Due to a recent court ruling lifting an injunction on Texas law SB 2420, new Apple Accounts in Texas are now subject to the law, which introduced age assurance requirements for app marketplaces and developers. As previously announced , this includes age assurance and parent or guardian consent on behalf of minors under the age of 18 for downloads, Apple In-App Purchases, and significant changes associated with an app. Parents or guardians will also be able to revoke their consent for any app they previously approved for their child. These changes will go into effect starting June 4, 2026. Developers can request age category data for these Apple Accounts through the Declared Age Range API . For significant changes, developers should use the Significant Change API under the PermissionKit framework. As a reminder, it’s the developer’s responsibility to determine when there’s a significant change to their app. To learn about a parent or guardian’s revocation of consent, the App Store is providing a server notification that developers can configure to receive notifications that consent has been withdrawn for their app on a child or teen’s device. Next steps Review documentation and implement the following: Declared Age Range API Significant Change API under PermissionKit New age rating property type in StoreKit App Store server notification Use Apple’s sandbox testing environment to validate that the APIs have been implemented correctly. For the most up-to-date requirements and API references, see: Age assurance frameworks Q&A Learn more about how you can provide age-appropriate experiences and safeguard privacy in your apps and games using robust features available across Apple platforms.
Apple Developer Centers are dedicated spaces designed for in-person developer sessions, labs, workshops, and appointments across a wide range of Apple technologies and platforms. With locations in Cupertino, Shanghai, Bengaluru, and Singapore, these purpose-built facilities bring expert guidance and hands-on learning directly to the developer community. Later this year, Apple will open its fifth Developer Center in Berlin, offering developers throughout Europe even greater access to Apple experts and events. Created for teams of all sizes and at every stage of app development, the Apple Developer Center Berlin will serve as a home base for in-person sessions, workshops, and one-on-one appointments. Additionally, consultation areas and dedicated labs will offer hands-on support from Apple experts in multiple languages. Learn more
Posted by Alice Yuan, Developer Relations Engineer, Ajesh Pai, Developer Relations Engineer, and Fung Lam, Developer Relations Engineer While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year. To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace. Beyond these forced terminations, unoptimized memory usage inevitably degrades the user experience. When the app approaches heap memory limits, it triggers frequent garbage collection—leading to noticeable UI stutters. Furthermore, when a device runs out of available memory, the system scrambles to reclaim pages, causing CPU strain, UI latency, and battery drain. If the memory shortage is too severe, it can cause Low Memory Killer (LMK) events that abruptly terminate background processes and force apps to have slow cold starts and lose user state. To build highly performant apps and avoid these forced terminations, we recommend that you adopt the following memory optimization strategies: Maximize bytecode optimization with R8 Optimize image loading Detect and fix memory leaks with Android Studio Trim memory when app leaves visible state Advanced memory observability with ProfilingManager A condensed version of this blog post is also available in video format, go check it out! Understanding Android 17 app memory limits App memory limits are being introduced in Android 17 to prevent "one bad actor" from destroying the multitasking experience and stability of the user’s entire device. Here is a breakdown of the reasons driving this architectural change: Preventing cascading kills: When an app becomes bloated or leaks memory while holding a privileged state (e.g. it’s running a Foreground Service), it is initially shielded from the system's Low Memory Killer (LMK). As this single app grows unchecked and hoards RAM, the LMK is forced to compensate by killing off dozens of smaller, well-behaved cached apps and background jobs to reclaim space for the memory hog. Preserving multitasking and user state: When the system is forced to purge cached apps to accommodate a single leaking process, the multitasking experience is severely degraded. Users returning to prior cached applications encounter sluggish cold starts instead of near-instant warm resumes. This inefficiency generates more CPU strain and accelerates battery depletion. It can also destroy the user’s context in recently used apps, such as scroll positions, navigation stacks, and in-game progress. To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo . If the system applied a limit, the exit reason is reported as REASON_OTHER and the description string will contain "MemoryLimiter:AnonSwap". You can also leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached. Furthermore, Android is actively working to surface more in-field memory metrics to developers within the Google Play Console. We have also expanded our memory limits documentation to include local debugging commands, allowing you to simulate memory constraints in your local environment and validate your application's behavior under any memory limit enforcement. Maximize bytecode optimization with R8 A highly effective way to reduce your app's memory footprint is to enable the R8 optimizer. By shrinking classes, methods, and fields into shorter names and stripping out unused code and resources, R8 significantly reduces your app's memory footprint by minimizing the amount of resident code required during execution. R8 minimizes resident code, shrinking the memory footprint and lowering LMK termination risk. This results in more frequent warm starts over slow cold starts. Additionally, streamlined bytecode reduces main-thread CPU overhead, directly cutting ANR rates for a more fluid user experience. For example, the digital bank Monzo enabled full R8 optimization and saw a 35% reduction in their ANR rate, a 30% improvement in cold start rate, and a 9% reduction in overall app size. The digital bank Monzo enabled full R8 optimization and boosted performance metrics by up to 35%. To properly configure R8 in your build.gradle file: Set isShrinkResources = true and isMinifyEnabled = true . Use proguard-android-optimize.txt instead of the legacy proguard-android.txt , which actually prevents optimizations and is no longer supported in Android Gradle Plugin 9. Remove android.enableR8.fullMode = false from your gradle.properties . If you are using reflection in your code base, then add Keep rules to prevent R8 from optimizing those parts of the code. Make sure to scope the keep rules narrowly to get the maximum optimization. To get the maximum optimization, make sure to follow these best practices in your keep rule file. Remove global options like -dontoptimize , -dontshrink , and -dontobfuscate that prevent R8 from optimizing the entire codebase Remove keep rules that prevent optimizing Android components like Activity, Services, Views or Broadcast receivers. Refine the broad package wide keep rules to target only specific classes or methods. To see more best practices, view our keep rules documentation . Library Developer R8 Best Practices If you are a library developer, strictly place the rules your consumers need into your consumer-rules file, and keep your library's internal protection rules in your proguard-rules.pro file. For more information on how to optimize libraries, see Optimization for library authors . R8 Configuration Analyzer To audit your R8 optimization, use the Configuration Analyzer . Configuration analyzer shows the current state of optimization with Obfuscation, Optimization, and Shrinking scores. With configuration analyzer, you can also understand how many classes, methods or fields are prevented from optimization by each keep rule. Refine these broad package wide keep rules to unlock the maximum optimization. Using configuration analyzer, you can also identify keep rules that are subsuming other keep rules, redundant keep rules and unused keep rules. The Configuration Analyzer shows the current state of optimization with Obfuscation, Optimization, and Shrinking scores. R8 Agent Skill You can also leverage the R8 Agent Skill with Android Studio agent or other AI tools to resolve misconfigurations and refine your rules resulting in improved app performance. (Insights from AI-driven skills will require technical verification) Optimize image loading Bitmaps are usually the largest common objects residing in your app's memory. They represent the final stage of the image loading process where compressed files, like JPEGs or PNGs, are decoded into raw pixel data for display. This means a tiny 100KB compressed image can balloon into several megabytes of RAM because memory consumption is determined by the image's pixel dimensions and color depth. Since bitmap operations are frequently on the critical path to drawing frames, unoptimized images cause severe memory bloat and UI jank. Google recommends leveraging image loading libraries Coil for Kotlin-first projects, particularly when developing with Jetpack Compose and Glide for Java-based applications. Adopt these five best practices Downsample images: If you’re loading bitmaps manually, avoid loading a massive image into a tiny thumbnail view; use inSampleSize to load a smaller version. Glide and Coil downsamples images by default and you can configure this downsample strategy using DownsampleStrategy and ImageLoader respectively. Cropping: Avoid embedding padding directly into an image file for letterboxing purposes (e.g., creating a transparent border to expand an image dimensions). Rather than baking in these borders, utilize InsetDrawable or apply padding directly within the View or Composable containing the bitmap. Config: Balance memory and quality by choosing the right pixel format. Use RGB_565 when transparency isn't needed, which uses half the memory of the default ARGB_8888 format. In Glide you can configure this by using DecodeFormat and in Coil you can use bitmapConfig property. Prioritize vector drawables: For basic geometric assets, leverage ShapeDrawable as a lightweight alternative to decoding rasterized bitmaps. By defining these assets once via XML, you ensure they scale seamlessly across all display densities while effectively eliminating resource-driven memory bloat. Reuse: If your application manages Bitmaps manually then to minimize memory churn, when a bitmap is no longer required, the app should call bitmap.recycle() and immediately discard the Bitmap reference. If you use an image loading library like Glide or Coil, return the bitmap to the library’s managed pool. By providing an existing buffer for future memory needs, the pool effectively avoids the overhead of new allocations. Check out our documentation on Optimizing performance for images to learn more. Android Studio tooling You can also eliminate redundant bitmaps using Android Studio Narwhal 4. Here is how to hunt them down in five simple steps: Open the Profiler tab in Android Studio Click Heap Dump (or "Analyze Memory Usage") and hit record to take a snapshot of your app’s current memory state. Scan the analysis results for the yellow warning triangle ⚠️, which Android Studio uses to flag duplicate bitmaps being stored multiple times. Alternatively, navigate to the profiler header, choose "Filter by:" and pick the "Duplicate Bitmaps" setting. Click on any flagged entry to open the Bitmap Preview pane, allowing you to see exactly which image is the repeat offender. Use that visual confirmation to track down the redundant loading logic in your code and implement a better caching strategy. Look for the yellow warning triangle ⚠️ in heap dumps when using the Android Studio Profiler. Detect and fix memory leaks with Android Studio Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM). Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE. The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis. LeakCanary memory leak analysis contextualized with Go to declaration for debugging Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks. Examples of common memory leaks Memory leaks occur when an object persists in memory beyond its intended lifespan. This typically happens due to: Retaining references to Fragments, Activities, or Views that are no longer in use. Mismanaging Context references. Failing to properly unregister observers, listeners, and receivers. Creating static references to objects that are bound to components with shorter lifecycles. Here are a few example scenarios: Scenario Compose-based example View-based example Leaking Context Example: Passing LocalContext.current to a ViewModel Fix: Keep Context dependent logic within the UI layer. For non-UI layers, refactor to use dependency injection or observe UI state using Kotlin flow . Example: Storing an Activity in a companion object or static variable. Fix: Don’t hold static references to UI components. Refactor to use dependency injection or observe UI state using Kotlin flow . Leaking Listeners Example: Using DisposableEffect to start a listener but leaving onDispose empty. Fix: Perform the unregistration and cleanup logic inside the onDispose block. Example: Registering for SensorManager updates and forgetting to unregister. Fix: Manually call unregisterListener() in onStop() or onDestroy() lifecycle. Leaking Views Example: Holding a reference to a legacy View inside an AndroidView without a release strategy. Fix: Use the release block of the AndroidView composable to clean up the legacy View . Example: Keeping a reference to a view binding object after the Fragment is destroyed. Fix: Set the binding variable to null inside the onDestroyView () lifecycle method. Trim memory when app leaves visible state Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management . Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app. If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the ComponentCallbacks2 interface. You can implement onTrimMemory in your Activity , Fragment , Service , or even your custom Application class. Using it in the Application class is highly effective for global cache management. The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage. In terms of memory lifecycle management, your implementation should focus exclusively on TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND . Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15. TRIM_MEMORY_UI_HIDDEN : This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources. TRIM_MEMORY_BACKGROUND : At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session. import android.content.ComponentCallbacks2 // Other import statements. class MainActivity : AppCompatActivity(), ComponentCallbacks2 { /** * Release memory when the UI becomes hidden or when system resources become low. * @param level the memory-related event that is raised. */ override fun onTrimMemory(level: Int) { if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) { // Release memory related to UI elements, such as bitmap caches. } if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) { // Release memory related to background processing, such as by // closing a database connection. } } } Note: The onTrimMemory integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents . Advanced memory observability with ProfilingManager To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the ProfilingManager API . Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles. For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback . Android 17 introduces new event-driven triggers , most notably TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY : The OOM trigger automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the registerForAllProfilingResults callback. The Anomaly trigger detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app. val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java) val triggers = ArrayList () triggers.add(ProfilingTrigger.Builder( ProfilingTrigger.TRIGGER_TYPE_ANOMALY)) val mainExecutor: Executor = Executors.newSingleThreadExecutor() val resultCallback = Consumer { profilingResult -> if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) { // upload profile result to server for further analysis setupProfileUploadWorker(profilingResult.resultFilePath) } profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback) profilingManager.addProfilingTriggers(triggers) Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI . To streamline your memory debugging workflow, use the Heap Dump Explorer , this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place. Use the Heap Dump Explorer ’s embedded flamegraph to visually inspect and navigate through objects with the highest heap allocations. Conclusion Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance .
Posted by Ataul Munim, Android Developer Relations Engineer A truly differentiated Android experience is about delivering premium delight wherever your users are. At Google I/O ‘26, we showcased how the latest advancements in the Android ecosystem can help you elevate your app's quality while maximizing development efficiency. To help you build apps that stand out, we're diving into the key tools and libraries designed to optimize your core performance, extend the surfaces of your app to other devices, and streamline how your app handles high-quality media. Here is a recap of the essential updates and sessions you need to know to deliver a next-level experience across form factors! Maximize app performance and ROI with the R8 Configuration Analyzer A premium experience is only as good as its foundation, and a performant foundation is what allows your app to scale across the Android ecosystem. This is especially true with the release of Android 17, which introduces conservative, device RAM-based app memory limits to target extreme memory leaks and outliers before they cause system-wide instability. To stay below these new system thresholds and prevent your app from being terminated, having a lean footprint is no longer optional: it’s a critical requirement. This year, we’re making it easier to build highly optimized, fast apps by introducing the R8 Configuration Analyzer in Android Studio. R8 is your most powerful tool for improving app performance, but its effectiveness is often limited by overly broad "keep rules" that prevent the compiler from stripping away unused code. The new Configuration Analyzer provides optimization, obfuscation, and shrinking scores, allowing you to identify specific rules that are preventing the benefits of R8 optimization. By optimizing their R8 configurations, developers at Monzo achieved a 30% improvement in cold starts and a 35% reduction in ANRs. Smaller, faster code isn't just about efficiency; it's about ensuring your app has the memory headroom to deliver delight on every form factor, from the phone to the car. Extend your reach with a unified approach to Widgets on Phones, Watches and Cars User interaction is shifting toward quick, glanceable moments—short bursts of information that keep users connected without needing to open the full app. To help you increase the reach of your app content, we are unifying the development experience across the Android ecosystem with Jetpack Glance. By using a consistent, Compose-based model, you can elevate the content most important to your users straight to the phone’s home screen, Wear Widgets (previously Tiles!), and cars with a familiar workflow. In order to help users engage with your content and features, even outside your app, we are making widgets more expressive and adaptive with RemoteCompose. On Wear OS, RemoteCompose allows you to use the Compose tools you’re already comfortable with to define UI logic that renders natively on remote surfaces, ensuring that your glanceable experiences remain highly performant and responsive even on resource-constrained hardware. On mobile and cars, RemoteCompose is used as a new framework giving Widgets new expressive capabilities. You can use Jetpack Glance (together with RemoteCompose on Wear) to deliver a cohesive user journey. Whether it’s viewing flight status on the car dashboard, checking a gate change on a watch, or managing a boarding pass from a phone widget, this shared approach maximizes your app’s presence while keeping your development effort focused and efficient. Supercharge your media pipeline with a complete, production-ready toolkit Android has become a world-class home for the entire media lifecycle, and we are simplifying the journey from the first capture to the final playback. By leveraging Jetpack CameraX and Media3, you can build professional-grade experiences that feel native across the entire ecosystem. It starts with high-fidelity capture using the CameraXViewfinder Composable, which ensures your preview remains perfectly scaled and responsive on any form factor, including foldables and tablets. Use this to build adaptive capture experiences like a picture-in-picture view for multi-tasking, or that take advantage of modern features like high-frame-rate or slow-motion capture with CameraX v1.5. The new Media3 AI Effects library will provide a unified interface for premium features like Image & Video Enhance, Magic Eraser, and Studio Sound. This allows you to focus on the creative intent while Media3 handles the heavy lifting of choosing the most efficient and reliable path for the device. Then, use the latest improvements in multi-asset editing with Media3 Transformer to composite your edited videos together! Complete the pipeline with tools designed for professional-grade export and viewing, including: CodecDB, which offers data-driven encoding recommendations tailored to specific chipsets, ensuring your exported videos maintain high visual quality with minimal noise or blurriness Scrubbing Mode in ExoPlayer to provide the buttery-smooth seeking experience users expect from premium media apps Enhanced Cast support with the new CastPlayer API in Media3 By unifying these technical pillars, you can build a cohesive, high-performance media journey that delivers both delight for your users and high ROI for your development team. For more details, check out the premium Android experience YouTube playlist .
The Instagram accounts for the Obama White House and the Chief Master Sergeant of the U.S. Space Force were briefly defaced with pro-Iranian images and messages over the weekend, after instructions began circulating on Telegram showing how to trick Meta's "AI support assistant" bot into resetting account passwords.
