On April 16, Google released Android 17 Beta 4, marking the conclusion of its scheduled beta phase. This build is primarily aimed at enhancing app compatibility and platform stability in anticipation of the final version’s launch. Developers are advised to take note of several behavioral changes that will impact their applications.
Beta 4 is the compatibility deadline
For SDK authors, library maintainers, tool developers, and game engine teams, the urgency of this beta release cannot be overstated. It is crucial that any necessary updates to support Android 17 are finalized promptly, ensuring that downstream app developers can proceed without delays when the stable version is released. Google suggests that developers test their applications by installing either production or test builds on devices or emulators running Beta 4, thoroughly engaging all app flows to identify any functional or UI regressions.
Behavior changes targeting apps on Android 17
Several significant changes will take effect for apps targeting Android 17. One of the most noticeable adjustments involves large-screen resizability restrictions; apps will no longer have the option to opt out of maintaining orientation, resizability, and aspect ratio constraints on larger displays.
Additionally, the restrictions on dynamic code loading have been expanded. The Safer Dynamic Code Loading protection, which was introduced in Android 14 for DEX and JAR files, now also applies to native libraries. Any native file loaded via System.load() must be designated as read-only; otherwise, an UnsatisfiedLinkError will be triggered.
Certificate Transparency is now enabled by default in Android 17, a shift from Android 16, where it required explicit opt-in from apps. Furthermore, local network access is restricted by default for applications targeting Android 17 or higher, with a new ACCESSLOCALNETWORK permission available for those that require extensive, persistent access.
Changes to background audio behavior have also been implemented. The audio framework now enforces stricter rules on background audio interactions, including playback, audio focus requests, and volume change APIs. These restrictions have evolved since Beta 2, introducing targetSDK gating for while-in-use foreground service enforcement and exempting alarm audio from these limitations.
App memory limits
Android 17 introduces per-app memory limits that are determined by the total RAM of the device. These limits have been conservatively set to target extreme memory leaks and other anomalies before they can lead to system-wide instability. Google anticipates that the majority of app sessions will experience minimal impact from these changes.
Developers can ascertain whether their application has been affected by checking the getDescription() field in ApplicationExitInfo for the string “MemoryLimiter.” Additionally, trigger-based profiling using TRIGGERTYPEANOMALY can capture heap dumps at the moment a memory limit is reached.
Android Studio Panda has integrated LeakCanary directly into the Profiler as a dedicated task, providing developers with insights into memory leaks in conjunction with their source code.
Profiling triggers for on-device anomaly detection
The introduction of an on-device anomaly detection service in Android 17 works in tandem with ProfilingManager. This service monitors for resource-intensive behaviors, such as excessive binder calls and memory usage, enabling applications to receive profiling artifacts triggered by system-detected events.
The TRIGGERTYPEANOMALY callback activates prior to any system enforcement, allowing developers to gather diagnostic data, including heap dumps or binder transaction stack samples, before the system terminates an application.
Post-quantum cryptography in Android Keystore
In a significant advancement, the Android Keystore now supports ML-DSA, the Module-Lattice-Based Digital Signature Algorithm standardized by NIST. On compatible devices, developers can generate ML-DSA keys and create quantum-safe signatures entirely within the secure hardware of the device. This implementation exposes the ML-DSA-65 and ML-DSA-87 algorithm variants through standard Java Cryptographic Architecture APIs, including KeyPairGenerator, KeyFactory, and Signature.
