Tag: Android P

A new commit in the Chrome OS Gerrit suggests that Android P framework testing is already underway for the platform.  This could allow for P support to roll out at the same time or very close the release of the update for phones later this year.

As readers may know, Android apps in Chrome OS run in Android Framework, which was updated to Nougat last December in Chrome 61 but, interestingly, the Oreo framework never rolled out.  The reason for the skip isn’t clear but it could have simply been focus shifting to get as many Chromebook builds updated to run Android in general.  The number of Chromebooks supporting Android apps has significantly increased over the course of the last year, in particular the last four months.

The framework is what allows Android apps to run in Chrome OS and for developers, gives them a standard API level across Android devices and Chromebooks so their apps will run on both and with the same feature sets.

As to be expected, the dominant Android news this week has been the release of the first developer preview for Android P.  While the code is still considered alpha and not near completion, you can already pick out areas of important changes in the upcoming release.

One minor change that has surfaced is a slightly revamped Pixel Launcher.  The Pixel Launcher was introduced with the original Pixel phones and Android Nougat.  It was tweaked slightly on the Pixel 2 lineup and Oreo and appears again to be set for a minor tweak with Android P and, presumably, the Pixel 3 lineup.  But you can try it out today on any phone.

As they did with the release of Android Oreo, we now have a rough timeline of the scheduled releases of Android P.  First, the not-so-shocking news.  It is going to be Q3 of this year before the public release of Android P happens. That falls right in line with previous Android releases and fits with the expected release of the next generation of Pixel phones.

With the release of the first developer preview today, it looks like the next one isn’t going to drop until early in May.  That, again, isn’t shocking.  Google’s developer conference, Google I/O, happens the first week in May.  When DP2 gets here, it is expected to be available to the Android Beta program for registered and supported devices.

In a somewhat unexpected move, Google has released the first Developer Preview of Android P, the next major version of the platform.  While it was expected to be released this month, perhaps even on 3/14 (Pi… get it?), it seems that the wait for this alpha build was much shorter than expected.

Before going into the details of what is new in this build, let me first be very clear.  This build is alpha.  It is not going to be stable and, in fact, is not even supported in the Android beta program.  In order to get it, you have to side-load it so it is really intended for app developers only.  If you really, really, really want to download it, you can do so here but brace yourself.  It is not going to be a smooth experience.  Also, keep in mind that this alpha build is only available for the Pixel, Pixel XL, Pixel 2 and Pixel 2 XL.

Although we are still weeks away from the first Developer Preview of Android P, more details of what will be in the next major release of the platform continue to come to light.  The latest is native support for iris scanning for biometric security.

A new commit points to iris identification to be supported within P, something that manufactures like Samsung have added to their devices.  This change should make it much easier for manufactures to add iris security support to their devices and it should be more reliable.

Yesterday I posted on the discovery of a code commit in Android P that prevents idle apps (those running in the background) from gaining access to your phone’s camera.  This is a security measure and one that, until this point, Android hasn’t properly addressed.  Now it seems there is a new commit that limits access to your phone’s microphone too.

The new commit has strikingly similar language to that of the commit found yesterday.

If a UID is in an idle state we don’t allow recording to protect user’s privacy. If the UID is in an idle state we allow recording but report empty data (all zeros in the byte array) and once the process goes in an active state we report the real mic data. This avoids the race between the app being notified aboout (sp) its lifecycle and the audio system being notified about the state of a UID.

This commit, like the one yesterday, essentially cuts off any app trying to gain access at a base level within Android.