3 ms·

Android's backwards compatibility, especially for apps that don't update, is quite solid. The cases where previously working behavior is broken without requirin

Android's backwards compatibility, especially for apps that don't update, is quite solid. The cases where previously working behavior is broken without requiring the app to "opt-in" to the breakage is generally scoped solely to things that are considered abuse vectors. Which "draws over other apps" unfortunately is. It's not as good as Windows' back compat, no. But then again nothing is, as that's the only platform concerned with preserving not just API compatibility but bug compatibility.

cesarb 4y ago
There's one case I know of where previously working behavior is broken, for something which was not an abuse vector at all: if your app depends on the hardware "menu" button (which is the case for nearly all apps made back when having a hardware "menu" button was standard for Android), for several versions Android showed an emulated software "menu" button next to the back/home/etc buttons, but more recent Android versions no longer show that button, breaking all these apps (since there's no way to get to their menu). See https://www.xda-developers.com/rip-menu-button-android-10-drops-legacy-support-extremely-old-apps/ https://www.xda-developers.com/rip-menu-button-android-10-dr... for details.
BoorishBears 4y ago
Android's backwards compatibility is atrocious with a capital A. Every version has random will-be-breaking changes that get held off if your app was compiled before said version came out, but there's only a release or two before the change starts to ignore your compiled version (for example, when a massive permissions change comes down the pipe, any app that's compiled against the newest SDK breaks immediately, and apps that were compiled against older ones just get to break next release) And just like any mobile platform, apps heavily rely on the OS to provide UI widgets and layout. So even design language changes can (and often do) break the UI. - What you're probably seeing is what developers are forced to work around: the fact that everyone is stuck targeting ancient versions of Android because Android users have just accepted their devices never getting OS upgrades. Android Studio will still default to targeting a minimum SDK version of API 25. Android 5.0. From November 12 2014. The situation is so bad that Google removed it from their dashboard (https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards) and buried it in the IDE: https://9to5google.com/2022/05/20/android-2022-distribution-numbers-chart/ https://9to5google.com/2022/05/20/android-2022-distribution-... Nearly a third of Android devices are on a version of Android >5 years old... just imagine if all your iOS apps had to target iOS 11 as a minimum feature set, and XCode defaulted to supporting iOS 8 for all new projects When the apps can't rely on any newer features, it creates the illusion of backwards compatibility.
- kllrnohj 4y ago
  Uhh... Like all of that is wrong. Android Studio defaults to targeting the latest API level, and Play Store even refuses to let you upload an APK targeting something more than a couple APIs old. You're regularly confusing target API with min API. Those are very different things. And compiled SDK version is yet something else. And the rest of your rant is about developers updating their app needing to track changes. That's an unrelated discussion. We're talking about backwards compatibility for apps that don't update. Meaning compile SDK & target API aren't changing. Android keeps those working quite well. > So even design language changes can (and often do) break the UI. Nonsense. The platform widgets are governed by the theme which almost never changes. Old apps that don't get updated will still be depending on Theme.Holo which is still there, still unchanging. And most apps are primarily not using platform widgets anyway, they're using Jetpack instead. Things like RecyclerView, MotionLayout, ConstraintLayout, CardView, etc.. are not in the platform, they're in jetpack. Which is a static library bundled into the APK. And therefore obviously not changing with an OS update
  - BoorishBears 4y ago
    I'm something of a career Android guy so I can do better than point out how you're wrong, I can explain how you're wrong too :) > Android Studio defaults to targeting the latest API level Whoops, you confused compileSdkVersion, targetSdkVersion, and minimumSdkVersion (I even mention targetSdkVersion separately as "compiled against") You (wrongly) thought I was talking about targetSdkVersion (which often doesn't match compileSdkVersion on new releases because... targetSdkVersion lets you duck those breaking changes! That's why Google usually gives about a year before any given compileSdkVersion requirement [latest release] is graduated to a targetSdkVersion requirement). I mean, read what I wrote again: "targeting a minimum SDK version of API 25". Min SDK is still defaulted to selecting Lollipop in AS Dolphin which hit full release just this month, and when you ask AS for help it specifically highlights API 25. Try it yourself :) - > And the rest of your rant is about developers updating their app needing to track changes. That's an unrelated discussion. We're talking about backwards compatibility for apps that don't update. Meaning compile SDK & target API aren't changing. Android keeps those working quite well. You didn't understand the conversation so you failed to follow the connection. I'm saying that Android doesn't do backwards compatibility well, but it doesn't need to since everyone is actively going out of their way to support old versions. That's why any moderately long lived Android codebase will be full of: if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.XXX) useOldPermission/Flag/Type else useNewPermission/Flag/Type > Nonsense. The platform widgets are governed by the theme which almost never changes. Old apps that don't get updated will still be depending on Theme.Holo which is still there, still unchanging. Forget OS version, the theme changes per device manufacturer! There've been cases of manufacturers redefining constants like android.R.color.black to be something completely different than black! That's why you can't rely on android.R for anything > And most apps are primarily not using platform widgets anyway, they're using Jetpack instead. Things like RecyclerView, MotionLayout, ConstraintLayout, CardView, etc.. are not in the platform, they're in jetpack. You failed to realize that the part of Jetpack they're using the most is a library literally called AppCompat. You know why it's called that? It try (and sometimes fail) to wrap dozens of versions worth of incompatibilities, bugs, breaking changes, and missing implementations in the user space (app)! It's a literal ode to my entire point, that Android *the OS* has never done backwards compatibility well, so developers *in userspace* end up putting a *ton* off work into glossing it over! Imagine if on iOS you couldn't just make a UITextView, you had to use a wrapper around a UITextView because iOS 8 was still a valid target for many apps and any new feature for the UITextView in the OS had to be simultaneously back ported to iOS 8... Just the other day I observed a case where the Jetpack Cardview worked on API 32 but broke on API 25 because on API 32 the library falls back to the built-in from the OS... Well it turns out the AppCompat implementation just randomly breaks if the radius of a corner is greater than View.height / 2. The OS implementation handles that gracefully. That's why any half-serious development team ends up needing to run their apps on all those versions of Android (or just unwittingly lives the life of one of those randomly poorly behaving apps in the wild) - Like if you just slow your roll and read what I said, it shouldn't be controversial to any serious Android developer. You said it yourself... Android has reached the point where basic UI development is literally built on a ball of strategies to work around the atrocious backwards compatibility situation via AppCompat and other libraries in Jetpack... do you realize that's not normal or indicative of an OS with good backwards compatibility? It's an utterly bizarre corner that Google backed themselves into and are aching for outs on

cesarb 4y ago

There's one case I know of where previously working behavior is broken, for something which was not an abuse vector at all: if your app depends on the hardware "menu" button (which is the case for nearly all apps made back when having a hardware "menu" button was standard for Android), for several versions Android showed an emulated software "menu" button next to the back/home/etc buttons, but more recent Android versions no longer show that button, breaking all these apps (since there's no way to get to their menu). See https://www.xda-developers.com/rip-menu-button-android-10-drops-legacy-support-extremely-old-apps/ https://www.xda-developers.com/rip-menu-button-android-10-dr... for details.

BoorishBears 4y ago

Android's backwards compatibility is atrocious with a capital A. Every version has random will-be-breaking changes that get held off if your app was compiled before said version came out, but there's only a release or two before the change starts to ignore your compiled version (for example, when a massive permissions change comes down the pipe, any app that's compiled against the newest SDK breaks immediately, and apps that were compiled against older ones just get to break next release) And just like any mobile platform, apps heavily rely on the OS to provide UI widgets and layout. So even design language changes can (and often do) break the UI. - What you're probably seeing is what developers are forced to work around: the fact that everyone is stuck targeting ancient versions of Android because Android users have just accepted their devices never getting OS upgrades. Android Studio will still default to targeting a minimum SDK version of API 25. Android 5.0. From November 12 2014. The situation is so bad that Google removed it from their dashboard (https://developer.android.com/about/dashboards https://developer.android.com/about/dashboards) and buried it in the IDE: https://9to5google.com/2022/05/20/android-2022-distribution-numbers-chart/ https://9to5google.com/2022/05/20/android-2022-distribution-... Nearly a third of Android devices are on a version of Android >5 years old... just imagine if all your iOS apps had to target iOS 11 as a minimum feature set, and XCode defaulted to supporting iOS 8 for all new projects When the apps can't rely on any newer features, it creates the illusion of backwards compatibility.

kllrnohj 4y ago
Uhh... Like all of that is wrong. Android Studio defaults to targeting the latest API level, and Play Store even refuses to let you upload an APK targeting something more than a couple APIs old. You're regularly confusing target API with min API. Those are very different things. And compiled SDK version is yet something else. And the rest of your rant is about developers updating their app needing to track changes. That's an unrelated discussion. We're talking about backwards compatibility for apps that don't update. Meaning compile SDK & target API aren't changing. Android keeps those working quite well. > So even design language changes can (and often do) break the UI. Nonsense. The platform widgets are governed by the theme which almost never changes. Old apps that don't get updated will still be depending on Theme.Holo which is still there, still unchanging. And most apps are primarily not using platform widgets anyway, they're using Jetpack instead. Things like RecyclerView, MotionLayout, ConstraintLayout, CardView, etc.. are not in the platform, they're in jetpack. Which is a static library bundled into the APK. And therefore obviously not changing with an OS update
- BoorishBears 4y ago
  I'm something of a career Android guy so I can do better than point out how you're wrong, I can explain how you're wrong too :) > Android Studio defaults to targeting the latest API level Whoops, you confused compileSdkVersion, targetSdkVersion, and minimumSdkVersion (I even mention targetSdkVersion separately as "compiled against") You (wrongly) thought I was talking about targetSdkVersion (which often doesn't match compileSdkVersion on new releases because... targetSdkVersion lets you duck those breaking changes! That's why Google usually gives about a year before any given compileSdkVersion requirement [latest release] is graduated to a targetSdkVersion requirement). I mean, read what I wrote again: "targeting a minimum SDK version of API 25". Min SDK is still defaulted to selecting Lollipop in AS Dolphin which hit full release just this month, and when you ask AS for help it specifically highlights API 25. Try it yourself :) - > And the rest of your rant is about developers updating their app needing to track changes. That's an unrelated discussion. We're talking about backwards compatibility for apps that don't update. Meaning compile SDK & target API aren't changing. Android keeps those working quite well. You didn't understand the conversation so you failed to follow the connection. I'm saying that Android doesn't do backwards compatibility well, but it doesn't need to since everyone is actively going out of their way to support old versions. That's why any moderately long lived Android codebase will be full of: if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.XXX) useOldPermission/Flag/Type else useNewPermission/Flag/Type > Nonsense. The platform widgets are governed by the theme which almost never changes. Old apps that don't get updated will still be depending on Theme.Holo which is still there, still unchanging. Forget OS version, the theme changes per device manufacturer! There've been cases of manufacturers redefining constants like android.R.color.black to be something completely different than black! That's why you can't rely on android.R for anything > And most apps are primarily not using platform widgets anyway, they're using Jetpack instead. Things like RecyclerView, MotionLayout, ConstraintLayout, CardView, etc.. are not in the platform, they're in jetpack. You failed to realize that the part of Jetpack they're using the most is a library literally called AppCompat. You know why it's called that? It try (and sometimes fail) to wrap dozens of versions worth of incompatibilities, bugs, breaking changes, and missing implementations in the user space (app)! It's a literal ode to my entire point, that Android *the OS* has never done backwards compatibility well, so developers *in userspace* end up putting a *ton* off work into glossing it over! Imagine if on iOS you couldn't just make a UITextView, you had to use a wrapper around a UITextView because iOS 8 was still a valid target for many apps and any new feature for the UITextView in the OS had to be simultaneously back ported to iOS 8... Just the other day I observed a case where the Jetpack Cardview worked on API 32 but broke on API 25 because on API 32 the library falls back to the built-in from the OS... Well it turns out the AppCompat implementation just randomly breaks if the radius of a corner is greater than View.height / 2. The OS implementation handles that gracefully. That's why any half-serious development team ends up needing to run their apps on all those versions of Android (or just unwittingly lives the life of one of those randomly poorly behaving apps in the wild) - Like if you just slow your roll and read what I said, it shouldn't be controversial to any serious Android developer. You said it yourself... Android has reached the point where basic UI development is literally built on a ball of strategies to work around the atrocious backwards compatibility situation via AppCompat and other libraries in Jetpack... do you realize that's not normal or indicative of an OS with good backwards compatibility? It's an utterly bizarre corner that Google backed themselves into and are aching for outs on