Do I read correctly that <https://android-develope...

# compose

[Tolriq]

Do I read correctly that https://android-developers.googleblog.com/2025/01/orientation-and-resizability-changes-in-android-16.html will fully prevent all the ways for an application to offer a lock orientation setting? (Something many want by app and not globally?)

[Stylianos Gakis]

Looks like it, great news!

[Tolriq]

Not really 🙂 Tell that to all my users that asked for the options to lock orientation to what the app is started to avoid unwanted rotation in specific apps but not globally ..

[Stylianos Gakis]

Those users are free to lock their device's orientation tbh.
Latest Android versions do this quite well, where the orientation is locked by default, and when you rotate you get an icon for a few seconds giving you the option to rotate. All you have to do is not click it if you don't want it to rotate.

[Tolriq]

So manual for all apps, or automatic for all apps, 0 control per application.

[Tolriq]

That's what users requested.

[Tolriq]

My main app main function is a remote control, people are accustomed to muscle memory and always want the buttons at the same place whatever the way they handle the tablet. But want the rest of the apps to auto rotate.

[Tolriq]

No more possible.

[Tolriq]

Even me as personal usage, I have auto rotate on but disable auto rotate in reading apps for when in bed.

[Tolriq]

Now will have to pass my time toggling a global OS option to manage single apps.

[Tolriq]

Apps should and must support all format and it's easy to add a check at Play Store level if they want quality.

[Tolriq]

But users should still be able to control how apps works.

[Stylianos Gakis]

I see two things here:

• Games will be excluded from these changes, based on the android:appCategory flag
Games are excluded, maybe there's room for more such cases, have you shared your feedback with them for remote control apps and the likes?

• Also, users have control. They can explicitly opt-in to using the app’s default behavior in the aspect ratio settings.
There seems to be some user customizability possible there, perhaps your use case can be accommodated this way?

[Tolriq]

Without a way to control no, users needs to be able to lock in the orientation they want. And it's never really possible to have a discussion about those things as indie dev.

[jw]

Are your users on large screens where this applies?

[jw]

(Also this is neither Compose related nor Kotlin related)

[jw]

For Compose, you can probably rotate the entire layout with a modifier at the root and get like 99% of the way there.

[Tolriq]

For the remote yes. Luckily many have dedicated old tablets so bigger impact will take time. But yes I posted here as that code was in compose but not really related but with many informed people's.

[Tolriq]

Got more details about your idea ? The most used setting is lock to starting orientation. I guess I should detect windows size change and rotate via a graphic layer ?

[jw]

Not sure you want to rotate at the graphic layer level, since you need touches and things to go to the right place still.

[jw]

But yeah, you can detect device orientation and compensate to ensure the layout is always rotated opposite whatever it reports

[Tolriq]

Hum yes bad idea with the layer, will look into the rotate API I thought it was high performance impact.

[Tolriq]

Thanks

[jw]

I honestly have no idea. I don't think it would be given my limited knowledge of Compose UI internals.

[Tolriq]

It was probably me when testing some animations around that and misusing the APIs. For a single non animating one it's probably not an issue.

[Tolriq]

Ok so just tested a simple .rotate(90f) and fling and many gestures are just completely broken 😞 Will have to figure out something else.

[ephemient]

afaik Modifier.graphicsLayer transformations apply to pointer inputs too, so touches still go to the right place

[ephemient]

this seems to work naturally, at least in a quick test in the interactive preview

Untitled.kt

[Tolriq]

Thanks, yes works nicely and touches are translated as in rotation. But flings have the same issues. Phone portrait, rotation 90f fling to the right, the content will jump back to start.

[Tolriq]

Not sure the compose team would take such a bug report as it sounds quite hackish.

[Tolriq]

And there's also the needs to translate all the insets and cutouts 😞 I guess I'll better try to deprecate the feature and tell users to only rely on OS auto rotate disabled.

[Stylianos Gakis]

You could inset everything using the safe drawing insets and use all of the safe area as your canvas to paint things. You'd not go edge to edge, but it'd work just fine.

[Stylianos Gakis]

However I still don't understand why you haven't yet made an issue with your use case to see what their response would be.

[Tolriq]

After 12 years I've given up long ago any AOSP report. Triage that have 0 understanding of Android and will request code to show that the functions are noOp + a full bug report. Then a couple of weeks later, we have passed this to the engineering team, then 2 years later. This is obsolete closing. The rate time I can get answers, when showing them that no what they say does not match what I ask and asking how can I achieve the result, same result closing 2 years later.

[Stylianos Gakis]

Do you believe you have better chances discussing this in this slack channel or by filing a report?

[Tolriq]

I was looking for workaround and got them to decide if I deprecate the function or workaround.

[Stylianos Gakis]

I don't know what kind of reports you've made in the past, but I've had tens of bugs fixed by filing reports throughout the years. It doesn't always work, but it's better than doing nothing about it.

[Tolriq]

In AOSP? or other parts of the trackers, i have hundreds of bug reports, dozens to R8 team as they always answers, for AOSP unless I know who to ping like Sean for https://issuetracker.google.com/issues/227218386 it's waste of time.

[jw]

You're free to not file bugs, of course, but then you can't really complain when things don't work.

[Tolriq]

This is not a bug it's a feature request for them to change or adapt a decision they made since a long time. I still do report some AOSP bugs even if useless. I asked if I should report the rotation and fling issue as it's hackish and Compose and not AOSP but with all the insets impacts I'm not sure there's something worth trying to workaround.

[mreiter]

Should be easy enough to detect Android 16 & screen rotation and then display an alert like "Don't want the screen to auto-rotate? Here's a link to the settings"

[Tolriq]

Users are well aware of the global OS setting. What they requested many times is a setting for the app to override the OS setting and be able to have a lock in those specific apps.

[Tolriq]

Even I will be impacted when reading on tablet in the bed, I prefer the tablet to auto rotate as I do not like the small button hard to reach and quickly disappearing requiring quite a few attempt to have it appear again if missed. Yet for reading apps I want the reading app to lock the orientation and not have unwanted rotation because I move a little too much on the side.