I recently read this Gizmodo article which I can say, quite misleading at some points.

And for a little background, Google recently added to Android's code base to prevent apps who are designed for Android 5.1 or lower to be installed into the operating system.

And I have some feelings that Google is also doing the same for running outdated-but-installed apps when the user wishes to upgrade from Android 13 to 14, just like what Apple did several times in iOS and MacOS.

The article author, however, mentioned this as an (possibly evil) attempt made by Google to restrict people from sideloading apps—and limit them to only install from the Play Store.

And oh, I almost forgot, the article was salted with phrases like "this is a threat to the Android open ecosystem!"

The two "target versions" of Android apps.

Before going further, I think we should understand how Android apps "target" which Android versions are compatible with the app.

And 5 years ago, I always thought that Android Jelly Bean (4.1-4.3) is "the Windows XP of Android operating system" with many app still support that particular Android version years after Google ended their support for Jelly Bean. We're also going to use the Windows XP analogy to understand Google's case for limiting these apps.

The first "target version" is something we commonly call as the minSdkVersion. Quite self-explanatory, isn't it? This attribute, found on the Android APK files are used to determine the bare minimum version of Android which can the app can run.

Sure, most app developers will always want to support as old versions as possible in order to reach as many devices as possible. But unfortunately, there's always technical challenges behind this, and they ultimately have to give up on the oldest version of Android the app can technically support.

And second, is the targetSdkVersion, which is commonly greater than minSdkVersion. This value, however, is used to note the youngest Android version the app developer have tested the app against. A simpler analogy to this is that "as the developer of this app, I guarantee that this will work on Android versions from minSdkVersion up to targetSdkVersion".

Since future versions of Android will introduce many breaking changes, the targetSdkVersion here is used on future Android versions to respectfully treat the app as the older defined version of Android to avoid new features and changes break the entire app experience.

For example, an app originally targeted for Android 10 will be respectully treated by Android 11, 12, 13, and so on as if the mobile device is running Android 10, albeit few technical and feature changes like app permissions.

But don't get me wrong, Gizmodo is already right by implicitly declaring that this restriction only works if the app's targetSdkVersion is lower than 23, i.e. Android 6.0 (Marshmallow).

If an app developer—even an independent one—isn’t writing their app to more recent source code than that, Android will deny installation.

https://gizmodo.com/android-14-6-block-old-apps-play-store-sideloading-pixe-1850025518

Compatibility concerns.

Sure, Android Marshmallow brings many significant technical improvements including Doze and fine-grained app permissions, which is also an added benefit for Android 14 by ensuring that every app must use fine-grained app permissions.

But rember that, once Android 14 is finally released, Android Marshmallow will be 8 years old! It's important that it would be very tiring for Google and Android developers to support Android versions beyond that, like the "XP" Android Jelly Bean which would become 11 years old.

Now, considering the age of these really, really old Android versions, you might be thinking, can Android and other OS developers always keep supporting these really old apps?

Just as those app developers who eventually give up supporting older versions of Android, the developers behind Android definitely want to give up supporting Android apps that, well, is only guaranteed to work on older Android versions.

Will every OEM adopt it?

The Gizmodo article said, "practically it's up to OEMs whether to block ancient apps or not in Android 14 and later." But my best guess is yes, every OEM will likely to adopt it as that means Google will no longer guarantee that Android 15, 16, and so on will still support those apps who are good for Android Lollipop and below, according to the app's defined targetSdkVersion. And Google can also enforce rules to make sure that every OEM should not bypass this restriction in any manner.

Just like when Windows 10 and 11 can't guarantee much that a software originally made for Windows XP and even 95 to run properly on their systems, even though Windows introduced "compatibility mode" because of naughty enterprises who stubbornly used these ancient programs to keep their businesses running on newer systems.

Conclusion: A threat to sideloading and Android's "open-source" ecosystem?

From that Gizmodo article again,

The Android mobile operating system has been around for a long time. But due to its openness and tinkerability, it’s developed a bit of a reputation for being risky to use if you’re not fully aware of its follies. That’s not good for Google, which is why the company seems to be constantly working to reduce that stigma through new features—and why it wants you only to download apps vetted through the Play Store.

With the next version of Android, you might not get as much freedom as you’re used to when installing apps you found on the web. But maybe this means Apple can finally stop using sideloading as an excuse for why Android is less safe than iOS.

If you ask whether this is a threat to sideloading and Android's platform openness, yes and no. But it's not fair to say that this restriction gives Google Play another competitive advantage. We believe that Google Play Store will also mark these, already-published ancient apps as "unavailable/incompatible for your device". Sure, this brings improved security on both sides: Google Play and sideloaded apps.

If you're afraid that apps like F-Droid no longer can be sideloaded because of this: the F-Droid client's targetSdkVersion is still set to Android 7.1 (which is still safe to install, of course) while the community is still struggling to raise that number. Remember that raising the value here is not just about editing the numbers, as the updated app must also be able to adapt with newer Android versions' changes and requirements.

Well, at the end of the day, it's the circle of life. You can find many more stories on how other OSes decided to drop support for really, really old apps.