fidzu : mobile

A great user experience is central to Android's mission, and delivering on that promise requires keeping devices fast, responsive, and reliable. This is why memory optimization is more critical than ever. Across the ecosystem, new devices are maintaining or even decreasing their physical memory capacity in response to memory price increases, yet users continue to expect the same seamless, high-performance app experience.

In Android 17, we introduced per-app memory limits, starting with Pixel devices, to help protect the overall user experience from applications using excess memory and causing system-wide slowdowns. Over the coming year, an increasing number of manufacturers will leverage the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices. If your app exceeds these limits, it will be slowed down and may be terminated. Optimizing your app's memory footprint is essential to preventing OS throttling and maintaining a seamless user experience.

In this post, we'll explore how these limits work under the hood, how to measure your memory footprint using new Android vitals metrics, and actionable steps to optimize your app or game.

Understanding Memory Limits

When your app exceeds its memory budget, Android takes progressive action to protect device responsiveness:

1. zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM (compressed RAM). While zRAM prevents immediate eviction, compressing and decompressing pages adds CPU overhead, which can result in noticeable UI jank and experience slowdowns.
2. Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system. 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.

To learn more about per-app memory limits and system enforcement, review the Android 17 App Memory Limits documentation. To test your application on different device configurations use the Memory Limiter adb commands.

Monitoring and Diagnosing Memory Issues

You can't optimize what you can't measure. Identifying memory leaks, excessive heap allocations, and Out-Of-Memory (OOM) crashes across the Android ecosystem requires leveraging complementary monitoring tools:

• Macro-level health with Android vitals: For broad, population-level visibility without additional overhead, Google Play Console's Android vitals provides essential metrics like Memory Usage (Anonymous RSS + swap) and Bitmap Memory Usage. This gives you a clear snapshot of memory distribution across different process states (foreground, background, user-perceived services, and cached) and RAM class ranges, helping you spot memory outliers.
• Memory Limiter exits & OOM tracking with Firebase Crashlytics: To stay informed about severe memory degradation before it impacts your key metrics, Crashlytics version 20.1.0 introduces additional debug data to help you catch, prioritize, and fix Out-Of-Memory exceptions and memory limiter kills. Tracking these events alongside custom logs and key-value metadata gives you immediate context into process status when a memory failure occurs.
• In-field traces with ProfilingManager: For teams able to maintain a performance observability framework, the ProfilingManager API introduced in Android 15 (API level 35) allows your app to programmatically request and collect detailed memory debug artifacts such as Java heap dumps and heap profiles directly from production devices. You can also trigger heap dump captures based on specific system signals, such as TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY.

Read our documentation to learn more about other memory monitoring techniques.

Summary & What's Next

With Android broadening per-app memory limits across all RAM classes, now is the time to audit your memory footprint:

1. Prioritize memory optimizations: Prevent your app from being impacted by app memory limits by using best practices.
2. Monitor memory use: Monitor your app's memory behavior to detect and resolve anomalous behavior.
3. Optimize your game: Follow the latest guidance for games and complex multimedia apps to maximize memory savings across process states.

Helpful Resources & References

• Android 17 Behavior Changes: App Memory Limits
• Android Vitals: Memory Usage (RSS + swap metric) and Bitmap Memory Usage
• Android Developers Blog: Prioritizing memory efficiency steps for Android 17
• Developer Guide: Manage your app's memory

Tinder is on a mission to power and inspire real connections by making meeting easy and fun for every new generation of singles. However, as their Android application codebase grew in size, so did its complexity. Prior to their latest optimization efforts, approximately 70% of the application was not optimized, carrying 17 dex files,including three dedicated just to startup. Although they had enabled R8, much of its optimization potential was blocked due to keep rules, and the team was unable to identify which specific rules were preventing optimization. To reduce startup time and decrease user-perceived Application Not Responding (ANR) errors, Tinder turned to the new R8 Configuration Analyzer to tackle these challenges.

By utilizing the R8 Configuration Analyzer, Tinder successfully identified and removed unintentional optimization blockers. The results were immediate and impactful: Tinder achieved a 47% reduction in app cold starts, shrank their app download size by 28.98% (down to 61.5 MB), and reduced user-perceived ANRs by 28%.

Configuration analyzer

The R8 Configuration Analyzer shows R8 optimization by tracking shrinking, optimization, and obfuscation scores to show available refinement areas. It shows the broad, redundant, or obsolete keep rules, including those from external libraries so that you can analyse the keep rule impact and refine the keep rules.

Key metrics shown in Configuration Analyzer include:

• Shrinking Score: Code percentage available for R8 shrinking.
• Optimization Score: Code percentage open to optimization (for example, method inlining, horizontal class merging).
• Obfuscation Score: Percentage of classes, methods and fields that can be renamed by R8 to decrease size.

Use the analyzer to audit keep rules and their impacts:

• Find broad rules: Narrow the scope of package-wide rules that restrict R8 optimization, and identify the specific classes, methods, and fields excluded from shrinking, optimization, and obfuscation.
• Refine rules: Target only specific classes/methods requiring reflection to unlock optimization
• Remove redundant rules: Remove rules that match zero classes, methods, or fields in your current build.
• Identical rules: Identical keep rules means rules that target the same classes, fields, and methods or duplicate declarations of keep rule in same or across keep rule files.
• Find subsumed rules: Clean up specific rules already covered by broader configurations.
• Identify problematic libraries: Check the combined optimization impact of merged consumer keep rules from all libraries.

To assist you in using the R8 Configuration Analyzer with agentic tools, we have published an R8 Analyzer skill. This skill optimizes automated development workflows by summarizing the R8 Configuration Analyzer report to display key metrics: optimization, obfuscation, and shrinking scores. It also highlights the five most impactful keep rules, giving you clear insight into what blocks code optimization.

Pinpointing hidden optimization blockers

Prior to integrating the R8 Configuration Analyzer, Tinder's Android app suffered from significant technical debt due to a heavily unoptimized codebase. This lack of optimization directly degraded the user experience, leading to users experiencing slow cold starts

To resolve these issues, the Tinder team utilized the R8 Configuration Analyzer to comprehensively audit their R8 configuration. The analyzer showed the R8 optimization of the codebase was around 28% even with R8 full mode. With R8 Configuration Analyzer, Tinder identified that an in-house library was introducing a broad, unscoped keep rule.

# Prevents optimization in all public classes along with all of their public and protected members

-keep public class * {
    public protected *;
}

This "wide" rule unintentionally covered various dependencies across the entire app, preventing optimization in a large number of classes. Because the over-inclusive rule prevented runtime crashes, developers frequently missed adding new rules for new features that used reflection, allowing hidden issues to compound over time.

By leveraging the insights provided by the R8 Configuration Analyzer, the team successfully traced and analyzed the specific classes affected by the broad keep rule from the library. The team immediately discovered that optimization was being blocked in larger, non-dynamically invoked classes where R8 could do optimization. Refining this specific keep rule allowed Tinder to unlock substantial optimization capabilities, untangle their legacy configurations, and drastically improve their overall optimization numbers, with R8 scores increasing from 28% to 50%, driving immediate performance gains across the application, and the Tinder team is actively working to further improve this figure.

• Faster Loading: The team achieved a 47% reduction on users experiencing slow cold starts of the app.
• Smaller Footprint: The App download size went from 86.6MB down to 61.5 MB (28.98% decrease).
• Improved Stability: User-perceived Application Not Responding (ANR) errors decreased from 0.35% to 0.28%, bringing them significantly closer to the peer median numbers
• Reduced Complexity: The total number of DEX files was cut down from 17 to 11, including just two startup files.

Beyond these technical performance enhancements, the increased application optimization directly translated into tangible business growth and higher user engagement, particularly in resource-constrained markets.

• Regional Engagement: Countries where Low RAM devices take a huge portion of the market, presented the largest increase in engagement, and decreasing the ANR rates was key to improving engagement in this vast market.
• Engagement Growth: Engagement has increased 3% since the increase in app optimization.

Safeguarding future performance with continuous integration

Addressing code minification isn't just a one-time fix; it requires continuous vigilance. Inspired by the massive gains achieved through the R8 Configuration Analyzer, Tinder's Android team proactively integrated optimization monitoring into their daily workflow to prevent regressions.

Tinder's team added a new job in their CI/CD pipeline to report changes in the optimization stats so everyone can see how their contribution is affecting optimization. When advising other developers considering R8 configuration integration, the team emphasizes the importance of auditing internal dependencies. While most popular third-party libraries come with well-defined rules, internal company projects that are considered "stable" might actually be introducing wide rules that negatively impact overall optimization.

Key Takeaways

Faced with a heavily unoptimized codebase and a high volume of DEX files, Tinder needed a way to cleanly audit their app's minification rules. The R8 Configuration Analyzer provided the ideal tooling necessary to identify overly broad internal library rules, the classes affected by the keep rule, allowing the team to confidently optimize their codebase. As a result, Tinder successfully cut cold starts by nearly half, shrank their APK size by over 28%, and established a healthier, more performant foundation for their users, with the team actively working to further improve these numbers.

How to Use R8 Configuration Analyzer

The R8 Configuration Analyzer and its standalone features can be utilized based on your current Android Gradle Plugin (AGP) version:

• AGP 9.3 Release: The R8 Configuration Analyzer is fully integrated and released with AGP 9.3. When running an R8 release build, the report will be generated in the build/outputs/mapping/release/configanalyzer.html folder.
• Standalone Gradle Task: AGP 9.3 introduces a standalone Gradle task that allows you to generate the analyzer report without running a full release build, providing a much faster feedback loop when refining keep rules locally:

  ./gradlew :app:analyzeReleaseR8Config

  The report is generated at build/reports/r8/r8-config-analyzer-release.html.
• Usage on Older AGP Versions: If you are using a version below AGP 9.3, you do not need to migrate your entire AGP version to analyze your configuration. You can update the R8 version independently to 9.3.7-dev or higher by following the Replacing R8 in AGP instructions. To generate the report locally, run your build with the property specified:

  ./gradlew assembleRelease  -Dcom.android.tools.r8.dumpkeepradiushtmltodirectory=<output_directory>

To learn more, see the R8 Configuration Analyzer documentation.

Since introducing the Android XR SDK, developers have transformed their ideas into innovative, immersive experiences for XR headsets and wired XR glasses. As the ecosystem expands, you can more easily take those experiences from preview to production and reach users wherever they are.

Today, we're excited to announce that Jetpack SceneCore, ARCore for Jetpack XR, and XR Runtime have reached beta with Jetpack Compose for XR to follow soon! This means the APIs are stabilizing, making it a great time to start integrating them into your production workflows and creating for Android XR.

Why the Jetpack XR SDK?

The Jetpack XR SDK includes all the tools and libraries you need to build immersive and augmented experiences for Android XR. Whether you're porting an existing 2D app or creating a new 3D XR app from scratch, you can do so using the familiar Android development tools you already know and love.

To support your development, this release focuses on providing the fundamental building blocks across the SDK:

• Jetpack SceneCore: Build and manipulate the Android XR scene graph with 3D content. You can arrange 3D models, play spatial audio, and use the robust entity-component system to create, control, and manage entities.
• ARCore for Jetpack XR: Bring digital content into the real world with perception capabilities. This library powers depth estimation, persistent anchors, hit testing, and plane identification.
• XR Runtime: Provides the essential runtime foundation of the SDK, handling device lifecycles, session creation, and system configurations that enable the API surface.
• Jetpack Compose for XR: Create spatial UI layouts that take advantage of Android XR's spatial capabilities. This library lets you use familiar Compose concepts to create spatial UIs and will be reaching Beta soon.

What's new in Beta?

Direct feedback from the developer previews helped shape these beta releases, introducing several important API refinements to ensure these libraries are ready for production.

• Expanded testing support: New capabilities are now available across the immersive XR libraries, including testing for spatial audio, XR devices, and session configuration. See the release notes for each library for details.
• Kotlin coroutines support: To better align with Kotlin coroutines, Session.create is now a suspend function.
• Terminology and class updates: AnchorEntity has been renamed to AnchorSpace, and both ActivitySpace and AnchorSpace now extend a common SpaceEntity class for more consistent spatial management across scenes.

See the full release notes for each library to check out specific details on naming and API changes.

Get started and provide feedback

To add these dependencies, include the Google Maven repository in your project and add the newest XR libraries to your build.gradle files.

dependencies {
    implementation("androidx.xr.scenecore:scenecore:1.0.0-beta02")
    implementation("androidx.xr.arcore:arcore:1.0.0-beta02")
    implementation("androidx.xr.runtime:runtime:1.0.0-beta02")
    implementation("androidx.xr.compose:compose:1.0.0-alpha17")
}

The ecosystem of Android XR devices that power immersive experiences is expanding, ranging from XR headsets to wired XR glasses. There's never been a better time to start building immersive experiences with the Jetpack XR SDK Beta. Dive in and start building and testing on Samsung Galaxy XR or Android XR Emulator today.