Android Sdk Versions

[Francisca Noggles]

Theversion history of the Android mobile operating system began with the public release of its first beta on November 5, 2007. The first commercial version, Android 1.0, was released on September 23, 2008.

The operating system is developed by Google on a yearly cadence since at least 2011.[1] New major releases are announced at Google I/O in May while still in beta testing with the stable version usually released to the public between August and October.

The development of Android started in 2003 by Android, Inc., which was purchased by Google in 2005.[2] There were at least two internal releases of the software inside Google and the Open Handset Alliance (OHA) before the beta version was released.[3][4] The beta was released on November 5, 2007,[5][6] while the software development kit (SDK) was released on November 12, 2007.[7] Several public beta versions of the SDK were released.[8] These releases were done through software emulation as physical devices did not exist to test the operating system. Both the operating system itself and the SDK were released along with their source code, as free software under the Apache License.[9]

The first public release of Android 1.0 occurred with the release of the T-Mobile G1 (aka HTC Dream) in October 2008.[10] Android 1.0 and 1.1 were not released under specific code names.[11] The code names "Astro Boy" and "Bender" were tagged internally on some of the early pre-1.0 milestone builds and were never used as the actual code names of the 1.0 and 1.1 releases of the OS.[12]

The project manager, Ryan Gibson, conceived using a confectionery-themed naming scheme for public releases, starting with Android 1.5 Cupcake. Google announced in August 2019 they were ending the confectionery theming scheme to use numerical ordering for future versions.[13] The first release under the numerical order format was Android 10, which was released in September 2019.

In 2017, Google announced that Google Play would begin to require apps to target a recent Android version.[14] Since then, a new major Android version has been released in the second half of each year, and apps must target it by August 31 of the following year for new apps, or November 1 for app updates.[15]

The main hardware platform for Android is the 64-bit ARM architecture (i.e. ARMv8-A; previously the 32-bit ARMv7 architecture was supported and first ARMv5), with x86[d] and MIPS[e] architectures also officially supported in later versions of Android. MIPS support has since been deprecated and support was removed in NDK r17.[314]

In 2012, Android devices with Intel processors began to appear, including phones[316] and tablets. While gaining support for 64-bit platforms, Android was first made to run on 64-bit x86 and then on ARM64.[317][318] Since Android 5.0 Lollipop, 64-bit variants of all platforms are supported in addition to the 32-bit variants.

I've just tried to run my app compiled using Java 8 on an Android 4.0 device. While I'm used to taking great care to look at the Android API levels in the Android documentation to make sure I'm only using APIs that are available on Android 4.0, I'm not so used to making sure I'm not using any features in Java itself that aren't available on Android 4.0.

This makes me wonder: Is there an overview which clearly shows which Android versions come with which Java version? e.g. how can I find out the first Android version that supports Java 7? And how can I find out the first Android version that supports Java 8?

This really must be easy to find but I'm just failing to see it. Googling always leads to results in which people are asking about the Java versions supported by Android Studio, not by Android itself.

By your definition, Android does not support any version of Java. The java and javax classes in the Android SDK do not exactly match any version of Java, whether a numerical version (e.g., 6, 7, 8) or whatever you want to consider Java SE/EE/ME to be.

Here, "Android Studio" is really referring to the build tools that compile your source code and create the Dalvik bytecode. Current tools can support all Java 7 and a few Java 8 features on all versions of Android. Additional Java 8 features are only available on API Level 24+, usually because they rely upon certain classes that were only added to the Android SDK at that point.

Moreover, you are using reflection to hack into framework classes, which means your results will not only vary by Android version but by device model, as device manufacturers can and do change the implementation of framework classes.

The documentation does not presently (Feb 2022) make any correlation between Android >=9.0 and JDK (that I could find); I suspect this has been overlooked since it does not appear that the setup documentation has been thoroughly updated since sometime prior to the Ubuntu 20.04 LTS release. It does mention that the latest master branch (Android 12.0.0_r32) comes with a prebuilts folder that has the necessary JDK in it.

My mother had a shopping app on her old smartphone which runs Android v6. Recently I noticed that the app on her phone was no longer supported. I've seen such things happen on old phones generally with many apps. I just wanted to know, why do companies drop their support to older OS versions after few years? Does it cost them a lot to continue the support to older OS versions as well? Does it require a whole team to be hired to just keep managing the support for older OS? Just being curious about this. Thanks.

The second option is of course very costly as you have to develop maintain each app app version independently (or at least large parts of the app). This way is often not used or only if the app has been completely rewritten for new devices and for old devices the old version remains with minimal to no support.

Developers/companies (referred to as just "developer" from now on) can choose to support older version, but it gets hard to maintain that code. Speaking as a developer, it can be difficult to remember what settings or commands mean to different versions of an OS. Some of these differences are even deprecated (disapproved of) or completely removed from the newer SDKs, which makes it difficult or impossible to maintain backwards compatibility. And sometimes it's removed because of good reasons, usually meaning that it has significant security issues.

And just because the app is dropped, it doesn't mean that there isn't a newer version available. Some companies may rewrite their software completely (for various reasons including getting rid of large amounts of unnecessary legacy code), then post it as a separate app, leaving the previous version available as their idea of backwards compatibility.

In fact, most non-mobile software development is done like this. The old version is still available somewhere when a new version is released. Mobile stores like Google and Apple don't have an easy way for a user to get older versions, even though the developer can still see those old versions.

A company may also decide that their method of communication (protocols) need to be updated to newer specifications that aren't available in old versions of the SDK. If you have an app written in an old SDK that works with old phones, but you need/decide to upgrade those protocols to a security version the old version just doesn't support, you may have to remove some backwards compatibility to get access to the newer standards in a newer SDK. And if you're going to completely rewrite an app, it makes more sense to do it in the latest SDK, rather than one that'll be completely out dated again in 1-2 years.

Even just rewriting an app to clean it up, remove unnecessary functionality, redo the user interface/user experience (UI/UX), or 100 other reasons, using the most recent SDK also makes the most sense.

The Answer I linked to above talks about 25% of Twitter users being ignored because of platform changes due to an upgraded app. Well, those 25% are the older phones that will likely be the fastest shrinking group of phones around. They will eventually be broken, dropped, the battery ruined with no replacements available, or a 1000 other reasons, including other apps ceasing to support them. I'm not saying it's a good move to remove that many users from using your app all at once, but evidently they thought they could survive it.

As Internet Explorer (IE), Edge, Gecko, Firefox, Safari, and others have fallen out of use, developers stop doing as much cross-browser compatibility. As someone who's done that as well, it's a total PITA, especially when a requirement is pixel perfect compatibility, which is pretty much impossible. I have 5 browsers installed because of this reason, yet I only use 1 for browsing.

Some companies will insist on supporting IE and Edge, because "it's installed as the default on computers and most of our users don't know to install something else". It doesn't matter how few people actually use IE or Edge, because "the statistics are taken from sites where most users are devs or higher level computer users". But the reality is that the majority of browsers aren't worth the time to support. People don't support Netscape Navigator anymore, even if there is someone still running Win 3.11 for Workgroups, Win 98SE, or Mac OS 8.5.

Sometimes this is strictly a "make more money" ideal, in that the developer wants to force you to buy the new version, but that's not always the case. It makes more sense to developers to spend more time on new features and relevant bugs in a new version than new features and bugs in the old version.

To make this happen, the developers of Android change the programming APIs little by little as new versions come out. New ways of doing things are added, and old ways of doing things are removed over time. Bugs in the APIs that older software depended on are fixed, and no effort is put in to maintaining the old behavior to maintain compatibility.

Doing this forces app makers to constantly maintain their software and release newer versions of it with minor changes. It costs more money to tweak the software so that it works on older versions of Android as well as the latest release at the same time. To maintain compatibility across major versions differences of Android, multiple versions of the app may have to be maintained and distributed separately. This would become quite costly, and since most everyone has a newer device, the market to justify the extra expense just isn't there.

3a8082e126