[nostrademons]

Foldables have a different UI which often requires different requests to the backend. They need to support both narrow-screen and large-screen formats for content, and you usually want to avoid having critical UI elements fall on the hinge for fairly obvious usability reasons.

[robertoandred]

That should all be abstracted out to the operating system, not dependent on checking for specific devices. Any app should be able to accommodate different screen/window sizes and safe areas.

[danaris]

...And does the Android OS provide this information?

'Cause if not, it makes perfect sense for nostrademons to be doing it themselves.

[nostrademons]

The Android OS does provide screen width/height information and safe areas. We use them when appropriate, which is fairly often, but not universally. Safe area support for foldables is pretty weak, though, because it's a relatively new device category that imposes fairly different constraints on devices.

The bigger issue is that there's always a long-tail of product considerations that need to be different on foldables and aren't covered by just feature-detecting the available screen resolution. Logging is one: PMs are very interested in how the category as a whole is performing, if only to direct future hardware plans, and that requires that it actually be categorized as a separate category. Backend requests are another: you can (and should) optimize your bandwidth usage on phones by not shipping to the client information that is only going to be displayed on large screens, and you can (and should) optimize your screen usage on large screens by displaying more information that is not available on phones, but foldables represent the union of the two, and you usually don't want the latency of additional backend requests when the user fold/unfolds the device.

(The irony is that the app in question is Google Play, and I personally know most of the PMs and several of the engineers on Android SysUI.)