Tag Archives: Android O

Improving urban GPS accuracy for your app

Posted by Frank van Diggelen, Principal Engineer and Jennifer Wang, Product Manager

At Android, we want to make it as easy as possible for developers to create the most helpful apps for their users. That’s why we aim to provide the best location experience with our APIs like the Fused Location Provider API (FLP). However, we’ve heard from many of you that the biggest location issue is inaccuracy in dense urban areas, such as wrong-side-of-the-street and even wrong-city-block errors.

This is particularly critical for the most used location apps, such as rideshare and navigation. For instance, when users request a rideshare vehicle in a city, apps cannot easily locate them because of the GPS errors.

The last great unsolved GPS problem

This wrong-side-of-the-street position error is caused by reflected GPS signals in cities, and we embarked on an ambitious project to help solve this great problem in GPS. Our solution uses 3D mapping aided corrections, and is only feasible to be done at scale by Google because it comprises 3D building models, raw GPS measurements, and machine learning.

The December Pixel Feature Drop adds 3D mapping aided GPS corrections to Pixel 5 and Pixel 4a (5G). With a system API that provides feedback to the Qualcomm® Snapdragon™ 5G Mobile Platform that powers Pixel, the accuracy in cities (or “urban canyons”) improves spectacularly.

Picture of a pedestrian test, with Pixel 5 phone, walking along one side of the street, then the other. Yellow = Path followed, Red = without 3D mapping aided corrections, Blue = with 3D mapping aided corrections. The picture shows that without 3D mapping aided corrections, the GPS results frequently wander to the wrong side of the street (or even the wrong city block), whereas, with 3D mapping aided corrections, the position is many times more accurate.

Picture of a pedestrian test, with Pixel 5 phone, walking along one side of the street, then the other. Yellow = Path followed, Red = without 3D mapping aided corrections, Blue = with 3D mapping aided corrections.

Why hasn’t this been solved before?

The problem is that GPS constructively locates you in the wrong place when you are in a city. This is because all GPS systems are based on line-of-sight operation from satellites. But in big cities, most or all signals reach you through non line-of-sight reflections, because the direct signals are blocked by the buildings.

Diagram of the 3D mapping aided corrections module in Google Play services, with corrections feeding into the FLP API. 3D mapping aided corrections are also fed into the GNSS chip and software, which in turn provides GNSS measurements, position, and velocity back to the module.

The GPS chip assumes that the signal is line-of-sight and therefore introduces error when it calculates the excess path length that the signals traveled. The most common side effect is that your position appears on the wrong side of the street, although your position can also appear on the wrong city block, especially in very large cities with many skyscrapers.

There have been attempts to address this problem for more than a decade. But no solution existed at scale, until 3D mapping aided corrections were launched on Android.

How 3D mapping aided corrections work

The 3D mapping aided corrections module, in Google Play services, includes tiles of 3D building models that Google has for more than 3850 cities around the world. Google Play services 3D mapping aided corrections currently supports pedestrian use-cases only. When you use your device’s GPS while walking, Android’s Activity Recognition API will recognize that you are a pedestrian, and if you are in one of the 3850+ cities, tiles with 3D models will be downloaded and cached on the phone for that city. Cache size is approximately 20MB, which is about the same size as 6 photographs.

Inside the module, the 3D mapping aided corrections algorithms solve the chicken-and-egg problem, which is: if the GPS position is not in the right place, then how do you know which buildings are blocking or reflecting the signals? Having solved this problem, 3D mapping aided corrections provide a set of corrected positions to the FLP. A system API then provides this information to the GPS chip to help the chip improve the accuracy of the next GPS fix.

With this December Pixel feature drop, we are releasing version 2 of 3D mapping aided corrections on Pixel 5 and Pixel 4a (5G). This reduces wrong-side-of-street occurrences by approximately 75%. Other Android phones, using Android 8 or later, have version 1 implemented in the FLP, which reduces wrong-side-of-street occurrences by approximately 50%. Version 2 will be available to the entire Android ecosystem (Android 8 or later) in early 2021.

Android’s 3D mapping aided corrections work with signals from the USA’s Global Positioning System (GPS) as well as other Global Navigation Satellite Systems (GNSSs): GLONASS, Galileo, BeiDou, and QZSS.

Our GPS chip partners shared the importance of this work for their technologies:

“Consumers rely on the accuracy of the positioning and navigation capabilities of their mobile phones. Location technology is at the heart of ensuring you find your favorite restaurant and you get your rideshare service in a timely manner. Qualcomm Technologies is leading the charge to improve consumer experiences with its newest Qualcomm® Location Suite technology featuring integration with Google's 3D mapping aided corrections. This collaboration with Google is an important milestone toward sidewalk-level location accuracy,” said Francesco Grilli, vice president of product management at Qualcomm Technologies, Inc.

“Broadcom has integrated Google's 3D mapping aided corrections into the navigation engine of the BCM47765 dual-frequency GNSS chip. The combination of dual frequency L1 and L5 signals plus 3D mapping aided corrections provides unprecedented accuracy in urban canyons. L5 plus Google’s corrections are a game-changer for GNSS use in cities,” said Charles Abraham, Senior Director of Engineering, Broadcom Inc.

“Google's 3D mapping aided corrections is a major advancement in personal location accuracy for smartphone users when walking in urban environments. MediaTek’s Dimensity 5G family enables 3D mapping aided corrections in addition to its highly accurate dual-band GNSS and industry-leading dead reckoning performance to give the most accurate global positioning ever for 5G smartphone users,” said Dr. Yenchi Lee, Deputy General Manager of MediaTek’s Wireless Communications Business Unit.

How to access 3D mapping aided corrections

Android’s 3D mapping aided corrections automatically works when the GPS is being used by a pedestrian in any of the 3850+ cities, on any phone that runs Android 8 or later. The best way for developers to take advantage of the improvement is to use FLP to get location information. The further 3D mapping aided corrections in the GPS chip are available to Pixel 5 and Pixel 4a (5G) today, and will be rolled out to the rest of the Android ecosystem (Android 8 or later) in the next several weeks. We will also soon support more modes including driving.

Android’s 3D mapping aided corrections cover more than 3850 cities, including:

  • North America: All major cities in USA, Canada, Mexico.
  • Europe: All major cities. (100%, except Russia & Ukraine)
  • Asia: All major cities in Japan and Taiwan.
  • Rest of the world: All major cities in Brazil, Argentina, Australia, New Zealand, and South Africa.

As our Google Earth 3D models expand, so will 3D mapping aided corrections coverage.

Google Maps is also getting updates that will provide more street level detail for pedestrians in select cities, such as sidewalks, crosswalks, and pedestrian islands. In 2021, you can get these updates for your app using the Google Maps Platform. Along with the improved location accuracy from 3D mapping aided corrections, we hope we can help developers like you better support use cases for the world’s 2B pedestrians that use Android.

Continuously making location better

In addition to 3D mapping aided corrections, we continue to work hard to make location as accurate and useful as possible. Below are the latest improvements to the Fused Location Provider API (FLP):

  • Developers wanted an easier way to retrieve the current location. With the new getCurrentLocation() API, developers can get the current location in a single request, rather than having to subscribe to ongoing location changes. By allowing developers to request location only when needed (and automatically timing out and closing open location requests), this new API also improves battery life. Check out our latest Kotlin sample.
  • Android 11's Data Access Auditing API provides more transparency into how your app and its dependencies access private data (like location) from users. With the new support for the API's attribution tags in the FusedLocationProviderClient, developers can more easily audit their apps’ location subscriptions in addition to regular location requests. Check out this Kotlin sample to learn more.



Qualcomm and Snapdragon are trademarks or registered trademarks of Qualcomm Incorporated.

Qualcomm Snapdragon and Qualcomm Location Suite are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

Double Stuffed Security in Android Oreo

Posted by Gian G Spicuzza, Android Security team

Android Oreo is stuffed full of security enhancements. Over the past few months, we've covered how we've improved the security of the Android platform and its applications: from making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, making Android easier to update, all the way to doubling the Android Security Rewards payouts. Now that Oreo is out the door, let's take a look at all the goodness inside.

Expanding support for hardware security

Android already supports Verified Boot, which is designed to prevent devices from booting up with software that has been tampered with. In Android Oreo, we added a reference implementation for Verified Boot running with Project Treble, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool features to make updates easier and more secure, such as a common footer format and rollback protection. Rollback protection is designed to prevent a device to boot if downgraded to an older OS version, which could be vulnerable to an exploit. To do this, the devices save the OS version using either special hardware or by having the Trusted Execution Environment (TEE) sign the data. Pixel 2 and Pixel 2 XL come with this protection and we recommend all device manufacturers add this feature to their new devices.

Oreo also includes the new OEM Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more flexibility for how they protect whether a device is locked, unlocked, or unlockable. For example, the new Pixel phones use this HAL to pass commands to the bootloader. The bootloader analyzes these commands the next time the device boots and determines if changes to the locks, which are securely stored in Replay Protected Memory Block (RPMB), should happen. If your device is stolen, these safeguards are designed to prevent your device from being reset and to keep your data secure. This new HAL even supports moving the lock state to dedicated hardware.

Speaking of hardware, we've invested support in tamper-resistant hardware, such as the security module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents many software and hardware attacks and is also resistant to physical penetration attacks. The security module prevents deriving the encryption key without the device's passcode and limits the rate of unlock attempts, which makes many attacks infeasible due to time restrictions.

While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo are required to implement key attestation. This provides a mechanism for strongly attesting IDs such as hardware identifiers.

We added new features for enterprise-managed devices as well. In work profiles, encryption keys are now ejected from RAM when the profile is off or when your company's admin remotely locks the profile. This helps secure enterprise data at rest.

Platform hardening and process isolation

As part of Project Treble, the Android framework was re-architected to make updates easier and less costly for device manufacturers. This separation of platform and vendor-code was also designed to improve security. Following the principle of least privilege, these HALs run in their own sandbox and only have access to the drivers and permissions that are absolutely necessary.

Continuing with the media stack hardening in Android Nougat, most direct hardware access has been removed from the media frameworks in Oreo resulting in better isolation. Furthermore, we've enabled Control Flow Integrity (CFI) across all media components. Most vulnerabilities today are exploited by subverting the normal control flow of an application, instead changing them to perform arbitrary malicious activities with all the privileges of the exploited application. CFI is a robust security mechanism that disallows arbitrary changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.

In addition to these architecture changes and CFI, Android Oreo comes with a feast of other tasty platform security enhancements:

  • Seccomp filtering: makes some unused syscalls unavailable to apps so that they can't be exploited by potentially harmful apps.
  • Hardened usercopy: A recent survey of security bugs on Android revealed that invalid or missing bounds checking was seen in approximately 45% of kernel vulnerabilities. We've backported a bounds checking feature to Android kernels 3.18 and above, which makes exploitation harder while also helping developers spot issues and fix bugs in their code.
  • Privileged Access Never (PAN) emulation: Also backported to 3.18 kernels and above, this feature prohibits the kernel from accessing user space directly and ensures developers utilize the hardened functions to access user space.
  • Kernel Address Space Layout Randomization (KASLR): Although Android has supported userspace Address Space Layout Randomization (ASLR) for years, we've backported KASLR to help mitigate vulnerabilities on Android kernels 4.4 and newer. KASLR works by randomizing the location where kernel code is loaded on each boot, making code reuse attacks probabilistic and therefore more difficult to carry out, especially remotely.

App security and device identifier changes

Android Instant Apps run in a restricted sandbox which limits permissions and capabilities such as reading the on-device app list or transmitting cleartext traffic. Although introduced during the Android Oreo release, Instant Apps supports devices running Android Lollipop and later.

In order to handle untrusted content more safely, we've isolated WebView by splitting the rendering engine into a separate process and running it within an isolated sandbox that restricts its resources. WebView also supports Safe Browsing to protect against potentially dangerous sites.

Lastly, we've made significant changes to device identifiers to give users more control, including:

  • Moving the static Android ID and Widevine values to an app-specific value, which helps limit the use of device-scoped non-resettable IDs.
  • In accordance with IETF RFC 7844 anonymity profile, net.hostname is now empty and the DHCP client no longer sends a hostname.
  • For apps that require a device ID, we've built a Build.getSerial() API and protected it behind a permission.
  • Alongside security researchers1, we designed a robust MAC address randomization for Wi-Fi scan traffic in various chipsets firmware.

Android Oreo brings in all of these improvements, and many more. As always, we appreciate feedback and welcome suggestions for how we can improve Android. Contact us at [email protected].

_____________________________________________________________________

1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven

Welcoming Android 8.1 Oreo and Android Oreo (Go edition)

Posted by Dave Burke, VP of Engineering

At Google for India this Monday, we announced the final release of Android 8.1 Oreo. Android 8.1 Oreo is another exciting step toward bringing to life our vision of an AI-first mobile platform, for everyone, everywhere.

Android 8.1 introduces support for our new Android Oreo (Go edition) software experience for entry-level devices. Android Oreo (Go edition) brings the best of Android to the rapidly growing market for low-memory devices around the world, including your apps and games.

Android 8.1 also introduces the Neural Networks API, a hardware accelerated machine learning runtime to support ML capabilities in your apps. On supported devices, the Neural Networks API enables fast and efficient inference for a range of key use cases, starting with vision-based object classification.

You can get started with Android 8.1 Oreo (API level 27) today. We're pushing sources to Android Open Source Project now, and rolling out the update to supported Pixel and Nexus devices over the next week. We're also working with our device maker partners to bring Android 8.1 to more devices, including Android Oreo (Go edition) devices, in the months ahead.

Android Oreo (Go edition)

As announced at Google I/O 2017, the "Android Go" project is our initiative to optimize the Android experience for billions of people coming online around the world. Starting with Android 8.1, we're making Android a great platform for entry-level devices in the Android Oreo (Go edition) configuration:

  • Memory optimizations -- Improved memory usage across the platform to ensure that apps can run efficiently on devices with 1GB or less RAM.
  • Flexible targeting options -- New hardware feature constants to let you target the distribution of your apps to normal or low-RAM devices through Google Play.
  • Optimized Google apps: Rebuilt and optimized versions of Google apps, using less memory, storage space, and mobile data.
  • Google Play: While all apps will be available on Android Oreo (Go edition) devices, Google Play will give visibility to apps specifically optimized by developers to provide a great experience for billions of people with the building for billions guidelines.

We've updated the building for billions guidelines with additional guidance on how to optimize your app for Android Oreo (Go edition) devices. For most developers, optimizing your existing APK or using Google Play's Multiple APK feature to target a version of your APK to low-RAM devices is the best way to prepare for Android Oreo (Go edition) devices. Remember that making your app lighter and more efficient benefits your whole audience, regardless of device.

Neural Networks API

The Neural Networks API provides accelerated computation and inference for on-device machine learning frameworks like TensorFlow Lite -- Google's cross-platform ML library for mobile -- as well as Caffe2 and others. TensorFlow Lite is now available to developers, so visit the TensorFlow Lite open source repo for downloads and docs. TensorFlow Lite works with the Neural Networks API to run models like MobileNets, Inception v3, and Smart Reply efficiently on your mobile device.

Autofill enhancements and more

Android 8.1 includes select new features and developer APIs (API level 27), along with the latest optimizations, bug fixes, and security patches. Extend your app with Autofill enhancements, a SharedMemory API, and more. You can also add established Android Oreo features as well, see the Android Oreo site for details.

Test your apps on Android 8.1

If haven't already, take a few moments today to test your apps and make sure they offer the experience you want for users upgrading to Android 8.1 Oreo.

Just install your current app from Google Play onto a device or emulator running Android Oreo and test the user flows. The app should run and look great, and handle the Android Oreo behavior changes properly. In particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.

Speed your development with Android Studio

To build with Android 8.1, we recommend updating to Android Studio 3.0, which is now available from the stable channel. On top of the new app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop for Android Oreo features like Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

With the final platform we're updating the SDK and build tools in Android Studio, as well as the API Level 27 emulator system images. We recommend updating to the Android Support Library 27.0.2, which is available from Google's Maven repository. See the version notes for details on what's new.

As always, we're providing downloadable factory and OTA images on the Nexus Images page to help you do final testing on your Pixel and Nexus devices.

Publish your updates to Google Play

When you're ready, you can publish your APK updates targeting API level 27 in your alpha, beta, or production channels. Make sure that your updated app runs well on Android Oreo as well as older versions. We recommend using beta testing to get early feedback from a small group of users and a pre-launch report to help you identify any issues, then do a staged rollout. Head over to the Android Developers site to find more info on launch best practices. We're looking forward to seeing your app updates!

What's next for Android Oreo?

We'll soon be closing the Developer Preview issue tracker, but please keep the feedback coming! If you still see an issue that you filed in the preview tracker, just file a new issue against Android 8.1 in the AOSP issue tracker. You can also continue to give us feedback or ask questions in the developer community.

Android Things Developer Preview 5

Posted by Wayne Piekarski, Developer Advocate for IoT

Today, we're releasing Developer Preview 5 (DP5) of Android Things, which includes the major change of being based on the upcoming Android O release. Android Things is Google's platform to enable Android Developers to create Internet of Things (IoT) devices, and seamlessly scale from prototype to production.

Android O

Android O is currently under Developer Preview for phones and tablets, and DP5 is now based on this upcoming release (previous releases were based on Android N). This means that your future Android Things applications should target API 26 to work correctly on the platform with our support libraries.

Hardware Changes

DP5 now adds support for the new NXP SprIoT i.MX6UL design, as listed in our developer kits documentation. With Intel discontinuing the Edison and Joule hardware designs, these platforms are moving to legacy support. They will not continue to receive the latest platform updates, but developers may continue to access the DP4.1 system images from the Android Things Console.

An important goal of Android Things is to help developers seamlessly scale from prototype to production. When we exit Developer Preview, we will differentiate between hardware platforms targeted for prototyping-only and hardware reference designs that can scale to production. Production-ready hardware will satisfy Google's security requirements and include long term support from the silicon manufacturers. We will have more to share later on.

Improvements

With the move to the Android O codebase, there are new API features from Android as well as specific features for Android Things. For those developers using UserDriver APIs, you will need to add new permissions to your AndroidManifest.xml. The documentation contains details about the permissions needed for each driver type. DP5 also now supports OpenGL ES 2.0 and WebView on the Raspberry Pi 3, which was a highly requested feature from developers. We have also implemented dynamic pin muxing for the Raspberry Pi 3, with pins being configured at runtime depending on what features are being used.

Android Studio

The samples for Android Things are now available directly in Android Studio for browsing and importing. You can now go to File, New, Import Samples, and search for Things to see everything that is available. We have a wide range of samples, demonstrating how to interact with buttons, sensors, LEDs, and displays, as well as implementing Google Assistant and TensorFlow.

Android Things Console

We recently launched the Android Things Console, which provides the ability to support over-the-air updates (OTA) to Android Things devices. We have recently made a number of UX improvements to the console to improve usability and functionality. DP5 is now available within the Android Things Console, but the DP5 update will not be pushed automatically to devices without your intervention. You will need to update your application for DP5, then create a new update and push it via the console yourself.

Feedback

With Android Things being updated to Android O, significant changes have been made to the platform. Please send us your feedback by filing bug reports and feature requests, and asking any questions on Stack Overflow. To start using DP5, use the Android Things Console to download system images and update existing devices. More information about the changes are available in the release notes. You can also join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas. Also, we have our new hackster.io community, where everyone can share the amazing projects they have built!

What’s new for shortcuts and widgets in Android O

Posted by Gloria Liou, Associate Product Manager Intern


Why use shortcuts and widgets?


One of our favorite features in Android O is the ability to pin shortcuts and widgets for your app onto the launcher through deep linking.


Shortcuts let users quickly start a specific task, while widgets give users instant access to specific actions and information from your app. Users want to get things done, and get things done fast - shortcuts and widgets are a way to help them and to increase user engagement with your content.

To pin a shortcut or widget, users long press your app's icon for options and drag and drop the selected item to a location of their choice.


Dynamic / static shortcuts
Pinned shortcuts






Adding shortcuts and widgets from within your app




 The API has a new flow for adding shortcuts and widgets from within your app. The new method uses a modal dialog, deprecating the old method of using a broadcast, which will not work on O devices.

That's not all. We've made improvements to the user interface and experience. In the old experience, there was no app icon on the shortcut, so users had no idea which app the shortcut was from. Marking shortcuts with the app icon provides better branding while protecting users from potential malware.





Old shortcut
New shortcut



There is also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.



With these new additions and improvements, users will be more likely to use your shortcuts and widgets, leading to more meaningful and impactful engagement with your app and happier, more productive users.

To learn more, head over to the shortcuts and widgets page on the Android Developers website.


Developer Preview 4 now available, official Android O coming soon!

Posted by Dave Burke, VP of Engineering

As we put the finishing touches on the Android O platform, today we're rolling out Developer Preview 4 to help you make sure your apps are ready.

This is the final preview before we launch the official Android O platform to consumers later this summer. Take this opportunity to wrap up your testing and publish your updates soon, to give users a smooth transition to Android O.

If you have a device that's enrolled in the Android Beta Program, you'll receive an update to Developer Preview 4 in the next few days. If you haven't enrolled your device yet, just visit the Android Beta site to enroll and get the update.

Watch for more information on the official Android O release soon!

What's in this update?

Developer Preview 4 is a release candidate build of Android O that you can use to complete your development and testing in time for the upcoming official release. It includes the final system behaviors, the latest bug fixes and optimizations, and the final APIs (API level 26) already available since Developer Preview 3.

We're releasing the Developer Preview 4 device system images today, together with the stable version of the Android 26.0.0 Support Library. Incremental updates to the SDK, tools, and Android Emulator system images are on the way over the next few days.

We're also introducing a new version of Android Testing Support Library that includes new features like Android Test Orchestrator, Multiprocess Espresso, and more. Watch for details coming soon.

Test your apps on Android O

Today's Developer Preview 4 system images give you an excellent way to test your current apps on the near-final version of Android O. By testing now, you can make sure your app offers the experience you want as users start to upgrade to the official Android O platform.

Just enroll a supported device in the Android Beta Program to get today's update over-the-air, install your current app from Google Play, and test the user flows. The app should run and look great, and should handle the Android O behavior changes properly -- in particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.

Once you've resolved any issues, publish your app updates with the current targeting level, so that they're available as users start to receive Android O.

Enhance your apps with Android O features and APIs

Users running the latest versions of Android are typically among the most active in terms of downloading apps, consuming content, and making purchases. They're also more vocal about support for the latest Android features in their favorite apps. With Android O, users are anticipating features like notification channels and dots, shortcut pinning, picture-in-picture, autofill, and others. These features could also help increase engagement with your app as more users upgrade to Android O over time.

With Android O your app can directly pin a specific app shortcut in the launcher to drive engagement.
Notification dots keep users active in your app and let them jump directly the app's core functions.

Enhancing your apps with Android O features can help you drive engagement with users, offer new interactions, give them more control and security, and improve performance. Features like adaptive icons, downloadable fonts, and autosizing TextView can simplify your development and minimize your APK size. Battery is also a top concern for users, so they'll appreciate your app being optimized for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Speed your development with Android Studio

When you're ready to build for Android O, we recommend updating to the latest version of Android Studio 3.0, available for download from the canary channel. Aside from improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Instant Apps, XML Fonts, Downloadable Fonts, and Adaptive Icons.

We also recommend updating to the stable version of the Android Support Library 26.0.0, available now from Google's Maven repository, and to the latest SDK, tools, and emulator system images, available over the next few days.

You can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to setup your environment to build with Android O.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 26. When you're ready, you can publish your APK updates in your alpha, beta, or production channels.

Make sure that your updated app runs well on Android O as well as older versions. We recommend using Google Play's beta testing feature to get early feedback from a small group of users. Then do a staged rollout. We're looking forward to seeing your app updates!

How to get Developer Preview 4

It's simple to get Developer Preview 4 if you haven't already! Just visit android.com/beta and opt-in your eligible phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, Nexus Player, and the Android Emulator. Enrolled devices will automatically update when we release the official version of Android O.

Thanks for all of your input throughout the preview. Continue to share your feedback and requests, we love it!

Android O APIs are final, get your apps ready!

Posted by Dave Burke, VP of Engineering

Three weeks ago at Google I/O, we announced the second developer preview of Android O along with key themes, Fluid Experiences and Vitals, and highlighted our work towards a modular base with Project Treble. It was also an important milestone for us with the release of the first beta-quality candidate. We talked a lot about what's new in Android during the keynote and breakout sessions—if you missed the livestream, be sure to check out the full archive of talks here.

Today we're rolling out Developer Preview 3 with the final Android O APIs, the latest system images, and an update to Android Studio to help you get ready for the consumer release later in the summer. Watch for one more preview update coming in July that will bring you the near-final system images.

If you've already enrolled your device in the Android Beta Program, you'll receive an update to Developer Preview 3 shortly.

Make your app compatible with Android O

With the consumer launch approaching in the coming months, a critical first step is making your current app compatible with Android O. This will give your users a seamless transition to the new platform as it arrives on their devices.

If you haven't tested your app for compatibility yet, getting started is straightforward -- just enroll a supported device in Android Beta and get the latest update over-the-air, then install your current app from Google Play and test. The app should run and look great, and it should handle the Android O behavior changes properly -- in particular pay attention to background limits and changes in networking, security, and identifiers.

After you've made any necessary updates, we recommend publishing the compatible version of your app to Google Play right away -- without changing the app's platform targeting.

Enhance your app with Android O features and APIs

Extending your apps with Android O features can help you drive more engagement, offer new interactions, give users more control and security, and even improve your app's performance.

Notification channels and dots give you more ways to surface new content to users and bring them back into your app. Picture-in-picture keeps your app onscreen while users are multitasking, and autofill makes it simple for them to enter forms data and helps keep their data secure. Also check out adaptive icons, XML font resources, downloadable fonts and emoji, autosizing TextView, AAudio API, and many others. You'll also want plan your support for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Picture-in-Picture mode lets you keep users engaged while they are multitasking (left). Notification dots keep users active in your app and let them jump directly the app’s core functions (right).

Get started with Developer Preview 3

Today's preview update includes the latest version of the Android O platform with the final API level 26 and hundreds of bugfixes and optimizations. You can download the final API 26 SDK from the SDK Manager in Android Studio, and Android Support Library 26.0.0 beta 2 from Google's Maven repository.

Together, these give you everything you need to develop and test your apps with the official Android O APIs. Once you've installed the final SDK, you can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to set up your environment to build with Android O.

APIs have changed since the second developer preview, so if you have existing code using Android O preview APIs, take a look at the diff report to see where your code might be affected.

If you're developing for Android O, we recommend updating to the latest version of Android Studio 3.0, now available in the canary channel. Aside from great new features like improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 includes build support for Instant Apps, an Adaptive Icon Wizard, and support for XML Fonts, and Downloadable Fonts.

Android Studio 3.0 includes tools for developing with Android O features lets you preview XML font resources in your app.

If you don't plan to use those features, you now have the option of developing for Android O using Android Studio 2.3.3 from the stable channel. Note that the tools for working with adaptive icons and downloadable fonts, and XML fonts are not available in Android Studio 2.3.3.

Publish your apps to alpha, beta or production channels in Google Play

Now that the APIs are final, you can publish APK updates compiling with, and optionally targeting, API 26 to your alpha, beta, or even production channels in Google Play. Publishing your O-targeted app during the preview lets you test compatibility on existing devices and push updates to devices running API 26 -- such as users who are enrolled in the Android Beta program.

To make sure that your updated app runs well on Android O as well as older versions, a common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to get the preview update

Through the Android Beta program, developers and early adopters worldwide will soon be getting Developer Preview 3 on their devices. If you aren't yet enrolled, just visit android.com/beta and opt-in your eligible Android phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and Nexus Player.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. We're looking forward to seeing your apps on Android O!

What’s New in Android: O Developer Preview 2 & More

Posted by: Dave Burke, VP of Engineering

android-o-logo.png
With billions of Android devices around the world, Android has surpassed our wildest expectations. Today at Google I/O, we showcased a number of ways we’re pushing Android forward, with the O Release, new tools for developers to help create more performant apps, and an early preview of a project we call Android Go -- a new experience that we’re building for entry-level devices.
Fluid experiences in Android O
It's pretty incredible what you can do on mobile devices today, and how easy it is to rely on them as computers in our pockets. In the O release we've focused on creating fluid experiences that make Android even more powerful and easy to use, and today we highlighted some of those:
  • Picture-in-picture: lets users manage two tasks simultaneously, whether it’s video calling your friend while checking your calendar, or reading a new recipe while watching a video on a specific cooking technique. We’ve designed PIP to provide seamless multitasking on any size screen, and it’s easy for apps to support it.
  • Notification dots extend the reach of notifications, a new way for developers to surface activity in their app, driving engagement. Built on our unique and highly regarded notification system, dots work with zero effort for most apps - we even extract the color of the dot from your icon. 
  • Autofill with Google simplifies setting up a new device and synchronizing passwords by bringing Chrome's Autofill feature to Android. Once a user opts-in, Autofill will work out-of-the-box for most apps. Developers can optimize their apps for Autofill by providing hints about the type of data expected or add support in custom views. 
  • A new homescreen for Android TV makes it easy for users to find, preview, and watch content provided by apps. Apps can publish one or more channels, and users can control the channels that appear on the homescreen. You’ll be able to get started with creating channels using the new TvProvider support library APIs. 
  • Smart Text Selection: In Android O, we’re applying on-device machine learning to copy/paste, to let Android recognize entities like addresses, URLs, telephone numbers, and email addresses. This makes the copy/paste experience better by selecting the entire entity and surfacing the right apps to carry out an action based on the type of entity.
  • TensorFlow Lite: As Android continues to take advantage of machine learning to improve the user experience, we want our developer partners to be able to do the same. Today we shared an early look at TensorFlow Lite, an upcoming project based on TensorFlow, Google’s open source machine learning library. TensorFlow Lite is specifically designed to be fast and lightweight for embedded use cases. Since many on-device scenarios require real-time performance, we’re also working on a new Neural Network API that TensorFlow can take advantage of to accelerate computation. We plan to make both of these available to developers in a maintenance update to O later this year, so stay tuned!  
(L) Android O: Picture-in-picture, (R) Android O: Notification dots

Working on the Vitals in Android
We think Android’s foundations are critical, so we’re investing in Android Vitals, a project focused on optimizing battery life, startup time, graphic rendering time, and stability. Today we showcased some of the work we’ve done so far, and introduced new tools to help developers understand power, performance, and reliability issues in their apps:
  • System optimizations: in Android O, we’ve done a lot of work across the system to make apps run faster and smoother. For example we made extensive changes in our runtime - including new optimizations like concurrent compacting garbage collection, code locality, and more. 
  • Background limits: up to now it’s been fairly easy for apps to unintentionally overuse resources while they’re in the background, and this can adversely affect the performance of the system. So in O, we've introduced new limits on background location and wi-fi scans, and changes in the way apps run in the background. These boundaries prevent overuse -- they’re about increasing battery life and freeing up memory.
  • New Android Vitals Dashboards in the Play Console: today we launched six Play Console dashboards to help you pinpoint common issues in your apps - excessive crash rate, ANR rate, frozen frames, slow rendering, excessive wakeups, and stuck wake locks, including how many users are affected, with guidance on the best way to address the issues. You can visit the Play Console today to see your app's data, then learn how to address any issues.
Android Go
Part of Android’s mission is to bring computing to everyone. We’re excited about seeing more users come online for the first time as the price of entry level smart phones drop, and we want to help manufacturers continue to offer lower-cost devices that provide a great experience for these users. Today we gave a sneak peek of a new experience that we’re building specifically for Android devices that have 1GB or less of memory -- Internally we call it “Android Go,” and it’s designed around three things
  • OS: We’re optimizing Android O to run smoothly and efficiently on entry-level devices
  • Apps: We’re also designing Google apps to use less memory, storage space, and mobile data, including apps such as YouTube Go, Chrome, and Gboard. 
  • Play: On entry-level devices, Play store will promote a better user experience by highlighting apps that are specifically designed for these devices -- such as apps that use less memory, storage space, and mobile data -- while still giving users access to the entire app catalog.
The Android Go experience will ship in 2018 for all Android devices that have 1GB or less of memory. We recommend getting your apps ready for these devices soon -- take a look at the Building for Billions to learn about the importance of offering a useful offline state, reducing APK size, and minimizing battery and memory use.

O Developer Preview 2, Now in Public Beta
Today’s release of O Developer Preview 2 is our first beta-quality candidate, available to test on your primary phone or tablet. We’re inviting those who want to try the beta release of Android O to enroll now at android.com/beta -- it’s an incredibly convenient way to preview Android O on your Nexus 5X, 6P, and Player, as well as Pixel, Pixel XL, or Pixel C device.

With more users starting to get Android O on their devices through the Android Beta program, now is the time to test your apps for compatibility, resolve any issues, and publish an update as soon as possible. See the migration guide for steps and a recommended timeline.

Later today you’ll be able to download the updated tools for developing on Android O, including the latest canaries of Android Studio, SDK, and tools, Android O system images, and emulators. Along with those, you’ll be able to download support library 26.0.0 beta and other libraries from our new Maven repo. The change to Maven from SDK Manager means a slight change to your build configuration, but gives you much more flexibility in how you integrate library updates with your CI systems.

When you’re ready to get started developing with Android O, visit the O Developer Preview site for details on all of the features you can use in your apps, including notification channels and dots, picture-in-picture, autofill, and others. APIs have changed since the first developer preview, so take a look at the diff report to see where your code might be affected.

Thanks for the feedback you’ve given us so far. Please keep it coming, about Android O features, APIs, issues, or requests -- see the Feedback and Bugs page for details on where to report feedback.

Here comes Treble: A modular base for Android

Posted by Iliyan Malchev, Project Treble team lead

On the Android team, we view each dessert release as an opportunity to make Android better for our users and our ecosystem partners. One thing we've consistently heard from our device-maker partners is that updating existing devices to a new version of Android is incredibly time consuming and costly.

With Android O, we've been working very closely with device makers and silicon manufacturers to take steps toward solving this problem, and we're excited to give you a sneak peek at Project Treble, the biggest change to the low-level system architecture of Android to date.

Life of an Android Release

First, it's helpful to understand the "life of an Android release". There are several steps a new Android release goes through before getting into the hands of users:

  1. The Android team publishes the open-source code for the latest release to the world.
  2. Silicon manufacturers, the companies that make the chips that power Android devices, modify the new release for their specific hardware.
  3. Silicon manufacturers pass the modified new release to device makers -- the companies that design and manufacture Android devices. Device makers modify the new release again as needed for their devices.
  4. Device makers work with carriers to test and certify the new release.
  5. Device makers and carriers make the new release available to users.

    With Project Treble, we're re-architecting Android to make it easier, faster and less costly for manufacturers to update devices to a new version of Android.

    The Vendor Interface

    Android was unveiled in 2007 as a free, open-source mobile operating system. From the beginning, we intended Android to be scaled across a variety of manufacturers. We knew that consistency of API was important for developers, so we created a compatibility program for the Developer API specified by the Compatibility Definition Document (CDD) and its associated Compatibility Test Suite (CTS), now comprising over a million tests.

    The result today is that app developers can write a single app that works across over a billion devices running on different hardware from different manufacturers.

    Project Treble aims to do what CTS did for apps, for the Android OS framework. The core concept is to separate the vendor implementation - the device-specific, lower-level software written in large part by the silicon manufacturers - from the Android OS Framework. This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. The new vendor interface is validated by a Vendor Test Suite (VTS), analogous to the CTS, to ensure forward compatibility of the vendor implementation.

    Benefits of Project Treble

    Today, with no formal vendor interface, a lot of code across Android needs to be updated when a device moves to a newer version of Android:

    With a stable vendor interface providing access to the hardware-specific parts of Android, device makers can choose to deliver a new Android release to consumers by just updating the Android OS framework without any additional work required from the silicon manufacturers:

    Project Treble will be coming to all new devices launched with Android O and beyond. In fact, the new Project Treble architecture is already running on the Developer Preview of O for Pixel phones.

    In addition to the architectural changes, we're working with our silicon and device partners to take their code changes, such as features for a carrier network in a specific country, and move them into the common Android Open Source Project (AOSP) codebase. For example, Sony and Qualcomm contributed dozens of features and hundreds of bugfixes to Android O so they no longer need to rework these patches with each new release of Android.

    We plan to publish the full documentation for Project Treble on source.android.com with the launch of O later this summer.

Changes to Device Identifiers in Android O

Posted by Giles Hogben, Privacy Engineer

Android O introduces some improvements to help provide user control over the use of identifiers. These improvements include:

  • limiting the use of device-scoped identifiers that are not resettable
  • updating the Android O Wi-Fi stack in conjunction with changes to the Wi-Fi chipset firmware used by Pixel, Pixel XL and Nexus 5x phones to randomize MAC addresses in probe requests
  • updating the way that applications request account information and providing more user-facing control

Device identifier changes


Here are some of the device identifier changes for Android O:

Android ID


In O, Android ID (Settings.Secure.ANDROID_ID or SSAID) has a different value for each app and each user on the device. Developers requiring a device-scoped identifier, should instead use a resettable identifier, such as Advertising ID, giving users more control. Advertising ID also provides a user-facing setting to limit ad tracking.

Additionally in Android O:

  • The ANDROID_ID value won't change on package uninstall/reinstall, as long as the package name and signing key are the same. Apps can rely on this value to maintain state across reinstalls.
  • If an app was installed on a device running an earlier version of Android, the Android ID remains the same when the device is updated to Android O, unless the app is uninstalled and reinstalled.
  • The Android ID value only changes if the device is factory reset or if the signing key rotates between uninstall and reinstall events.
  • This change is only required for device manufacturers shipping with Google Play services and Advertising ID. Other device manufacturers may provide an alternative resettable ID or continue to provide ANDROID ID.

Build.SERIAL


To be consistent with runtime permissions required for access to IMEI, use of android.os.Build.SERIAL is deprecated for apps that target Android O or newer. Instead, they can use a new Android O API, Build.getSerial(), which returns the actual serial number, as long as the caller holds the PHONE permission. In a future version of Android, apps targeting Android O will see Build.SERIAL as "UNKNOWN". To avoid breaking legacy app functionality, apps targeting prior versions of Android will continue see the device's serial number, as before.

Net.Hostname


Net.Hostname provides the network hostname of the device. In previous versions of Android, the default value of the network hostname and the value of the DHCP hostname option contained Settings.Secure.ANDROID_ID. In Android O, net.hostname is empty and the DHCP client no longer sends a hostname, following IETF RFC 7844 (anonymity profile).

Widevine ID


For new devices shipping with O, the Widevine Client ID returns a different value for each app package name and web origin (for web browser apps).

Unique system and settings properties


In addition to Build.SERIAL, there are other settings and system properties that aren't available in Android O. These include:

  • ro.runtime.firstboot: Millisecond-precise timestamp of first boot after last wipe or most recent boot
  • htc.camera.sensor.front_SN: Camera serial number (available on some HTC devices)
  • persist.service.bdroid.bdaddr: Bluetooth MAC address property
  • Settings.Secure.bluetooth_address: Device Bluetooth MAC address. In O, this is only available to apps holding the LOCAL_MAC_ADDRESS permission.

MAC address randomization in Wi-Fi probe requests


We collaborated with security researchers1 to design robust MAC address randomization for Wi-Fi scan traffic produced by the chipset firmware in Google Pixel and Nexus 5X devices. The Android Connectivity team then worked with manufacturers to update the Wi-Fi chipset firmware used by these devices.

Android O integrates these firmware changes into the Android Wi-Fi stack, so that devices using these chipsets with updated firmware and running Android O or above can take advantage of them.

Here are some of the changes that we've made to Pixel, Pixel XL and Nexus 5x firmware when running O+:

  • For each Wi-Fi scan while it is disconnected from an access point, the phone uses a new random MAC address (whether or not the device is in standby).
  • The initial packet sequence number for each scan is also randomized.
  • Unnecessary Probe Request Information Elements have been removed: Information Elements are limited to the SSID and DS parameter sets.

Changes in the getAccounts API


In Android O and above, the GET_ACCOUNTS permission is no longer sufficient to gain access to the list of accounts registered on the device. Applications must use an API provided by the app managing the specific account type or the user must grant permission to access the account via an account chooser activity. For example, Gmail can access Google accounts registered on the device because Google owns the Gmail application, but the user would need to grant Gmail access to information about other accounts registered on the device.

Apps targeting Android O or later should either use AccountManager#newChooseAccountIntent() or an authenticator-specific method to gain access to an account. Applications with a lower target SDK can still use the current flow.

In Android O, apps can also use the AccountManager.setAccountVisibility()/ getVisibility() methods to manage visibility policies of accounts owned by those apps.

In addition, the LOGIN_ACCOUNTS_CHANGED_ACTION broadcast is deprecated, but still works in Android O. Applications should use addOnAccountsUpdatedListener() to get updates about accounts at runtime for a list of account types that they specify.

Check out Best Practices for Unique Identifiers for more information.


Notes

  1. Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven ↩