Android OS (1.0 ➡️17)

[limmk]

 

[Shutterbox]

My first android phone is Motorola Droid.
Satki slider keyboard

 

[Purikura]

My first Android phone is Motorola Atrix.

 

[limmk]

 

[Sunny Day Song]

Kit Kat has always been peak Android for me

simple interface and doesn't take up too much RAM

 

[limmk]

In years past, every deep dive into Android has unearthed a wealth of new functions, features, and alterations. So, what is causing Android updates to feel smaller than ever?

“Small” is a little subjective. From the perspective of most people, visual and function changes are becoming less prominent. Android is undergoing bigger changes beneath the surface. Prep work for future updates is happening, and it doesn’t seem to make a dent in the front-facing UI or areas you’d ordinarily notice.

While wheels are in motion and AI will play a big part, how did we get here, and what will the future hold?

Beginnings, reaching maturity, and a plateauing platform​

The simple answer is that Android is a fully mature operating system at this point in time.

Google has been the sole owner of Android since 2005, but it started off in scrappy fashion. The first device to ship with the OS installed was the HTC Dream in 2008. The iPhone 3G was already helping propel Apple to a massive market share, but the Dream helped lay the foundations for what we now know as Android.

It was important to get this new OS on as many devices as possible, but it led to major problems with fragmentation as OEMs and carriers were intent on putting their own spin on the core system. The need for standardization was crucial. Since the launch of Project Treble in 2017, we’ve seen lots of improvements across every smartphone from practically every manufacturer. This is just a modular base for Android that speeds up the process of development by providing an almost complete version of the OS that you can tweak as necessary.

With HTC dropping out of the space and other players also toning things down, we’re in a better place. Most third-party skins offer similar key functions and mostly visual takes on what Google has laid out as a framework for Android with each yearly AOSP release.

Since those early days, we’ve had a few inflection points.

The Lollipop update was one such change. It introduced the world to Material Design with vibrant colors, bold typefaces, and a completely flat interface that introduced clean animations. This was the biggest and most extensive change to how Android looked and felt in November 2014. It wasn’t perfect, but Android needed a refresher at the time to move away from a bit of a nerdy, hacky feel.

This was iterated on for years until Android 10. By this point, things were starting to get a little stale. Go back and test drive an Android 11-powered device, and you’ll see what I mean. Sure, things are functional, and there are some changes we’d love to see reverted. Quick Settings toggles were almost perfect back then.

However, Android 12 and the introduction of Material You in 2021 was another major inflection point. It has offered the biggest departure from the “old” Android. From a pure user-facing perspective, this was a huge overhaul. Some things were removed, but huge new features were added.

Android 13, 14, and 15 have come and gone, each favoring under-the-hood changes rather than functionality-altering user-facing changes. Android 15 probably feels more like Android 12.5 to someone who isn’t versed in the minutiae of the OS.

Changes aren’t immediately noticeable now, but the groundwork has been laid for bigger things in the future.

So why are updates getting smaller?​

One answer could be that we are already at “peak smartphone.”

When we look at the form factor, the “slab phone” hasn’t evolved too drastically in the past five or six years. It has a touchscreen, some cameras, and an OS. Sure, we see more form factors, but the flip-and-fold style hasn’t hit mass appeal like regular phones.

Android and iOS are very mature. Look at desktop operating systems as a precursor example. They have barely changed since the 1980s. It’s a display with a graphical interface, pointer, and keyboard input. Touchscreens have made some headway, but these aren’t great for true productivity.

Like desktop computing, our mobile operating systems have probably already reached a plateau. We can only increase the quality of the components within our devices—better screens, better cameras, and a better overall experience.

Another answer could be that Android is becoming more modular.

Android 10 introduced Mainline. This allows some system components to be altered or updated outside of the yearly release cadence. It also addressed some of the fragmentation issues seen in older versions because Google can bypass OEMs by pushing Play System updates to keep your devices secure and safe.

Mainline is just part of the puzzle.

Google has also placed a greater emphasis on and relied on Play Service updates over the past few years. This major change is visible with features like Quick Share (formerly Nearby Share) and Theft Protection. You don’t need to update your device to get access. A Play Service update is pushed, and you can access new functions without a full system OTA. In isolation, these are huge features that would ordinarily be headline additions to a large system upgrade. Instead, they are just regular things added to most phones running Android 6.0 or higher.

The only confusing aspect is the crossover from QPR Beta updates. There is often overlap with the next platform release, so you may get something that was originally intended for the next OS version early as part of a Pixel Drop. It’s a little convoluted, but it means that—again—some more functionality breaks free of those yearly updates.

Pixel phones are the apex of Google’s efforts with Android. In essence, these phones are becoming vehicles for Google’s OS skin. The Pixel lineup gets unique functions that you might get on other phones later down the line. Pixel Drops (formerly Pixel Feature Drops) also drop ship new functions outside of huge yearly updates.

They are stuffed to the brim, and you might receive changes that alter the look and feel of your phone every three months.

Google is chipping away at the old model of huge changes in one big release, and while it diminishes the excitement somewhat. We get more in bite-sized chunks rather than a huge deluge just once per year.

Apps and AOSP​

As I alluded to earlier, we’re 17 years into the Android operating system. The early years were full of iteration, implementation, and updates to the core experience.

Now it’s: refine, nip, tuck, and enhance.

One of the biggest benefits of choosing a phone today is that you can buy a phone or tablet from Samsung, OnePlus, Xiaomi, Oppo, and others with more confidence that these OEMs will offer support beyond a few months. Many are even offering extensive update schedules to match Google’s 7-year update promise. Sure, not everyone is doing as well, but the “big” players are trying to improve with every release.

It’s also important to note that AOSP is not what it once was. Google has been hard at work creating its own version of Android specifically to help differentiate the Pixel series from the other hardware on the market. Because most of the true software innovation is behind us, many once-innovative functions are now available on practically every smartphone.

For brands, unique apps are pushing the boundaries. A great example of this is Samsung DeX. Not many Android makers have a dedicated desktop mode, but Samsung has led the charge. On Pixel phones, there are functions like Hold for Me, Call Screen, and a growing list that isn’t available on other hardware. Every OEM is adding their own little apps to help give their devices an edge.

Smartphones peaked a long time ago and save the growing foldable phone space; we are seeing incremental updates across the board.

Android 15 mainly offers quality-of-life changes and enhancements to existing functions. Many of the features that were on Pixel 9 are not locked into the latest update—rather, they have added functions locked to the hardware.

To make matters worse, the Pixel 9 launched with last year’s Android 14 release. It was practically identical to what you’d find on Pixel 6, 7, and 8 series handsets, apart from an updated Pixel Weather app, plus Pixel Studio and Pixel Screenshots.

​

 

[limmk]

 

[limmk]

 

[limmk]

 

[limmk]

七年之痒

 

[limmk]

TL;DR

• Google has confirmed to Android Authority that development of the Android operating system will soon fully happen in private.
• Currently, Google shares some of the work it does on the public AOSP Gerrit, but moving forward, this work will all be done in private.
• The goal for this privatization is to simplify Android OS development and not to hinder external developers, which is why Google remains committed to publishing source code to AOSP after each release.

No matter the manufacturer, every Android phone has one thing in common: its software base. Manufacturers can heavily customize the look and feel of the Android OS they ship on their Android devices, but under the hood, the core system functionality is derived from the same open-source foundation: the Android Open Source Project. After over 16 years, Google is making big changes to how it develops the open source version of Android in an effort to streamline its development.

The Android Open Source Project, or AOSP for short, is an operating system that Google releases under the Apache 2.0 License. Apache 2.0 is a software license that allows anyone to use, distribute, or modify and distribute operating systems based on AOSP without the need to pay any licensing fees or release source code. This permissive licensing structure has facilitated the widespread adoption of AOSP, leading to the creation of customized forks like Samsung’s One UI.

Like many other open-source projects, AOSP accepts code contributions from third-party developers. However, Google conducts most AOSP development itself, as it “treats the Android project as a full-scale product development operation” to “ensure the vitality of Android as a platform and as an open-source project.” Therefore, Google has the final say on what code can be merged into AOSP and when new version source code is released. The company develops AOSP components privately to allow “developers and OEMs to use a single version [of Android] without tracking unfinished future work just to keep up.”

A screenshot of the landing page for the Android Open Source Project.
To balance AOSP’s open nature with its product development strategy, Google maintains two primary Android branches: the public AOSP branch and its internal development branch. The AOSP branch is accessible to anyone, while Google’s internal branch is restricted to companies with a Google Mobile Services (GMS) licensing agreement.

While some OS components, such as Android’s Bluetooth stack, are developed publicly in the AOSP branch, most components, including the core Android OS framework, are developed privately within Google’s internal branch. Google confirmed to Android Authority that it will soon shift all Android OS development to its internal branch, a change intended to streamline its development process.

To simplify Android OS development, Google will no longer have two ‘main’ branches​

Because Google develops large portions of Android in its internal branch, the public AOSP branch often lags far behind what’s available privately. This difference is apparent when comparing feature and API availability between a clean AOSP build and Google’s latest Android 16 beta, which was built from its internal branch. While the shift to trunk-based development reduced this discrepancy, it persists and continues to pose challenges for Google.

This discrepancy forces Google to spend time and effort merging patches between the public AOSP branch and its internal branch. Due to how different the branches are, merge conflicts often arise. Take for example this patch that enables screen magnifier functionality for the navigation bar and keyboard. The patch introduces a new accessibility setting, which is placed at the end of the list of accessibility settings. This creates a merge conflict as the list’s length varies between AOSP and Google’s internal branch. While a fix for this specific issue is straightforward, numerous other AOSP patches trigger similar merge conflicts when integrated into Google’s internal branch.

Likewise, developing Android’s new unlocked-only storage area API required a Google engineer to cherry-pick a patch from the internal branch to AOSP to resolve a merge conflict. This is because while the API was developed in AOSP, the file containing new Android build flags was developed internally. As a result, a patch updating the build flag files had to be submitted internally and then applied to AOSP.

There are likely countless examples of merge conflicts like this, which is why Google is doing away with its current two-pronged Android development strategy and instead shifting all development internally.

What does this mean for us?​

Google confirmed to Android Authority that it is committed to publishing Android’s source code, so this change doesn’t mean that Android is becoming closed-source. The company will continue to publish the source code for new Android releases, so when Google releases Android 16 later this year, we’ll get the source code for the update. In addition, Google will continue to publish the source code for Android’s Linux kernel fork, as it is licensed under GPLv2, which mandates source code releases, and is separate from AOSP.

What will change is the frequency of public source code releases for specific Android components. Some components like the build system, update engine, Bluetooth stack, Virtualization framework, and SELinux configuration are currently AOSP-first, meaning they’re developed fully in public. Most Android components like the core OS framework are primarily developed internally, although some features, such as the unlocked-only storage area API, are still developed within AOSP.

 

[limmk]

A screenshot of the AOSP Gerrit, the web-based code review system used by Google.
Beginning next week, all Android development will occur within Google’s internal branches, and the source code for changes will only be released when Google publishes a new branch containing those changes. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch.

This change will have minimal impact on regular users. While it streamlines Android OS development for Google, potentially affecting the speed of new version development and bug reduction, the overall effect will likely be imperceptible. Therefore, don’t expect this change to accelerate OS updates for your phone.

This change will also have minimal impact on most developers. App developers are unaffected, as it pertains only to platform development. Platform developers, including those who build custom ROMs, will largely also see little change, since they typically base their work on specific tags or release branches, not the main AOSP branch. Similarly, companies that release forked AOSP products rarely use the main AOSP branch due to its inherent instability.

LineageOS 22.2 is based on the AOSP android-15.0.0_r20 release tag, which contains the latest changes in the March 2025 quarterly release.

External developers who enjoy reading or contributing to AOSP will likely be dismayed by this news, as it reduces their insight into Google’s development efforts. Without a GMS license, contributing to Android OS development becomes more challenging, as the available code will consistently lag behind by weeks or months. This news will also make it more challenging for some developers to keep up with new Android platform changes, as they’ll no longer be able to track changes in AOSP.

For reporters, this change means less access to potentially revealing information, as AOSP patches often provide insights into Google’s development plans. For instance, a code change I spotted in AOSP revealed the Pixel’s webcam feature months before its official release. Similarly, I used hints in AOSP to deduce Android 16’s earlier release date, while a now-deleted code change I spotted last week gave us our first public mention of the upcoming Google Pixel 10. While these types of leaks likely did not trigger this change, it will undoubtedly affect our ability to report on upcoming Android features and devices.

---

Ultimately, I think this change makes sense, even if the optics look bad for Google. Google had three options here: Maintain the status quo, shift all development internally, or make all development public. Considering Google’s stated rationale for private Android development and its recent transition to trunk-based development, its decision to consolidate work under a single, internal branch, streamlining both OS development and source code releases, is understandable.

Google will share more details about this change when it announces it later this week. If you’re interested in learning more, be sure to keep an eye out for the announcement and new documentation on source.android.com.

 

[limmk]

 

[limmk]

一针见血

 

[limmk]

 

[limmk]

TL;DR

• Google has raised the requirement for how much flash storage Android devices must have in order to pass the company’s certification program.
• Starting with Android 15, devices must ship with at least 32GB of storage, 75% of which must be allocated to the data partition.
• Android 15 also includes some other new requirements, such as requiring telephony devices to support sharing emergency contacts with emergency services and requiring chipsets to support Vulkan 1.3.

While the best Android phones include at least 128GB of internal storage, many budget-friendly phones offer considerably less. Some Android devices even ship with as little as 16GB of storage, a significant portion of which the Android operating system occupies. Despite Google’s efforts to compress Android and its mobile apps for low-end hardware, 16GB of storage doesn’t provide much space for apps, resulting in a poor user experience. That’s why Google recently increased the minimum storage requirement for Android devices.

Starting with Android 15, Google now requires Android devices to have at least 32GB of internal storage. Google mandates that 75% of this 32GB must be allocated to the data partition, which stores preinstalled system apps, system app data, certain system files, and crucially, all user apps and files. This doubles the previous minimum flash storage requirement of 16GB, introduced with Android 13 in 2022. Consequently, devices with less than 32GB of storage cannot upgrade to Android 15, as Google’s new requirement applies to both new and upgrading devices.

Android OS Version	Flash Storage Size Requirement	Data Partition Size Requirement
Android 15	32GB or higher	75% of total storage size or higher
Android 14	16GB or higher	75% of total storage size or higher
Android 13	16GB or higher	75% of total storage size or higher
Android 12	8GB or higher	75% of total storage size or higher

Google can’t legally prevent manufacturers from building smartphones with less than 32GB of storage so long as those phones use the open source version of Android (AOSP), as AOSP’s licensing terms don’t allow such restrictions. However, Google can enforce this requirement on companies seeking to ship Android smartphones with Google Mobile Services (GMS), as GMS is proprietary. The minimum flash storage size requirement is specified in the confidential GMS Requirements document, a document outlining the rules devices must meet to obtain a GMS license. Most smartphone and tablet makers adhere to these rules because a GMS license is essential for success; without it, devices cannot ship with core Google apps like the Google Play Store and Google Play Services.

Google hopes that increasing the minimum flash storage size to 32GB will improve the user experience on low-end Android devices, which account for the majority of Android device sales worldwide. This change will provide more space for apps for both users and original equipment manufacturers (OEMs). However, increased storage capacity doesn’t guarantee faster storage speeds, and most of these devices will likely still use slower eMMC storage chips. This is understandable, though, since UFS chips are more expensive than eMMC chips, making their exclusion on budget hardware a common compromise.

 

[limmk]

What other new Android 15 requirements are there?​

In addition to the increased minimum flash storage size, Android 15 devices must meet other new requirements to pass GMS certification. While most of these new requirements are under the hood or apply only to chipset vendors rather than OEMs, one new requirement has significant safety implications for users.

Google states that cellular devices launching with Android 15 or later must offer users the option to share their emergency contacts data with the system’s Emergency Location Service during emergency calls. This feature allows users to opt in to share their emergency contacts along with location data when contacting emergency services. This enables emergency services to more easily reach out to emergency contacts for updates or additional information. To protect user privacy, Google mandates a clear disclosure about what information may be shared with emergency services and requires blocking contact data sharing unless the user opts in.

Another key new requirement is that Android 15 mandates that new chipsets support Vulkan 1.3 or higher, and comply with the Android Baseline 2022 profile and Vulkan Profile for Android 15. Furthermore, devices running Android 15 or later (excluding those running Android Go Edition) must include ANGLE libraries and provide a way for app developers to use these libraries as replacements for the native OpenGL ES driver. ANGLE essentially translates older OpenGL ES calls to Vulkan, enabling modern devices without native OpenGL ES drivers to support older apps and games. Google specifies that while these ANGLE libraries don’t need to be enabled by default in Android 15, they must be enabled by default in Android 16.

The Vulkan and ANGLE requirements in Android 15 aren’t surprising, especially given Google’s recent announcement that Vulkan is now the official graphics API for Android. Since the company aims to make Android a leading gaming platform, improving Vulkan API support is a key step. Therefore, Google is using GMS Requirements to gradually raise the standard for Vulkan API feature support on Android devices.

Google

The final requirement change worth noting is a slight adjustment to Android’s minimum RAM requirement. To receive GMS certification, Android 14 devices with 2GB of RAM must enable Android’s low memory optimizations (Android Go Edition). While Android 15 devices with 2GB of RAM can still receive GMS certification, this low memory optimization requirement now also applies to devices with 3GB of RAM. Currently, OEMs can choose whether devices with 4GB of RAM use Android’s low memory optimizations, but this may become mandatory in the next Android release. It’s good to see Google increase the minimum memory an Android device must have, as this specification significantly impacts user experience.

Android OS Version	Must use low RAM optimizations	Can optionally use low RAM optimizations	Cannot license GMS
Android 15	2GB or 3GB	4GB	< 2GB
Android 14	2GB	3GB	< 2GB
Android 13	2GB	3GB	< 2GB
Android 12	1GB or 2GB	N/A	< 1GB
Android 11	1GB	N/A	< 1GB
Android 10	512MB or 1GB	N/A	< 512MB

The rest of the new Android 15 requirements are either minor or not relevant to most users, but I’ve listed them below anyways for completeness:

• Chipsets that set ro.board.first_api_level or ro.board.api_level to 202404 and support any of the above CHRE functionality MUST declare the android.hardware.context_hub feature flag.
• Chipsets that set ro.board.first_api_level or ro.board.api_level to 202404 MUST support ID attestation.
• Chipsets that set ro.board.first_api_level or ro.board.api_level to 202404 MUST implement StrongBox when the underlying hardware supports it, Remote Provisioning v3 HAL interface in the hardware instance on the AP which supports the primary KeyMint instance in order to provision KeyMint attestation keys, KeyMint 3.0 or higher HAL interface in secure hardware that has performance similar to the AP, and provide Android Profile for DICE support for the Remote Provisioning HAL interface.
• Chipsets that launch with Android 15 support (ro.board.first_api_level or ro.board.api_level to 202404) are STRONGLY RECOMMENDED to package each HAL in a vendor APEX. This will become MUST in Android 16.
• Chipsets that launch with Android 15 support and that support Bluetooth 5.0 or higher are STRONGLY RECOMMENDED to enable hearing aid support over Bluetooth LE for the ASHA protocol. This will become MUST in Android 16.
• Chipsets that launch with Android 15 support are STRONGLY RECOMMENDED to support Widevine L1 and include a corresponding secure decoder for every hardware AVC, HEVC, VP9, or AV1 decoder on the device. This will become MUST in 16.
• Remote Key Provisioning Mainline module is now STRONGLY RECOMMENDED to be preloaded in Android 15 but will become MUST in Android 16.

 

[limmk]

When trying to find out when your Pixel will get updates and support, you might be left frustrated that Google is being less explicit with end-of-life dates for the lineup.

Since the Pixel 8 series, Google has offered one of the most extensive support windows for any Android phone, matched only by Samsung and Apple. That is obviously good for longevity, but it appears that Google quietly removed explicit support window timeframes for Pixel devices back when Pixel 6 and 7 owners had a surprise increase to device updates – which could account for the lack of mention of this in coverage of this change at the time.

When looking into the updates for the brand-new Pixel 9a, it was immediately clear to us that this could cause some unwanted confusion.

Prior to the change late last year, the page clearly outlined the guaranteed update windows for various Pixel generations. For instance, the Pixel 9 series had August 2031 listed as the timeframe for when it could be considered “end of life.”

A visit to the same support page now reveals a different picture. Seven years of updates for the Pixel 8 series and newer do remain prominently displayed — encompassing OS upgrades, security patches, and even potential Pixel Drops — but the specific end dates (in table format) for software support are conspicuously absent. This seven-year commitment is listed as starting “from when the device first became available on the Google Store in the US.”

Pixel 8 and later phones will get updates for seven years starting from when the device first became available on the Google Store in the US.
This includes seven years of OS and security updates, and may also include new and upgraded features with Pixel Drops.

Historical data from the Wayback Machine indicates this shift occurred on December 5th, 2024. Examining an archived version of the support page from that date confirms the presence of explicit end dates for older Pixel phones, information that is no longer directly available on the current iteration. It was previously displayed in a table with exact end dates for each model in the lineup and those that are no longer given regular updates.

old explicit support page​

new support pages​

Interestingly, Google implemented a redirect. Instead of finding end-of-life dates on the main update policy page, users are directed to a separate page that confirms the initial availability date for specific Pixel devices. This new page provides the starting point for calculating the update window or timeframe.

Extended support for newer Pixels is undoubtedly a win, but we have to say that the removal of clear end dates for older and future models from the main support page introduces an unnecessary degree of ambiguity. We’ve built out the table again if you don’t have time to work it out for yourself:

Phone	Guaranteed Android version updates until at least:	Guaranteed security updates until at least:
Pixel 9a	April 2032	April 2032
Pixel 9 Pro Fold	August 2031	August 2031
Pixel 9 Pro XL	August 2031	August 2031
Pixel 9 & 9 Pro	August 2031	August 2031
Pixel 8a	May 2031	May 2031
Pixel 8 & 8 Pro	October 2030	October 2030
Pixel Fold	June 2028	June 2028
Pixel 7a	May 2028	May 2028
Pixel 7 & Pixel 7 Pro	October 2027	October 2027
Pixel 6a	July 2027	July 2027
Pixel 6 & 6 Pro	October 2026	October 2026

Without this, Pixel owners will now need to be more proactive in referencing the device availability dates to understand their phone’s remaining update lifespan, which just adds to consumer confusion. It could be that this gives Google more room to expand updates like the company did with the Pixel 6 and 7 series. That said, it’s simply not clear why this change was made in the first place.

 

[limmk]

 

[limmk]

At the start of April, Google released the latest Android distribution numbers. The last update was 11 months earlier, with Android 15 making its debut in these stats.

As of April 1, Android 15 is on 4.5% of devices. The new version was released to AOSP at the start of September. This should includes stable releases from Pixel (mid-October), OnePlus, and Nothing. During this period, Samsung was beta testing One UI 7, but it only just launched in recent weeks.

The majority of devices — 27.4% — are still running Android 14.

Android version	Percentage
15 / V	4.5%
14 / U	27.4%
13 / T	16.8%
12 / S	12.8%
11 / R	15.9%
10 / Q	10.2%
9 / Pie	5.8%
8.1 / Oreo	3.0%
8 / Oreo	1.0%
7.1 / Nougat	0.6%
7 / Nougat	0.6%
6 / Marshmallow	0.7%
5.1 / Lollipop	0.5%
5 / Lollipop	0.1%
4.4 / KitKat	0.1%

Meanwhile, Android 16 is expected as early as June for Pixel devices.

At this point, Google releases distribution stats once or twice a year via Android Studio. It’s based on the number of devices that connected to the Play Store within a seven-day period.