Posted by Maru Ahues Bouza – Director, Product Administration
With 3+ billion Android units in use globally, the Android ecosystem is extra vibrant than ever. Android cell apps run on a various vary of units, from telephones and foldables to tablets, Chromebooks, automobiles, and most just lately XR. Customers purchase into a complete machine ecosystem and anticipate their apps to work throughout all units. To thrive on this multi-device surroundings, your apps must adapt seamlessly to totally different display sizes and kind elements.
Many Android apps depend on consumer interface approaches that work in a single orientation and/or limit resizability. Nevertheless, customers need apps to make full use of their giant screens, so Android machine producers added well-received options that override these app restrictions.
With this in thoughts, Android 16 is eradicating the power for apps to limit orientation and resizability on the platform stage, and shifting to a constant mannequin of adaptive apps that seamlessly regulate to totally different display sizes and orientations. This alteration will cut back fragmentation with habits that higher meets consumer expectations, and improves accessibility by respecting the consumer’s most popular orientation. We’re constructing instruments, libraries, and platform APIs that can assist you do that to offer a constantly wonderful consumer expertise throughout the whole Android ecosystem.
What’s altering?
Beginning with Android 16, we’re phasing out manifest attributes and runtime APIs used to limit an app’s orientation and resizability, enabling higher consumer experiences for a lot of apps throughout units.
These modifications will initially apply when the app is working on a big display, the place “giant display” implies that the smaller dimension of the show is larger than or equal to 600dp. This consists of:
- Internal shows of huge display foldables
- Tablets, together with desktop windowing
- Desktop environments, together with Chromebooks
The next manifest attributes and APIs might be ignored for apps focusing on Android 16 (SDK 36) on giant screens:
Manifest attributes/API | Ignored values |
screenOrientation | portrait, reversePortrait, sensorPortrait, userPortrait, panorama, reverseLandscape, sensorLandscape, userLandscape |
setRequestedOrientation() | portrait, reversePortrait, sensorPortrait, userPortrait, panorama, reverseLandscape, sensorLandscape, userLandscape |
resizeableActivity | all |
minAspectRatio | all |
maxAspectRatio | all |
There are some exceptions to those modifications for controlling orientation, side ratio, and resizability:
- As talked about earlier than, these modifications will not apply for screens which are smaller than sw600dp (e.g. most telephones, flippables, outer shows on giant display foldables)
Additionally, customers have management. They’ll explicitly opt-in to utilizing the app’s default habits within the side ratio settings.
Prepare for this transformation, by making your app adaptive
Apps might want to assist panorama and portrait layouts for window sizes within the full vary of side ratios that customers can select to make use of apps in, as there’ll now not be a approach to limit the side ratio and orientation to portrait or to panorama.
To check in case your app might be impacted by these modifications, use the Android 16 Beta 1 developer preview with the Pixel Pill and Pixel Fold collection emulators in Android Studio, and both set targetSdkPreview = “Baklava” or use the app compatibility framework by enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT flag.
For present apps that limit orientation and side ratio, these modifications might end in issues like overlapping layouts. To resolve these points and meet consumer expectations, our imaginative and prescient is that apps are constructed to be adaptive, to offer an optimum expertise whether or not somebody is utilizing the app on a telephone, foldable, pill, Chromebook, XR or in a automobile.
Resolving widespread issues
- Keep away from stretched UI elements: If layouts had been designed and constructed with the belief of telephone screens, then app performance might break for different side ratios. For instance, if a structure was constructed assuming a portrait side ratio, then UI parts that fill the max width of the window will seem stretched in landscape-oriented home windows. If layouts aren’t constructed to scroll, then customers might not be capable of click on on buttons or different UI parts which are offscreen, leading to complicated or damaged habits. Add a most width to elements to keep away from stretching, and add scrolling to make sure all content material is reachable.
- Protect state throughout when window dimension modifications: Eradicating orientation and side ratio restrictions additionally implies that the window sizes of apps will change extra ceaselessly in response to how the consumer prefers to make use of an app, akin to by rotating, folding, or resizing an app in multi-window or free-form windowing modes. Orientation modifications and resizing will end in Exercise recreation by default. To make sure an excellent consumer expertise, it’s crucial that app state is preserved by way of these configuration modifications in order that customers don’t lose their place within the app when altering posture or altering windowing modes.
To account for various window sizes and side ratios, use window dimension lessons to drive structure habits in a approach that doesn’t require device-specific customizations. Apps must also be constructed with the belief that window sizes will ceaselessly change. It’s not crucial to construct duplicate orientation-specific layouts – as a substitute, guarantee your present UIs can re-layout nicely it doesn’t matter what the window dimension is. When you’ve got a landscape- or portrait-specific structure, these layouts will nonetheless be used.
Optimizing for window sizes by constructing adaptive
In case you’re already constructing adaptive layouts and supporting all orientations, you are arrange for fulfillment as your app might be ready for every of the machine varieties and windowing modes your customers wish to use your app in and these modifications ought to have minimal impression.
We have additionally obtained a variety of testing sources that can assist you assure reliability. You possibly can automate testing with instruments just like the Espresso testing framework and Jetpack Compose testing APIs.
FlipaClip is a good instance of why constructing for a number of form-factors issues: they noticed 54% development in pill customers within the 4 months after they optimized their app to be adaptive.
Timeline
We perceive that the modifications are important for apps which have historically solely supported portrait orientation. UI points like buttons going off display, overlapping content material, or screens with digicam viewfinders may have changes.
That can assist you plan forward and make the required changes, right here’s the deliberate timeline outlining when these modifications will take impact:
- Android 16 (2025): Modifications described above would be the baseline expertise for big display units (smallest display width > 600dp) for apps that focus on API stage 36, with the choice for builders to opt-out.
- Android launch in 2026: Modifications described above would be the baseline expertise for big display units (smallest display width >600dp) for apps that focus on API stage 37. Builders won’t have an choice to opt-out.
Goal API stage | Relevant units | Developer opt-out allowed |
36 (Android 16) | Giant display units (smallest display width >600dp) | Sure |
37 (Anticipated) | Giant display units (smallest display width >600dp) | No |
The deadlines for focusing on a selected API stage are app retailer particular. For Google Play, the plan is that focusing on API 36 might be required in August 2026 and focusing on API 37 will be required in August 2027.
Getting ready for Android 16
Confer with the Android 16 modifications web page for all modifications impacting apps in Android 16, in addition to further sources for updating your apps in case you are impacted. To check your app, obtain the Android 16 Beta 1 developer preview and replace to targetSdkPreview = “Baklava” or use the app compatibility framework to allow particular modifications.
We’re dedicated to serving to builders embrace this new period of adaptive apps and unlock the complete potential of their apps throughout the various Android ecosystem. Take a look at the do’s and don’ts for designing and constructing throughout a number of window sizes and kind elements, as nicely tips on how to take a look at throughout the number of units that your app might be utilized in.
Keep tuned for extra updates and sources as we strategy the discharge of Android 16!