Smartphones, mobile chipsets, and the apps and networks powering life on the go.
744 articles found
Apple design kits for Figma and Sketch are now available for iOS, iPadOS, and macOS 27. These include: Updates to Liquid Glass Expanded component and state support Naming changes to better align with code Improved resizing The addition of Dark Mode for macOS Download the design kits from the Apple Design Resources
As part of a recent agreement with Brazil’s competition regulator CADE (Conselho Administrativo de Defesa Econômica), Apple is introducing changes to iOS that create new options for developers' apps in Brazil. Beginning with iOS 26.5, developers can distribute apps on alternative app marketplaces, operate alternative app marketplaces, process app payments for digital goods and services outside of Apple In-App Purchase in iOS, and more. The new options for downloading apps from alternative app marketplaces and making app payments open new avenues for malware, fraud, scams, and privacy and security risks. Apple has worked with CADE to introduce protections from these new threats — with a special emphasis on child safety. Those protections include Notarization for iOS apps, an authorization process for app marketplaces, and requirements that help protect children from inappropriate content and scams. By July 6, 2026, all current members of the Apple Developer Program will need to agree to the latest update to the Apple Developer Program License Agreement, which includes new terms that allow for these options in Brazil. Learn more about the updates You can also request a 30-minute online appointment to ask questions about these changes.
Posted by Matthew Forsythe, Director Product Management, Android App Safety July 15, 2026: Updated Play Console requirements for Play developers To meet Android developer verification and updated Play Console Requirements , Play developers must register their Play apps in Play Console. While 99% of apps on Play have been registered automatically, you should check your Play Console Home page to register any remaining apps by September 30, 2026 to avoid global removal from Google Play and ensure a seamless user installation experience. You can also use Play Console to register apps you distribute outside of Google Play to ensure they can be installed on certified Android devices. Last year, we introduced Android developer verification to strengthen ecosystem security and stop malicious actors from hiding behind anonymity to release harmful apps. Millions of apps have been registered since the verification launched in March, covering nearly all installs on Google Play and a large majority of installs from outside of Google Play. We appreciate the feedback and partnership from industry leaders, developers, and Android communities that helped us design this experience and drive strong adoption. Initial launch across seven stores and four countries These new developer verification protections will take effect on September 30, 2026, starting with users in Brazil, Indonesia, Singapore, and Thailand. This rollout is an industry-wide effort to create a safer ecosystem . We will begin by verifying app installations from the following stores: Google (Google Play) Honor (HONOR App Market) OPlus (OPPO App Market) Samsung (Galaxy Store) Transsion (Palm Store) vivo (V-Appstore) Xiaomi (GetApps) Following this initial phase with our partners, we will expand these protections globally for all apps on certified Android devices in 2027. Automate your workflow with new APIs To further streamline app registration, we are launching a suite of developer-requested APIs to help you register apps in bulk or directly through your continuous integration and deployment (CI/CD) pipelines. The Android Developer ID Status API will let you check if a package name has already been registered, and the Android Developer Console API will let you register and manage package names directly within your development environment. Both APIs also support OAuth delegation, allowing third-party platforms, like Android app stores, to perform these operations natively on your behalf. We'll launch these APIs over the next few months. What’s next June 2026: Starting this month, we are rolling out a new system service that will be automatically installed on most Android devices. This service will be used later this year to verify developer registration. July 2026: We’ll launch the Android Developer ID Status API globally and begin early access for the Android Developer Console API. Early access also starts for limited distribution accounts on Android Developer Console. This new type of Android developer account is designed for students, hobbyists, and learners and lets you share your apps to up to 20 devices without a government-issued ID or a fee. August 2026: Limited distribution accounts and the new Android Developer Console API will launch globally. We’ll also launch an advanced flow for installing apps from unverified developers, which includes security checkpoints to resist coercion scams, while allowing power users to maintain the ability to sideload apps from unverified developers. September 30, 2026: App registration becomes required for participating stores in Brazil, Indonesia, Singapore, and Thailand . Unregistered apps can be sideloaded with Android Debug Bridge (adb) or advanced flow. 2027 and beyond: After incorporating the feedback from our partners, users, and developer community, we’ll expand the Android verification requirement globally. Get started with Android developer verification If you distribute apps in Brazil, Indonesia, Singapore, or Thailand via the stores listed above, please ensure your verification is complete by the September deadline. Google Play developers: Most Play developers are already verified, and over 99% of their apps have been registered. Go to your Play Console Home page to see your app’s verification status, and register apps you want to continue distributing that weren't automatically registered. Developers who distribute only outside of Google Play: Sign up for the Android Developer Console today to register your apps. Students and hobbyists: Sign up here for early access to limited distribution accounts to help us refine the feature with your feedback. Thank you for helping us build a safer Android ecosystem. Stay tuned for more updates as we approach September and the 2027 global rollout.
Posted by Coco Fatus, UX Designer, Alon Hetzroni, UX Engineer, Azin Mehrnoosh, Product Manager Android XR At this year's Google I/O , we announced an update for spatial experiences: the Geospatial API is now available as a preview in ARCore for Jetpack XR . By bringing Google's Visual Positioning System (VPS) to Android XR, Android XR enables anchoring digital content to the physical world with sub-meter accuracy and precise orientation in supported areas.* To explore what the Geospatial API could unlock, our team built a demo: the XR Geospatial Tour. Imagine walking into a new city, putting on a pair of wired XR glasses (like the upcoming XREAL Project Aura), and instantly having a knowledgeable, local guide showing you around. You don't need to stare down at a 2D map—instead, 3D models gently guide your path, and an intelligent voice tells you about the historical landmarks right in front of you. We combined the Geospatial APIs , Gemini API using Firebase AI Logic , Google Maps Grounding , and Jetpack XR SDK to create a hands-free, immersive walking tour experience. *Disclaimer: Video and Tour Guide application are for demonstration purposes only. Some sequences have been shortened. Any hardware depicted may be under development; final product details may differ. Let’s walk through the implementation details and show how we tied these APIs together to build a world-scale spatial experience. 1. Pinpointing the User with ARCore Geospatial API (VPS) Enhance your navigation experience on XR by combining the power of GPS with the precision of VPS. The accuracy and precise orientation that comes with VPS allows 3D waypoints to align with the physical world. This is why the Geospatial API on Android XR can help you build custom experiences. By using advanced computer vision, VPS tries to provide a GeospatialPose (including latitude, longitude, and heading) that is more accurate than GPS. Here's how we retrieve the user's Geospatial pose by mapping the device's orientation to a Geospatial coordinate: // Retrieve the current geospatial pose from the ARCore session val result = geospatial.createGeospatialPoseFromPose(arDevice.state.value.devicePose) if (result is CreateGeospatialPoseFromPoseSuccess) { val pose = result.pose Log.d("VPS", "Accurate Location: ${pose.latitude}, ${pose.longitude}") } Because the entire experience relies on this accuracy, we monitor the horizontalAccuracy and orientationYawAccuracy until they meet our thresholds. If the user is indoors or in an unrecognized area, we prompt them to "walk to an outdoor public space and look around". 2. Crafting the Itinerary with Gemini API & Google Maps Grounding Once we have a location, we use the Gemini API using Firebase AI Logic to prompt the Gemini model to act as a local tour guide. We pass the user's coordinates to the model and ask it to output a structured JSON response containing nearby walking tours: val configForTools = ToolConfig( functionCallingConfig = null, retrievalConfig = retrievalConfig { latLng = FirebaseLatLng(pose.latitude, pose.longitude) languageCode = "en" } ) val responseJsonSchema = Schema.obj( mapOf( "locationIntro" to Schema.string(), "tours" to Schema.array( Schema.obj( mapOf( "title" to Schema.string(), "description" to Schema.string(), "stops" to Schema.array( Schema.obj( mapOf( "name" to Schema.string(), "detailedName" to Schema.string(), "description" to Schema.string() ) ) ) ) ) ) ) ) val model = Firebase.ai(backend = GenerativeBackend.googleAI()).generativeModel( modelName = "gemini-3.5-flash", tools = listOf(Tool.googleMaps()), generationConfig = generationConfig { responseMimeType = "application/json" responseSchema = responseJsonSchema } ) val result = model.generateContent("The user is at latitude ${pose.latitude} and longitude ${pose.longitude}. Generate exactly 3 diverse tours near this location (e.g., historical, food, nature). All tour ideas should be walking distance only.") Large Language Models are great at generating rich descriptions, but they can sometimes hallucinate exact latitude/longitude coordinates. To solve this, we used Google Maps Grounding to ground the AI. 3. A Voice to Guide You: Gemini 2.5 TTS To make the tour guide feel truly present, we implemented dynamic voiceovers. Using the gemini-2.5-flash-tts model, we can configure our model generation config to natively return audio data instead of just text! Here’s how you can request the ResponseModality.AUDIO: val ttsModel = Firebase.ai(backend = GenerativeBackend.googleAI()) .generativeModel( modelName = "gemini-2.5-flash-tts", generationConfig = generationConfig { // Instruct the model to return Audio responseModalities = listOf(ResponseModality.AUDIO) } ) val response = ttsModel.generateContent("Say in a neutral but positive voice:\n$prompt") // Extract the raw audio bytes from the response val audioBytes = response.candidates.firstOrNull()?.content?.parts ?.filterIsInstance<InlineDataPart>() ?.firstOrNull { it.mimeType.contains("audio") }?.inlineData 4. Bringing it to Life in 3D with Jetpack XR The final piece of the puzzle is rendering this data in the user's field of view. The Jetpack XR SDK makes it intuitive to transition from a 2D Android UI to spatial computing. We used Jetpack Compose for XR to build spatial components. To represent points of interest along the tour, we built a Composable called InfoSphere, which contains a GltfModel of a 3D orb that floats in space and can be interacted with to reveal information. Using Jetpack XR SDK, we can place 3D models alongside the Compose UI using SpatialBox and SceneCoreEntity . We also used InteractableComponent to respond to user taps. @Composable fun InfoSphere( content: InfoBubbleContent, session: Session, sphereModel: GltfModel, isSelected: Boolean, onClick: () -> Unit ) { // SpatialBox lets us arrange 3D components and SpatialPanels together SpatialBox( SubspaceModifier .offset(x = 2.dp, y = 1.dp, z = (-3).dp) // Positioned in 3D space ) { // Smoothly animate the visibility of our 2D Compose UI Panel AnimatedSpatialVisibility(visible = isSelected) { SpatialPanel { InfoBubble(content) // Regular 2D Compose UI } } // Render our interactive 3D sphere SceneCoreEntity( factory = { GltfModelEntity.create(session, sphereModel).also { entity -> // Make the 3D model respond to user taps entity.addComponent(InteractableComponent.create(session) { inputEvent -> if (inputEvent.action == InputEvent.Action.UP) { onClick() } }) } } ) } } By combining AnimatedSpatialVisibility for traditional Compose UI surfaces with SceneCoreEntity 3D elements, we're able to seamlessly blend data into the physical world. Explore what’s possible with Android XR today Building the XR Geospatial Tour app showed us that the barrier to entry for world-scale spatial experiences is lower than ever for Android developers. With the Geospatial API now available in preview on Android XR, your apps can seamlessly understand the physical world around them. By combining Compose for XR ’s APIs with the high-precision location data of VPS and the generative capabilities of Gemini, we can create experiences that understand both where the user is and what they are looking at. To help you get hands-on with Android XR, we are thrilled to open applications for the Android XR Developer Catalyst Program , which includes XREAL Project Aura. Starting today, you can apply to get access to an XREAL Project Aura devkit or our display glasses devkit over the coming months! *Disclaimer: Available on select devices. Internet connection required. Works on compatible apps and surfaces. Results may vary.
Posted by Matthew McCullough, VP of Product Management, Android Developer Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months. Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity. Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works. Let's dive deeper into Android 17. An intelligence system With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol . AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state. The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments. /** * A note app's [AppFunction]s. */ class NoteFunctions( private val noteRepository: NoteRepository ) { /** * Adds a new note to the app. * * @param appFunctionContext The execution context. * @param title The title of the note. * @param content The note's content. */ @AppFunction(isDescribedByKDoc = true) suspend fun createNote( appFunctionContext: AppFunctionContext, title: String, content: String ): Note { return noteRepository.createNote(title, content) } } We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging. The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production. Adaptive-first Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks , the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard . No resizability/orientation restrictions on large screens To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively. Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps: App Bubbles: Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow. The Bubble Bar: On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles. Desktop interactive PiP: In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows. App Bubbles and Bubble Bar in action Activity recreation updates To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD , CONFIG_KEYBOARD_HIDDEN , CONFIG_NAVIGATION , CONFIG_TOUCHSCREEN , and CONFIG_COLOR_MODE ). Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute. Continue On Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed. Handoff Suggestion on a Tablet class MyHandoffActivity : Activity() { ... override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // Do stuff ... // Enable handoff setHandoffEnabled(true, null) } // Override and implement onHandoffActivityDataRequested override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData { // Create and return handoff data } } Go adaptive-first with Jetpack Compose To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill . This AI-powered developer workflow helps you implement the best adaptive practices: Adaptive navigation: Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library. Multi-pane layouts: Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions. FlexBox & Grid APIs: Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully. Advanced non-touch input: Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode. Dynamic window states: Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions. Android is Compose-first Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first . All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features. TIP Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code. Performance & efficiency App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas. App memory limits Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements: R8 Optimizer: The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8. The R8 Configuration Analyzer LeakCanary in Android Studio Panda: The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code. ApplicationExitInfo: If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap". On-Device Anomaly Detection: Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached. val profilingManager = applicationContext .getSystemService(ProfilingManager::class.java) val triggers = ArrayList<ProfilingTrigger>().apply { add(ProfilingTrigger.Builder( ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build()) } profilingManager.addProfilingTriggers(triggers) And, we're working to surface more in-field memory metrics to you within Google Play Console. Generational garbage collection Android 17 introduces more frequent, less resource-intensive young-generation collections to ART 's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates. Lock-Free MessageQueue For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods. The peekWhen and poll APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals. Static final fields now truly final Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application. Custom notification view restrictions To reduce memory usage we are further restricting the size of custom notification views . This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher. Privacy & Security Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences. Privacy-preserving choices Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects: System-Level Contact Picker: Utilizing ACTION_PICK_CONTACTS , apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad READ_CONTACTS permission. It also fully supports work/personal profile separation. Customizable Photo Picker aspect ratio: Using PhotoPickerUiCustomizationParams , you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps. System-rendered Location Button: A new system-rendered location button that you can embed in your app grants precise location access for the current session only. EyeDropper API: A new system-level API, ACTION_OPEN_EYE_DROPPER , allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions. val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> if (result.resultCode == Activity.RESULT_OK) { val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK) // Use the picked color in your app } } fun launchColorPicker() { val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER) eyeDropperLauncher.launch(intent) } Picking a color from anywhere on the screen with the system EyeDropper Local network access Apps targeting Android 17 now either require the ACCESS_LOCAL_NETWORK runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again. SMS OTP protection Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours: WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch) . Standard SMS OTP: Delayed for all apps targeting SDK 37+ . Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs . Post-Quantum Cryptography (PQC) Android 17 is ready for the next generation of cryptographic security: Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs. Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery. Safer native dynamic code loading If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError Smarter password protection for physical inputs With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default. Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer). These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields. Smarter password protection for physical inputs Media and camera features that empower creators and delight users Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers. Eclipsa Video : HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content. RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors. Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features. Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata. Versatile Video Coding (H.266) : Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat , adding new VVC profiles in MediaCodecInfo , and integrating support into MediaExtractor . Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera. Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video. Better support for hearing aids Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices. Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps. CameraX and Media3 CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences. We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX. Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices. Get your apps, libraries, tools, and game engines ready! If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17. Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following: Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens . Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError. Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in .) Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default . Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORK permission for broad, persistent access. Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance . NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate , vendor-specific SDKs, as well as the deprecated NNAPI . Get started with Android 17 Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air. Getting the Android 17 beta on partner devices Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi. For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail . Once you’re set up, here are some of the things you should do: Test your current app for compatibility, learn whether your app is affected by changes in Android 17 , and install your app onto a device or Android Emulator running Android 17 and extensively test it. Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward. For complete information on Android 17 please visit the Android 17 developer site .
Posted by Stevan Silva, Group Product Manager, and Vinny DaSilva, Developer Relations Engineer, Android XR From augmented overlays to fully immersive environments, the Android XR ecosystem is expanding rapidly, with the Samsung Galaxy XR already available today. Alongside the latest updates from Google I/O and this week's Augmented World Expo (AWE), we are rolling out new tooling, broader engine support, and ecosystem resources to help you build and scale experiences for Android XR. To get a quick look at what’s new, check out our video recap! Ready to dive deeper? Let’s jump into the major updates that will streamline your XR development workflow. Build, Prototype, and Iterate with Developer Preview 4 Developer Preview 4 of the Android XR SDK delivers the APIs and tools you need to design and build right from your laptop. This update includes the specific libraries required to target both immersive and augmented experiences. Check out the video below for a comprehensive breakdown of the latest in Android XR: To test all of these interactions without needing physical hardware, you can emulate and iterate on your code entirely within Android Studio . Check out our tooling deep dive to see how you can use XR emulator today: Extending your mobile apps for intelligent eyewear Building for audio and display glasses doesn't mean starting from scratch. With the Jetpack Projected library , you can take your existing mobile app to create a complementary augmented experience. The new release includes a Device Availability API that hooks into standard Android Lifecycle states, allowing your app to natively adapt its behavior based on whether the glasses are being worn. To accelerate your development journey, use Android CLI and the display glasses skill to extend your mobile app into an augmented experience. The skill is packed with specialized knowledge of Jetpack Compose Glimmer, enabling it to build your UI using our recommended design patterns. We’ve also updated Jetpack Compose Glimmer to optimize text legibility on optical see-through displays and provide touchpad-optimized navigation components. See how it looks in action: Developers at NAVER Papago are already exploring how to seamlessly bring their mobile experience directly to display glasses. To learn how to leverage these tools, watch this session on extending mobile apps for AI glasses: Building global, location-based immersive experiences For developers focused on immersive experiences, Developer Preview 4 brings modern, Kotlin-first architectural upgrades across our core perception libraries. We have also introduced an early preview of the Geospatial API for wired XR glasses. By combining ARCore for Jetpack XR with Google's Visual Positioning System (VPS), you can anchor digital content to high-precision real-world locations. Leverage the Platforms You Know with Expanded Engine Support We want you to build using the ecosystems and workflows you already know best. To make it easier to bring your existing XR experiences over to Android XR, we are thrilled to introduce official support for Unreal Engine and Godot alongside our existing Unity's support for wired XR glasses . With this expansion, we are introducing the Android XR Engine Hub , a desktop tool for Windows that shortens iteration cycles by bringing real-time testing directly into your engines viewport. Catch the full breakdown of our engine updates here: Apply Today for the Android XR Developer Catalyst Program In addition to providing the platform, we want to fuel your innovation directly through ecosystem resources. The Android XR Developer Catalyst Program is designed to support developers with access to pre-release hardware, including display glasses, and wired XR glasses. Accepted developers will receive resources, support forums, and launch guidance to prepare their apps for Google Play. Applications are open right now, so don't wait to submit your project ideas . Start Building! The ecosystem is growing rapidly, and the tools are ready for you to explore. Samsung Galaxy XR is available now, and you can dive in today with Developer Preview 4 of the Android XR SDK . If you don’t have hardware yet, check out the tools and to get started with the XR Emulator in Android Studio . For a complete look at all of our technical sessions, browse the full Android XR Playlist on YouTube to see what else is possible. We can’t wait to see what you build!
Posted by Simona Milanovic, Developer Relations Engineer Every year, Google I/O brings new announcements and resources across ecosystems and products, including Android development. As development shifts toward AI and agent-assisted tooling, we’ve expanded our offerings to better support you, however you decide to build for Android. To help you stay up to date, here is a summary of the top 3 announcements for Android Developer Productivity at I/O . 1. Android CLI is now stable Android CLI is now stable at version 1.0 , with more capabilities and integrations. The latest version of Android CLI introduces many new features, like programmatic version lookup and support for Journeys, and bridging capability to allow agents to integrate directly with Android Studio , via the studio command . Running Android Studio alongside the agent and Android CLI enables more efficient navigation in your project, more precise output, and access to Android Studio’s unique tooling , such as performance profilers, Compose Previews, and Android Device Streaming. Android CLI now integrates seamlessly with Android Studio Additionally, Google Antigravity now officially supports Android development, with the Android resources bundle , which includes the Android CLI and skills. You can either install the bundle during onboarding after installation, or later from the Settings > Customizations > Build With Google Plugins menu. This provides Antigravity with all the powerful tools and knowledge of Android CLI to enable it to perform core tasks—from creating projects to deploying your app on a new virtual device—much more easily and efficiently. Google Antigravity now offers the Android resources bundle Android CLI is now available through more package managers: like npm and homebrew . For more information, check out the Android CLI blog post and official documentation. 2. Android skills keep growing To help models gain expertise for specific development patterns that follow our best practices, we are continuing to expand our repository of Android skills , available through Android CLI and GitHub . Android skills ground LLMs in specialized workflows and domain knowledge, for the most common and more complex user journeys they might struggle with. We’ve shipped a fresh new batch of skills, with now more than 17 skills for areas such as: Adaptive UI Display Glasses and Jetpack Compose Glimmer for XR Migration to CameraX Perfetto SQL and Trace Analysis Jetpack Compose Styles API AppFunctions Verified email retrieval with Android Credential Manager Engage SDK integration Testing setup Wear OS Jetpack Compose Material3 Android skills keep growing You can browse skills and install using the Android CLI commands: android skills list android skills add –skill=<skill-name> For more information, check out the official documentation. 3. Android Bench adds new models Earlier this year, we launched Android Bench - our leaderboard for testing LLMs on real-world Android development challenges and tasks, with the goal of accelerating model improvements, so you have more helpful options for AI assistance. Latest results from Android Bench leaderboard You asked us to evaluate open models. So, at I/O, we added more commonly used ones, including our local model Gemma 4 , to the leaderboard. We also added the latest models including Gemini 3.5 Flash. We are also working on increasing the difficulty of challenges we’re giving LLMs, including creating long running tasks, to continue encouraging improvements. These tasks will be coming soon to Android Bench. Check out the Android Bench leaderboard to see the latest results. Android development anywhere By expanding our AI-assisted Android development offerings to Antigravity, through Android CLI and Android skills, and solidifying with the pro capabilities and production grade polish of Android Studio, we’re supporting Android developers wherever they choose to build. Have fun bringing your ideas to life faster and easier than ever before - we’re excited to see what you build in this new era of agentic development. Check out the full Developer productivity at Google I/O 2026 YouTube playlist for more information.
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 .
Who's covering this category most
Explore more of what's active right now
JBL Xtreme 5 drops back to its best price with $100 off at AmazonAndroid AuthorityAugust 20, 2026
Galaxy S26 FE breaks cover in new case leakAndroid AuthorityAugust 20, 2026
Sony WF-C710N deal drops these wireless ANC earbuds to just $88Android AuthorityAugust 20, 2026
Gemini’s Daily Brief could soon land on your Pixel’s lock screenAndroid AuthorityAugust 20, 2026
Amazon drops the TCL NXTPAPER 70 Pro below $280 in this best-price dealAndroid AuthorityAugust 20, 2026