Android 17 is now the latest major Android OS release, bringing another round of changes that development teams need to understand before updating their applications.
Released on June 16, 2026, Android 17 uses API level 37 and continues several directions Google has been building toward over recent Android versions. Applications are expected to adapt better across screen sizes, handle privacy-sensitive capabilities more carefully, consume system resources responsibly, and follow stricter security and lifecycle expectations.
Some Android 17 changes affect every application running on the new operating system, even when the app has not updated its target SDK. Others become active only when the application targets Android 17.
For development teams, this distinction matters.
Updating an app for Android 17 is not simply a matter of changing targetSdkVersion to 37. Teams should test existing behavior on Android 17 first, review the changes triggered by targeting API 37, update affected functionality, and then move the new target through their normal testing and release process.
Here are the Android 17 changes that deserve the most attention.
Android 17 Is API Level 37
Android 17 corresponds to API level 37.
Developers can use the Android 17 SDK to compile against the newest platform APIs and test behavior changes introduced in the release.
However, three Android SDK values continue to serve different purposes.
minSdkVersion defines the oldest Android version the app supports.
compileSdkVersion determines which Android APIs are available when compiling the application.
targetSdkVersion tells Android which platform behavior model the application has been designed and tested to support.
An app can therefore compile against Android 17 while still supporting much older Android versions.
Updating the target SDK deserves additional testing because some Android 17 behavior changes are specifically activated for applications targeting API 37.
Large-Screen Adaptivity Is No Longer Optional
One of the most important Android 17 developer changes affects large-screen applications.
Android 16 began ignoring some orientation, aspect-ratio, and resizability restrictions on displays with a smallest width of at least 600dp for applications targeting API 36.
Android 16 also provided a temporary opt-out.
For apps targeting Android 17, that opt-out is no longer available.
This means developers should expect applications to run in different:
Window sizes
Orientations
Aspect ratios
Multi-window configurations
An app should no longer depend on forcing portrait mode simply because its interface was originally designed around a phone.
Teams should test tablets, foldables, desktop-style windows, and other large-screen environments.
Adaptive layouts should react to the current app window instead of assuming that the application always occupies the complete physical display.
This makes large-screen testing an important part of CI/CD pipelines for Android app development, especially for products that previously avoided tablet or multi-window optimization.
Android 17 Introduces App Memory Limits
Android 17 introduces app memory limits designed to improve overall system stability.
The initial limits are intentionally conservative and are aimed mainly at extreme memory consumption, leaks, and other outlier behavior.
This does not mean normal applications suddenly need to reduce every allocation.
It does mean teams should pay closer attention to uncontrolled memory growth.
Common sources of memory problems include:
Retaining activities
Loading oversized images
Holding large collections indefinitely
Keeping unnecessary caches
Failing to release media resources
Processing very large datasets in memory
Apps killed because of Android 17's memory limiting can expose additional information through ApplicationExitInfo, helping developers investigate the cause.
Memory monitoring should therefore become another part of performance testing rather than something teams examine only after receiving crash reports.
Background Audio Rules Are Stricter
Android 17 strengthens restrictions around background audio behavior.
The platform now places tighter controls on:
Starting audio playback
Requesting audio focus
Changing volume
when an application is not in an appropriate lifecycle state.
For apps targeting Android 17, these restrictions are stricter.
Media, communication, alarm, navigation, fitness, and other audio-heavy applications should review where playback starts and whether the action is connected to a valid user or foreground interaction.
A pattern that previously worked by quietly starting audio from the background may no longer behave as expected.
Test audio flows involving:
Background state
Foreground services
Notifications
Media controls
Audio focus
App reopening
Silent failures can be particularly difficult to diagnose because some restricted audio operations do not necessarily produce a normal application crash.
Local Network Access Now Requires More Attention
Android 17 adds an important privacy change for apps communicating with devices on the local network.
Applications targeting Android 17 can require the ACCESS_LOCAL_NETWORK runtime permission when they need direct access to devices on the user's LAN.
This can affect apps connecting to:
Smart-home hardware
Printers
Local media servers
Casting receivers
Cameras
Enterprise equipment
IoT devices
Developers should not automatically request the permission during startup.
Request it when the user attempts a feature that genuinely requires local-network access.
Android also provides system-mediated approaches for certain device-selection use cases that can reduce the need for broad network access.
During app prototyping, teams should identify these permission moments early because adding another runtime permission can change onboarding and device-setup workflows.
Encrypted Client Hello Improves Network Privacy
Android 17 introduces platform support for Encrypted Client Hello, or ECH.
ECH improves TLS privacy by protecting information that can otherwise reveal which domain an application is connecting to.
For applications targeting Android 17, ECH can be used when the application's networking library and the remote server both support it.
Developers can also configure ECH behavior through Network Security Configuration.
Most application teams will not build custom ECH implementations.
However, organizations with sophisticated networking infrastructure, regulated environments, custom proxies, or unusual TLS configurations should test their network stack carefully when moving to Android 17.
The release is another sign that Android networking is moving toward stronger encrypted-by-default behavior.
Cleartext Networking Should Be Removed
Android 17 also continues Android's move away from insecure cleartext traffic.
Google has announced a future deprecation direction for the broad usesCleartextTraffic mechanism.
Applications still depending on plain HTTP should treat this as another reason to migrate.
Production apps should normally communicate through HTTPS.
Where special network rules are genuinely necessary, teams should use Network Security Configuration rather than weakening networking protections across the entire application.
This is particularly important for fintech, healthcare, SaaS, and enterprise applications handling sensitive information.
OTP Protection Becomes Stronger
Android 17 expands protection around SMS messages containing one-time passwords.
Applications should not assume that broad SMS access automatically means they can immediately read authentication codes intended for another service.
Android's direction is to protect OTP messages and encourage apps to use purpose-built mechanisms such as SMS Retriever or SMS User Consent where appropriate.
Authentication teams should test:
Login verification
Account recovery
Phone verification
Two-factor authentication
on Android 17.
Do not wait for users to report that automatic verification suddenly stopped working.
Camera APIs Gain New Capabilities
Android 17 introduces several improvements for applications working heavily with cameras.
One useful addition is the ability to update camera session output configurations without completely closing and recreating the session.
This can support smoother transitions between camera use cases.
For example:
Photo mode
→ switch configuration
→ video mode
without unnecessary disruption.
Android 17 also introduces RAW14 support on compatible hardware, allowing professional camera applications to work with 14-bit RAW image data.
These features will matter most to photography, scanning, imaging, creative, medical imaging, and specialized enterprise applications.
Normal business apps using basic camera capture may not require major changes.
Photo Picker Gets More Customization
Android 17 expands the system Photo Picker with additional UI customization.
Developers can adjust aspects of how media appears inside the picker, including supported grid presentation options.
The Photo Picker remains important because it allows users to choose specific photos or videos without requiring applications to request broad access to the complete media library.
For privacy-conscious applications, using system pickers where possible can reduce unnecessary permissions while providing users with more control.
VVC Support Expands Android Media Capabilities
Android 17 adds platform support for Versatile Video Coding, also known as H.266 or VVC.
VVC is a newer video codec designed to provide stronger compression efficiency for modern media workloads.
Streaming and media companies should still evaluate actual device support, encoding infrastructure, playback compatibility, and fallback strategies before changing their delivery pipeline.
A platform supporting a codec does not automatically mean every device in the application's audience can immediately depend on it.
Media apps should continue using capability detection and appropriate fallback behavior.
WebGPU Comes to Android
Android 17 also expands Android's graphics and compute capabilities through WebGPU APIs.
WebGPU provides modern access to GPU-powered graphics and compute capabilities and fits into Android's broader movement toward Vulkan as an important low-level graphics foundation.
Potential use cases include:
Advanced graphics
Visualization
Image processing
Games
Creative tools
GPU compute
Most normal business applications will not need to rebuild around WebGPU.
However, graphics-heavy and compute-heavy products should evaluate whether the new APIs can improve performance or simplify future rendering architecture.
AI Workloads Need Android 17 Testing Too
The platform itself continues becoming more capable of supporting advanced computational workloads.
Apps using AI and machine learning integration in Android apps should test model execution, memory use, thermal behavior, and background processing on Android 17.
This is particularly important because AI features can place unusual pressure on:
Memory
CPU
GPU
NPU
Battery
A model that works correctly does not automatically qualify as a well-optimized mobile feature.
Combine Android 17 compatibility testing with established Android app battery optimization techniques so AI improvements do not create new retention problems.
Bluetooth Behavior Changes for Target 37
Apps targeting Android 17 should also review Bluetooth communication.
For RFCOMM-based BluetoothSocket connections, InputStream.read() now returns -1 when the connection closes or the end of the stream is reached.
Some older implementations may rely entirely on catching an IOException to exit a reading loop.
Those loops should now explicitly handle -1.
This may affect:
Hardware companion apps
Medical devices
Industrial equipment
Vehicle accessories
Specialized enterprise devices
Bluetooth testing should include real connection loss instead of checking only successful communication.
Deep Links and Notifications Still Need Compatibility Testing
Platform upgrades can expose assumptions in application entry points.
Teams should re-test Firebase Cloud Messaging for Android push notifications to ensure notification taps, background behavior, and destination routing remain correct.
The same applies to the Android deep linking implementation guide used by marketing and growth workflows.
Test the application when it is:
Closed
Backgrounded
Already open
Signed out
Opened through a notification
Opened through an App Link
Android upgrades are a good time to test complete user journeys instead of checking only whether the home screen launches.
Google Play Does Not Require API 37 Yet
Android 17 may be the latest operating system, but Google Play's target API requirement follows a separate schedule.
Starting August 31, 2026, standard new Android apps and app updates submitted to Google Play need to target Android 16, API level 36, or higher.
Google Play is not yet requiring standard applications to target Android 17/API 37.
This distinction gives teams time to migrate carefully.
A practical approach is:
Run app on Android 17
→ fix compatibility issues
Then:
Update compile SDK
→ review API 37 behavior changes
→ target Android 17 when ready
→ run full regression testing
Do not change the target version without understanding what behavior it activates.
Update Your Testing Strategy
Every Android release should create a repeatable compatibility process.
A practical Android 17 checklist includes:
Install the application on Android 17 without changing the target SDK.
Test major user journeys.
Review behavior changes affecting all apps.
Update the Android SDK and dependencies.
Review behavior changes for apps targeting API 37.
Test large-screen and multi-window behavior.
Test background work, audio, networking, notifications, Bluetooth, and permissions.
Run automated and manual regression testing.
Release through testing tracks before full production rollout.
Professional Android app development services can help teams audit existing applications, identify compatibility risks, modernize platform integrations, and prepare releases for newer Android versions.
Cross-Platform Apps Still Need Android 17 Work
Using Flutter app development, React Native app development, or broader cross platform app development does not remove Android OS compatibility requirements.
Framework updates may handle some platform changes.
Others affect:
Native plugins
Permissions
Background services
Notifications
Bluetooth
Media
Window behavior
Teams need to verify that their framework version and third-party packages support Android 17.
Native iOS app development has its own yearly OS migration cycle, so organizations supporting both platforms should include OS compatibility work in the broader release roadmap.
Android 17 Should Be Part of Product Planning
Platform upgrades should not be isolated engineering tasks.
New capabilities may influence product design.
Large-screen changes may create opportunities for better tablet workflows.
Camera APIs may improve imaging experiences.
Privacy changes may require onboarding adjustments.
WebGPU may enable richer visual tools.
During future app prototyping, designers and developers should work from current Android behavior instead of reproducing assumptions from older OS versions.
Similarly, app store optimization should accurately represent platform capabilities that users can actually access rather than advertising unsupported Android features.
Android 17 Continues Android's Adaptive Direction
Android 17 is not a complete reinvention of Android development.
It is a continuation of several trends that have been building for years.
Applications are expected to adapt across more devices and window sizes.
Privacy protections are becoming more specific.
Background behavior is more controlled.
Networking is becoming more secure.
Media and graphics capabilities continue expanding.
System resources such as memory and battery receive greater protection.
For Android development teams, the most important response is not to chase every new API.
Review what affects your application, test those areas thoroughly, and adopt new capabilities when they create meaningful value.
The latest Android release should make the app better for users, not simply make the target SDK number larger.
Frequently Asked Questions
What is the latest Android version for developers?
As of July 27, 2026, Android 17 is the latest stable major Android release. It was released on June 16, 2026 and corresponds to API level 37.
Does Google Play require apps to target Android 17?
No. Starting August 31, 2026, standard new apps and updates need to target Android 16, API level 36, or higher. Android 17 targeting is not yet the minimum Google Play requirement.
What is the biggest Android 17 change for large-screen apps?
Apps targeting Android 17 can no longer opt out of the large-screen behavior that ignores certain orientation, aspect-ratio, and resizability restrictions on qualifying large displays.
Does Android 17 affect apps that still target older API levels?
Yes. Some Android 17 behavior changes apply to all applications running on Android 17 regardless of target SDK. Other changes apply only when an application targets API level 37.
What should developers test before targeting Android 17?
Test core workflows, large-screen resizing, permissions, networking, background work, audio, Bluetooth, notifications, deep links, memory use, battery behavior, third-party SDKs, and any platform-specific integrations used by the app.
Can Flutter and React Native apps support Android 17?
Yes. Flutter and React Native apps can support Android 17, but teams should update their frameworks and dependencies, verify native plugins, review Android-specific behavior changes, and perform compatibility testing on Android 17 devices or emulators.
