[HTML payload içeriği buraya]
30.8 C
Jakarta
Monday, May 11, 2026

Put together your app for the resizability and orientation modifications in Android 17


Posted by Miguel Montemayor, Developer Relations Engineer, Android 

With the discharge of Android 16 in 2025, we shared our imaginative and prescient for a tool ecosystem the place apps adapt seamlessly to any display—whether or not it’s a telephone, foldable, pill, desktop, automobile show, or XR. Customers count on their apps to work in every single place. Whether or not multitasking on a pill, unfolding a tool to learn comfortably, or operating apps in a desktop windowing setting, customers count on the UI to fill the obtainable show house and adapt to the system posture.

We launched important modifications to orientation and resizability APIs to facilitate adaptive conduct, whereas offering a short lived opt-out that can assist you make the transition. We’ve already seen many builders efficiently adapt to this transition when focusing on API degree 36.

Now with the discharge of the Android 17 Beta, we’re shifting to the following part of our adaptive roadmap: Android 17 (API degree 37) removes the developer opt-out for orientation and resizability restrictions on massive display units (sw > 600 dp). Once you goal API degree 37, your app should be able to adapting to a wide range of show sizes.

The conduct modifications make sure that the Android ecosystem affords a constant, high-quality expertise on all system kind components.

What’s altering in Android 17

Apps focusing on Android 17 should guarantee their compatibility with the part out of manifest attributes and runtime APIs launched in Android 16. We perceive for some apps this can be a giant transition, so we’ve included greatest practices and instruments for serving to keep away from widespread points later on this weblog put up.

No new modifications have been launched since Android 16, however the developer opt-out is not potential. As a reminder: when your app is operating on a big display—the place massive display implies that the smaller dimension of the show is bigger than or equal to 600 dp—the next manifest attributes and APIs are ignored:

Be aware: As beforehand talked about with Android 16, these modifications don’t apply for screens which might be smaller than sw 600 dp or apps categorized as video games based mostly on the android:appCategory flag.

Manifest attributes/APIIgnored values
screenOrientationportrait, reversePortrait, sensorPortrait, userPortrait, panorama, reverseLandscape, sensorLandscape, userLandscape
setRequestedOrientation()portrait, reversePortrait, sensorPortrait, userPortrait, panorama, reverseLandscape, sensorLandscape, userLandscape
resizeableActivityall
minAspectRatioall
maxAspectRatioall

Additionally, customers retain management. Within the facet ratio settings, customers can explicitly opt-in to utilizing the app’s requested conduct.

Put together your app

Apps might want to assist panorama and portrait layouts for show sizes within the full vary of facet ratios wherein customers can select to make use of apps, together with resizable home windows, as there’ll not be a approach to limit the facet ratio and orientation to portrait or to panorama.

Check your app

Your first step is to check your app with these modifications to verify the app works nicely throughout show sizes.

Use Android 17 Beta 1 with the Pixel Pill and Pixel Fold collection emulators in Android Studio, and set the targetSdkPreview = “CinnamonBun”. Alternatively, you should utilize the app compatibility framework by enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT flag in case your app doesn’t goal API degree 36 but.

We’ve got extra instruments to make sure your layouts adapt appropriately. You possibly can robotically audit your UI and get solutions to make your UI extra adaptive with Compose UI Test, and simulate particular show traits in your assessments utilizing DeviceConfigurationOverride.

For apps which have traditionally restricted orientation and facet ratio, we generally see points with skewed or misoriented digital camera previews, stretched layouts, inaccessible buttons, or lack of consumer state when dealing with configuration modifications. 

Let’s check out some methods for addressing these widespread points.

Guarantee digital camera compatibility

A typical downside on panorama foldables or for facet ratio calculations in eventualities like multi-window, desktop windowing, or related shows, is when the digital camera preview seems stretched, rotated, or cropped.

Guarantee your digital camera preview isn’t stretched or rotated.

This concern usually occurs on massive display and foldable units as a result of apps assume fastened relationships between digital camera options (like facet ratio and sensor orientation) and system options (like system orientation and pure orientation).

To make sure your digital camera preview adapts appropriately to any window dimension or orientation, contemplate these 4 options:

Answer 1: Jetpack CameraX (most well-liked) 

The best and most sturdy resolution is to make use of the Jetpack CameraX library. Its PreviewView UI ingredient is designed to deal with all preview complexities robotically:

  • PreviewView appropriately adjusts for sensor orientation, system rotation, and scaling

  • PreviewView maintains the facet ratio of the digital camera picture, sometimes by centering and cropping (FILL_CENTER)

  • You possibly can set the dimensions sort to FIT_CENTER to letterbox the preview if wanted

For extra data, see Implement a preview within the CameraX documentation.

Answer 2: CameraViewfinder 

If you might be utilizing an current Camera2 codebase, the CameraViewfinder library (backward suitable to API degree 21) is one other trendy resolution. It simplifies displaying the digital camera feed through the use of a TextureView or SurfaceView and making use of all the mandatory transformations (facet ratio, scale, and rotation) for you.

For extra data, see the Introducing Digicam Viewfinder weblog put up and Digicam preview developer information.

Answer 3: Handbook Camera2 implementation 

If you cannot use CameraX or CameraViewfinder, you will need to manually calculate the orientation and facet ratio and make sure the calculations are up to date on every configuration change:

  • Get the digital camera sensor orientation (for instance, 0, 90, 180, 270 levels) from CameraCharacteristics

  • Get the system’s present show rotation (for instance, 0, 90, 180, 270 levels)

  • Use the digital camera sensor orientation and show rotation values to find out the mandatory transformations to your SurfaceView or TextureView

  • Make sure the facet ratio of your output Floor matches the facet ratio of the digital camera preview to forestall distortion

Vital: Be aware the digital camera app is likely to be operating in a portion of the display, both in multi-window or desktop windowing mode or on a related show. For that reason, display dimension shouldn’t be used to find out the size of the digital camera viewfinder; use window metrics as a substitute. In any other case you danger a stretched digital camera preview.

For extra data, see the Digicam preview developer information and Your Digicam app on totally different kind components video.

Answer 4: Carry out fundamental digital camera actions utilizing an Intent 

If you happen to do not want many digital camera options, a easy and simple resolution is to carry out fundamental digital camera actions like capturing a photograph or video utilizing the system’s default digital camera utility. On this case, you possibly can merely use an Intent as a substitute of integrating with a digital camera library, for simpler upkeep and flexibility. 

For extra data, see Digicam intents.

Keep away from stretched UI or inaccessible buttons

In case your app assumes a selected system orientation or show facet ratio, the app could run into points when it’s now used throughout varied orientations or window sizes.

Guarantee buttons, textfields, and different components aren’t stretched on massive screens.

You’ll have set buttons, textual content fields, and playing cards to fillMaxWidth or match_parent. On a telephone, this seems nice. Nonetheless, on a pill or foldable in panorama, UI components stretch throughout all the massive display. In Jetpack Compose, you should utilize the widthIn modifier to set a most width for elements to keep away from stretched content material:

Field(
    contentAlignment = Alignment.Heart,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching past 300dp
            .fillMaxWidth()        // Fills width as much as 300dp
            .padding(16.dp)
    ) {
        // Your content material
    }
}

If a consumer opens your app in panorama orientation on a foldable or pill, motion buttons like Save or Login on the backside of the display could also be rendered offscreen. If the container is just not scrollable, the consumer may be blocked from continuing. In Jetpack Compose, you possibly can add a verticalScroll modifier to your element:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

By combining max-width constraints with vertical scrolling, you guarantee your app stays purposeful and usable, no matter how vast or quick the app window dimension turns into.

See our information on constructing adaptive layouts.

Protect state with configuration modifications

Eradicating orientation and facet ratio restrictions means your app’s window dimension will change way more continuously. Customers could rotate their system, fold/unfold it, or resize your app dynamically in split-screen or desktop windowing modes.

By default, these configuration modifications destroy and recreate your exercise. In case your app doesn’t correctly handle this lifecycle occasion, customers can have a irritating expertise: scroll positions are reset to the highest, half-filled types are cleaned, and navigation historical past is misplaced. To make sure a seamless adaptive expertise, it’s important your app preserves state by way of these configuration modifications. With Jetpack Compose, you possibly can opt-out of recreation, and as a substitute permit window dimension modifications to recompose your UI to replicate the brand new quantity of house obtainable.

See our information on saving UI state.

Focusing on API degree 37 by August 2027

In case your app beforehand opted out of those modifications when focusing on API degree 36, your app will solely be impacted by the Android 17 opt-out elimination after your app targets API degree 37. That can assist you plan forward and make the mandatory changes to your app, right here’s the timeline when these modifications will take impact:

The deadlines for focusing on a selected API degree are app-store particular. For Google Play, new apps and updates shall be required to focus on API degree 37, making this conduct necessary for distribution in August 2027.

Making ready for Android 17

Consult with the Android 17 modifications web page for all modifications impacting apps in Android 17. To check your app, obtain Android 17 Beta 1 and replace to targetSdkPreview = “CinnamonBun” or use the app compatibility framework to allow particular modifications.

The way forward for Android is adaptive, and we’re right here that can assist you get there. As you put together for Android 17, we encourage you to evaluation our guides for constructing adaptive layouts and our massive display high quality tips. These sources are designed that can assist you deal with a number of kind components and window sizes with confidence.

Don’t wait. Begin preparing for Android 17 in the present day!

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles