Perhaps the most longstanding problem Android has faced since the launch of the first Android phone in September 2008 is the erratic rollout of major version updates across OEMs. While advancements have been made since then—the introduction of Nexus and Android One devices, monthly security updates that include older branches of Android, and adding seamless updates in Nougat—the underlying problem of OEMs simply not updating phones persists, particularly for non-flagship, low-cost phones.
Project Treble, Google’s solution to this, was announced ahead of the 2017 Google I/O developer conference. Per Google’s announcement, Treble introduces a vendor interface that sits between the Android OS framework and vendor-supplied components, allowing device manufacturers to ship new Android versions without requiring silicon providers to provide updated drivers for components where support is not mainlined into AOSP, or the Linux kernel in general. Compatibility is assured using a vendor test suite (VTS), analogous to the compatibility test suite (CTS) already in use for app developers. While Google noted that the Pixel phones are already running a preview of Treble, this technology will generally be available only on phones that ship with Android O.
Google also said that specific changes such as support for “features for a carrier network in a specific country” have also been mainlined into AOSP during the development of Android O, along with specific bug fixes and other features now included in AOSP, preventing the need for hardware vendors to rework their inclusion as images are built for individual devices. Perhaps the most visible or, in this case, audible change is the inclusion of Qualcomm’s aptX and Sony’s LDAC codecs in AOSP.
The first developer preview of Android O, released in March, also introduced the beginnings of a theming engine for the OS. In this preview state, the theming engine appears to be limited to the notification shade and quick settings view. While it is unclear if this feature will be finished in time for the final release of Android O, a centralized theming system would make it easier for OEMs to customize Android to their liking, as well as provide end users the ability to use their own themes.
Additional security improvements in Android O
Android Marshmallow (6.0) added granular permissions, allowing users to grant specific permissions to apps as needed when the app is in use, rather than granting all necessary permissions at installation time. Previously, apps that required verification codes to be sent through SMS either required the user to manually copy and paste the verification code from an SMS app to the app requiring verification, or grant SMS access to the app requesting verification—unnecessarily providing the app with the entire SMS history on the device.
In Android O, apps can now request a single-use token for SMS use, which redirects the anticipated SMS verification message to the app itself, rather than the inbox of the device. This is handled through the new PendingIntent type createAppSpecificSmsToken, which does not require explicit SMS permissions to use. Accordingly, as the verification token is directed to the app, the device SMS inbox will not become cluttered with verification tokens.
Android O also brings robust support for password managers with the Autofill Framework. This adds the type Autofill Service to the default apps selection, and the work of detecting fillable fields has been offloaded from Autofill apps and password managers to the Android system itself, as well as app developers who wish to explicitly define fillable fields in their apps.
What do you want in Android O?
What features are on your wish list for Android O? Do you plan to use Android O developer preview builds on your device? Share your thoughts in the comments.