Category Archives: Android Developers Blog

An Open Handset Alliance Project

Improving app security and performance on Google Play for years to come

Posted by Edward Cunningham, Product Manager, Android

Google Play powers billions of app installs and updates annually. We relentlessly focus on security and performance to ensure everyone has a positive experience discovering and installing apps and games they love. Today we're giving Android developers a heads-up about three changes designed to support these goals, as well as explaining the reasons for each change, and how they will help make Android devices even more secure and performant for the long term.

  • In the second half of 2018, Play will require that new apps and app updates target a recent Android API level. This will be required for new apps in August 2018, and for updates to existing apps in November 2018. This is to ensure apps are built on the latest APIs optimized for security and performance.
  • In August 2019, Play will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions.
  • Additionally, in early 2018, Play will start adding a small amount of security metadata on top of each APK to further verify app authenticity. You do not need to take any action for this change.

We deeply appreciate our developer ecosystem, and so hope this long advance notice is helpful in planning your app releases. We will continue to provide reminders and share developer resources as key dates approach to help you prepare.

Target API level requirement from late 2018

API behavior changes advance the security and privacy protections of Android – helping developers secure their apps and protecting people from malware. Here are a few such changes from recent platform versions:

  • Implicit intents for bindService() no longer supported (Android 5.0)
  • Runtime permissions (Android 6.0)
  • User-added CAs not trusted by default for secure connections (Android 7.0)
  • Apps can't access user accounts without explicit user approval (Android 8.0)

Many of these changes only apply to apps that explicitly declare their support for new API behaviors, through the targetSdkVersion manifest attribute. For example, only apps with a targetSdkVersion of 23 (the API level of Android 6.0) or higher give the user full control over what private data – such as contacts or location – the app can access via runtime permissions. Similarly, recent releases include user experience improvements that prevent apps from accidentally overusing resources like battery and memory; background execution limits is a good example of this type of improvement.

In order to provide users with the best Android experience possible, the Google Play Console will require that apps target a recent API level:

  • August 2018: New apps required to target API level 26 (Android 8.0) or higher.
  • November 2018: Updates to existing apps required to target API level 26 or higher.
  • 2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher.

Existing apps that are not receiving updates are unaffected. Developers remain free to use a minSdkVersion of their choice, so there is no change to your ability to build apps for older Android versions. We encourage developers to provide backwards compatibility as far as reasonably possible. Future Android versions will also restrict apps that don't target a recent API level and adversely impact performance or security. We want to proactively reduce fragmentation in the app ecosystem and ensure apps are secure and performant while providing developers with a long window and plenty of notice in order to plan ahead.

This year we released Android Oreo, the most secure and best performing version of Android yet, and we introduced Project Treble to help the latest releases reach devices faster. Get started building apps that target Android 8.1 Oreo today.

64-bit support requirement in 2019

Platform support for 64-bit architectures was introduced in Android 5.0. Today, over 40% of Android devices coming online have 64-bit support, while still maintaining 32-bit compatibility. For apps that use native libraries, 64-bit code typically offers significantly better performance, with additional registers and new instructions.

In anticipation of future Android devices that support 64-bit code only, the Play Console will require that new apps and app updates are able to run on devices without 32-bit support. Apps that include a 32-bit library will need to have a 64-bit alternative – either within the same APK or as one of the multiple APKs published. Apps that do not include native code are unaffected.

This change will come into effect in August 2019. We're providing advance notice today to allow plenty of time for developers who don't yet support 64-bit to plan the transition. Stay tuned for a future post in which we'll take an in-depth look at the performance benefits of 64-bit native libraries on Android, and check out the CPUs and Architectures guide of the NDK for more info.

Security metadata in early 2018

Next year we'll begin adding a small amount of security metadata on top of each APK to verify that it was officially distributed by Google Play. Often when you buy a physical product, you'll find an official label or a badge which signifies the product's authenticity. The metadata we're adding to APKs is like a Play badge of authenticity for your Android app.

No action is needed by developers or users. We'll adjust Play's maximum APK size to take into account the small metadata addition, which is inserted into the APK Signing Block and does not alter the functionality of your app. In addition to enhancing the integrity of Play's mobile app ecosystem, this metadata will enable new distribution opportunities for developers in the future and help more people keep their apps up to date.

Looking ahead

2017 has been a fantastic year for developers who have seen growth and success on Google Play. We've been hard at work on features (including those announced at I/O 2017 and at Playtime) to help you improve your app quality and business performance. With these features and the upcoming updates, we hope to see the Android and Play ecosystem continue to thrive in 2018 and beyond.

How useful did you find this blogpost?

Quick Boot & the Top Features in the Android Emulator

Posted by Jamal Eason, Product Manager, Android

Today, we are excited to announce Quick Boot for the Android Emulator. With Quick Boot, you can launch the Android Emulator in under 6 seconds. Quick Boot works by snapshotting an emulator session so you can reload in seconds. Quick Boot was first released with Android Studio 3.0 in the canary update channel and we are excited to release the feature as a stable update today.

In addition to this new feature, we also wanted to highlight some of the top features from recent releases. Since the complete revamp of the Android Emulator two years ago, we continue to focus on improving speed, stability and adding a rich set of features that accelerate your app development and testing. With all the recent changes, it is definitely worth updating to the latest version of the Android Emulator to use it today.

Top 5 Features

  • Quick Boot - Released as a stable feature today, Quick Boot allows you to resume your Android Emulator session in under 6 seconds. The first time you start an Android Virtual Device (AVD) with the Android Emulator, it must perform a cold boot (just like powering on a device), but subsequent starts are fast and the system is restored to the state at which you closed the emulator last (similar to waking a device). We accomplished this by completely re-engineering the legacy emulator snapshot architecture to work with virtual sensors and GPU acceleration. No additional setup is required because Quick Boot is enabled by default starting with Android Emulator v27.0.2.

Quick Boot in the Android Emulator

  • Android CTS Compatibility - With each release of the Android SDK, we ensure that the Android Emulator is ready for your app development needs, from testing backwards compatibility with Android KitKat to integrating the latest APIs of the developer preview. To increase product quality and reliability of emulator system images, we now qualify final Android System Image builds from Android Nougat (API 24) and higher against the Android Compatibility Test Suite (CTS)—the same testing suite that official Android physical devices must pass.
  • Google Play Support - We know that many app developers use Google Play Services, and it can be difficult to keep the service up to date in the Android Emulator system images. To solve this problem, we now offer versions of Android System Images that include the Play Store app. The Google Play images are available starting with Android Nougat (API 24). With these new emulator images, you can update Google Play Services via the Play Store app in your emulator just as you would on a physical Android device. Plus, you can now test end-to-end install, update, and purchase flows with the Google Play Store.
  • Performance Improvements - Making the emulator fast and performant is an on-going goal for our team. We continuously look at the performance impact of running the emulator on your development machine, especially RAM usage. With the latest versions of the Android Emulator, we now allocate RAM on demand, instead of allocating and pinning the memory to the max RAM size defined in your AVD. We do this by tapping into the native hypervisors for Linux (KVM) and macOS® (Hypervisor.Framework), and an enhanced Intel® HAXM (v6.2.1 and higher) for Microsoft® Windows®, which uses the new on-demand memory allocation.
  • Additionally, over the last several releases, we have improved CPU and I/O performance while enhancing GPU performance, including OpenGL ES 3.0 support. Looking at a common task such as ADB push highlights the improvements in the Android CPU and I/O pipelines:

    ADB Push Speed Comparison with Android Emulator

    For GPU performance, we created a sample GPU emulation stress test app to gauge improvements over time. We found that the latest emulator can render higher frame rates than before, and it is one of the few emulators that can render OpenGL ES 3.0 accurately per the Android specification.

GPU Emulation Stress Test - Android App

GPU Emulation Stress Test with Android Emulator

More Features

In addition to these major features, there are a whole host of additional features that we have added to the Android Emulator over the last year that you may not be aware of:

  • Wi-Fi support - Starting with API 24 system images, you can create an AVD that both connects to a virtual cellular network and a virtual Wi-Fi Access Point.
  • Google Cast support - When using a Google Play system image, you can cast screen and audio content to Chromecast devices on the same Wi-Fi network.
  • Drag and drop APKs & files - Simply drag an APK onto the Android Emulator window to trigger an app install. Also you can drag any other data file and find it in the /Downloads folder in your Android Virtual Device.
  • Host copy & paste - You can copy & paste text between the Android Emulator and your development machine.
  • Virtual 2-finger pinch & zoom - When interacting with apps like Google Maps, hold down the Ctrl Key (on Microsoft® Windows® or Linux) or ⌘ (on macOS® ) , and a finger overlay appears on screen to aid with pinch & zoom actions.
  • GPS location - Manually select a GPS point or set of GPS points under the Location tab of the Android Emulator.
  • Virtual sensors - There is a dedicated page in the extended controls panel that has supported sensors in the Android Emulator including acceleration, rotation, proximity and many more.
  • WebCam support - You can use a webcam or your laptop built-in webcam as a virtual camera in the AVD. Validate your AVD camera settings in the Advanced Settings page in the AVD Manager.
  • Host machine keyboard - You can use your real keyboard to enter text into the Android Virtual Device.
  • Virtual SMS and phone calls - In the extended controls panel, you can trigger a virtual SMS or phone call to test apps with telephony dependencies.
  • Screen zooming - On the main toolbar, click on the magnify glass icon to enter zoom mode, and then select a region of the screen you want to inspect.
  • Window resizing - Simply drag a corner of the Android Emulator window to change to the desired size.
  • Network proxy support - Add a custom HTTP proxy for your Android Emulator session by going to the Settings page under the Proxy tab.
  • Bug reporting - You can quickly generate a bug report for your app by using the Bug Report section in the extended controls panel to share with your team or to send feedback to Google.

Learn more about the Android Emulator in the Emulator documentation.

Getting Started

All of these features and improvements are available to download and use now with Android Emulator v27.0.2+, which you can get via the SDK Manager in Android Studio. For a fast experience, we recommend creating and running the x86 version of emulator system images, with the latest Android Emulator, Intel® HAXM (if applicable) and graphics drivers installed.

We appreciate any feedback on things you like, issues or features you would like to see. If you find a bug, issue, or have a feature request feel free to file an issue. We are definitely not done, but we hope you are excited about the improvements so far.

LoWPAN on Android Things

Posted by Dave Smith, Developer Advocate for IoT

Creating robust connections between IoT devices can be difficult. WiFi and Bluetooth are ubiquitous and work well in many scenarios, but suffer limitations when power is constrained or large numbers of devices are required on a single network. In response to this, new communications technologies have arisen to address the power and scalability requirements for IoT.

Low-power Wireless Personal Area Network (LoWPAN) technologies are specifically designed for peer-to-peer usage on constrained battery-powered devices. Devices on the same LoWPAN can communicate with each other using familiar IP networking, allowing developers to use standard application protocols like HTTP and CoAP. The specific LoWPAN technology that we are most excited about is Thread: a secure, fault-tolerant, low-power mesh-networking technology that is quickly becoming an industry standard.

Today we are announcing API support for configuring and managing LoWPAN as a part of Android Things Developer Preview 6.1, including first-class networking support for Thread. By adding an 802.15.4 radio module to one of our developer kits, Android Things devices can communicate directly with other peer devices on a Thread network. These types of low-power connectivity solutions enable Android Things devices to perform edge computing tasks, aggregating data locally from nearby devices to make critical decisions without a constant connection to cloud services. See the LoWPAN API guide for more details on building apps to create and join local mesh networks.

Getting Started

OpenThread makes getting started with LoWPAN on Android Things easy. Choose a supported radio platform, such as the Nordic nRF52840, and download pre-built firmware to enable it as a Network Co-Processor (NCP). Integrate the radio into Android Things using the LoWPAN NCP user driver. You can also expand support to other radio hardware by building your own user drivers. See the LoWPAN user driver API guide for more details.

To get started with DP6.1, use the Android Things Console to download system images and flash existing devices. Then download the LoWPAN sample app to try it out for yourself! LoWPAN isn't the only exciting thing happening in the latest release. See the release notes for the full set of fixes and updates included in DP6.1.

Feedback

Please send us your feedback by filing bug reports and feature requests, as well as asking any questions on Stack Overflow. 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. We look forward to seeing what you build with Android Things!

Diagnose and understand your app’s GPU behavior with GAPID

Posted by Andrew Woloszyn, Software Engineer

Developing for 3D is complicated. Whether you're using a native graphics API or enlisting the help of your favorite game engine, there are thousands of graphics commands that have to come together perfectly to produce beautiful 3D images on your phone, desktop or VR headsets.

GAPID (Graphics API Debugger) is a new tool that helps developers diagnose rendering and performance issues with their applications. With GAPID, you can capture a trace of your application and step through each graphics command one-by-one. This lets you visualize how your final image is built and isolate problematic calls, so you spend less time debugging through trial-and-error.

GAPID supports OpenGL ES on Android, and Vulkan on Android, Windows and Linux.

Debugging in action, one draw call at a time

GAPID not only enables you to diagnose issues with your rendering commands, but also acts as a tool to run quick experiments and see immediately how these changes would affect the presented frame.

Here are a few examples where GAPID can help you isolate and fix issues with your application:

What's the GPU doing?

Why isn't my text appearing?!

Working with a graphics API can be frustrating when you get an unexpected result, whether it's a blank screen, an upside-down triangle, or a missing mesh. As an offline debugger, GAPID lets you take a trace of these applications, and then inspect the calls afterwards. You can track down exactly which command produced the incorrect result by looking at the framebuffer, and inspect the state at that point to help you diagnose the issue.

What happens if I do X?

Using GAPID to edit shader code

Even when a program is working as expected, sometimes you want to experiment. GAPID allows you to modify API calls and shaders at will, so you can test things like:

  • What if I used a different texture on this object?
  • What if I changed the calculation of bloom in this shader?

With GAPID, you can now iterate on the look and feel of your app without having to recompile your application or rebuild your assets.

Whether you're building a stunning new desktop game with Vulkan or a beautifully immersive VR experience on Android, we hope that GAPID will save you both time and frustration and help you get the most out of your GPU. To get started with GAPID and see just how powerful it is, download it, take your favorite application, and capture a trace!

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.

Tuning your apps and games for long screen devices

Posted by Fred Chung, Developer Advocate

In recent months, there's a growing trend for handset makers to ship new devices with long screen aspect ratio (stretching beyond 16:9), many of which also sport rounded corners. This attests to the Android ecosystem's breadth and choice. Pixel 2 XL and Huawei Mate 10 Pro are just two of many examples. These screen characteristics could bring a very immersive experience to users and they take notice of apps and games that don't take advantage of the long aspect ratio screen on these new devices. Therefore it is important for developers to optimize for these screen designs. Let's have a look at related support provided by the Android OS.

Optimize for long aspect ratio screens

Most apps using standard UI widgets will likely work out-of-the-box on these devices. Android documentation details techniques for flexibly working on multiple screen sizes. However, some games and apps with custom UIs may run into issues due to incorrect assumptions on certain aspect ratios. We're sharing a few typical issues faced by developers, so you can pay attention to those relevant to you:

  • Certain sides of the screen are cropped. This makes any graphic or UI elements in the affected regions look incomplete.
  • Touch targets are offset from UI elements (e.g. buttons). Users may be confused on UI elements that are seemingly interactive.
  • For full screen mode on rounded corners devices, any UI elements very close to the corners may be outside of the curved corner viewable area. Imagine if a commerce app's "Purchase" button was partially obstructed? We recommend referencing Material Design guidelines by leaving 16dp side margins in layouts.

If responsive UI is really not suitable for your situation, as a last resort declare an explicit maximum supported aspect ratio as follows. On devices with a wider aspect ratio, the app will be shown in a compatibility mode padded with letterbox. Keep in mind that certain device models provide an override for users to force the app into full-screen compatibility mode, so be sure to test under these scenarios too!

Targets API level 26 or higher: Use android:maxAspectRatio attributes.

Targets API level 25 or lower: Use android.max_aspect meta-data. Note that maximum aspect ratio values will be respected only if your activities don't support resizableActivity. See documentation for detail.

System letterboxes an app when the declared maximum aspect ratio is smaller than the device's screen.

Consider using side-by-side activities

Long aspect ratio devices enable even more multi-window use cases that could increase user productivity. Beginning in Android 7.0, the platform offers a standard way for developers to implement multi-window on supported devices as well as perform data drag and drop between activities. Refer to documentation for details.

Testing is crucial. If you don't have access to one of these long screen devices, be sure to test on the emulator with adequate screen size and resolution hardware properties, which are explained in the emulator documentation.

We know you want to delight your users with long screen devices. With a few steps, you can ensure your apps and games taking full advantage of these devices!

Android Things Developer Preview 6

Posted by Wayne Piekarski, Developer Advocate for IoT

The next release of Android Things Developer Preview 6 (DP6) is here with lots of new features and bug fixes. Android Things is Google's platform that enables Android Developers to create Internet of Things (IoT) devices with support for powerful applications such as video and audio processing and on-board machine learning with TensorFlow. For the specifics on what is new, visit the release notes. Here are a few of the highlights of what is in DP6.

IoT launcher

DP6 includes a new IoT launcher that allows the user to see the current state of the device and change settings using a touch screen or USB input devices. Settings such as configuring the WiFi, finding the build ID, and checking for updates is now something that can be done interactively, making it even easier to get started. This launcher is visible when no other developer-provided IOT_LAUNCHER Activity is present.

Graphics acceleration defaults

Android Things uses the open-source SwiftShader library, a CPU-based implementation of the OpenGL ES APIs. This enables common OpenGL support across all platforms, even those with no GPU hardware. However, many simple 2D UIs render faster if the drawing is done directly to the framebuffer and OpenGL emulation is not used. In DP6, OpenGL rendering is disabled by default to ensure that most apps run with the fastest UI possible. If you need OpenGL support for 3D rendering, WebView, or TextureView, then explicitly enable it in your AndroidManifest.xml according to the documentation:

<activity

    ...
    android:hardwareAccelerated="true">

API 27 and Google Play Services

DP6 is now based on the latest Android 8.1 developer preview, with API level 27. Most of the standard Android samples now work on DP6. For example, the Camera2Basic sample using the Camera2 API and TextureView now works on both NXP and Raspberry Pi based devices (with the hardwareAccelerated flag set to true). Google Play Services has been updated to support SDK version 11.6, supporting all the latest features.

Command-line flashing tool

We heard from developers that flashing and configuring a board using fastboot can be tedious, so the Android Things Console now brings a new and simpler way of flashing device images. Instead of using fastboot and adb commands manually, a new interactive command-line android-things-setup-utility is now provided. This tool makes it much easier to get started with Android Things, and automates the download and flashing process.

Android Things Console updates

DP6 introduces the new partition scheme that will be used for the upcoming production release. Due to the new partition layout, the over-the-air update (OTA) system cannot update existing DP5.1 or earlier devices. Developers will need to go to the Android Things Console, and download and flash a new DP6 build. The Console UI has also been changed for DP6 features, and will only allow you to create new builds based on DP6. If you have any older existing builds, they are still available for download but will not support OTA updates. Developers are encouraged to move all work to DP6.

GPIO pin naming

The interactive IoT launcher shown at boot now includes an I/O pinout section where you can discover the labels of all the pins. The pin naming used by the i.MX7 has been changed, and you should update your code to use this new naming convention. See the i.MX7 documentation for the complete list of pin names.

Settings and Device Update APIs

New APIs have been added to Android Things that control the configuration of the local device and device updates. UpdateManager gives developers control over when updates and reboots can be performed, ensuring the device is available for the user when needed. DeviceManager controls factory reset, reboot, and device locales. APIs are also provided for settings such as ScreenManager to control the screen, and TimeManager to control the clock and time zone.

Peripheral command-line tool

We now provide a command-line tool pio that gives developers access to the Peripheral API via the adb shell. Developers can interactively test GPIO, PWM, UART, I2C, SPI, and future interfaces from an adb shell, which is useful for debugging and automated testing.

Feedback

DP6 includes significant changes and improvements to the platform. Please send us your feedback by filing bug reports and feature requests, as well as asking any questions on Stack Overflow. To start using DP6, use the Android Things Console to download system images and flash existing devices, or use the android-things-setup-utility. 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. We look forward to seeing what you build with Android Things!

Delve deeper into Android development with our new course!

Posted by Jocelyn Becker, Senior Program Manager, Google Developer Training

If you know the basics of building Android apps and want to delve deeper, take a look at our new Advanced Android Development course built by the Google Developers Training team.

Do you want to learn how to use fragments, add widgets for your app, and fine tune your app's performance? Make your app available to a diverse user base through localization and accessibility features? Use sensors in your app? How about creating custom views, drawing directly to the screen and running animations?

Each lesson in our new course takes you through building an app that illustrates an advanced concept, from incorporating maps into your app to using a SurfaceView to draw outside the main UI thread.

This course is intended for experienced Java programmers who already know the fundamentals of building Android apps. It is a follow-on course to our Android Developer Fundamentals course. The course is intended to be taught as instructor-led training. However, all the materials are published online and are available to anyone who wants to learn more advanced concepts of Android development.

We have published detailed written tutorials, concept guides, slide decks, and most importantly, a treasure trove of apps in GitHub. You can find links to everything at developers.google.com/training/android-advanced.

Educational institutions worldwide are invited to use this course to teach your students. Individual developers are welcome (and encouraged) to work through the tutorials to learn on their own.

Each lesson presents a different, advanced topic, and you can teach or learn each topic independently of the others.

Build apps as you learn how to use sensors, add places to your app, and draw directly to a canvas. And much more!

The new course covers:

  • using fragments
  • building widgets
  • using sensors
  • measuring and improving application performance
  • localizing your app
  • making your app accessible
  • adding location, places and maps to your apps
  • creating custom views
  • drawing to the canvas
  • drawing to a SurfaceView off the main thread
  • running animations

Learn more at developers.google.com/training/android-advanced.

Final preview of Android 8.1 now available

Posted by Dave Burke, VP of Engineering

Starting today we're rolling out an update to the Android 8.1 developer preview, the last before the official launch to consumers in December. Android 8.1 adds targeted enhancements to the Oreo platform, including optimizations for Android Go (for devices with 1GB or less of memory) and a Neural Networks API to accelerate on-device machine intelligence. We've also included a few smaller enhancements to Oreo in response to user and developer feedback.

If you have a device enrolled in the Android Beta Program, you'll receive the update over the next few days. If you haven't enrolled yet, just visit the Android Beta site to enroll and get the update.

At the official release in December we'll bring Android 8.1 to all supported Pixel and Nexus devices worldwide -- including Pixel 2 and Pixel 2 XL, Pixel, Pixel XL, Pixel C, Nexus 5X, and Nexus 6P. Watch for announcements soon.

What's in this update?

This preview update includes near-final Android 8.1 system images for Pixel and Nexus devices, with official APIs (API level 27), the latest optimizations and bug fixes, and the November 2017 security patch updates. You can use the images for compatibility testing or to develop using new Android 8.1 features like the Neural Networks API and others.

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.

Also, for Pixel 2 users, the Android 8.1 update on these devices enables Pixel Visual Core -- Google's first custom-designed co-processor for image processing and ML -- through a new developer option. Once enabled, apps using Android Camera API can capture HDR+ shots through Pixel Visual Core. See the release notes for details.

Get your apps ready

With the consumer launch coming in December, it's important to test your current app now. This ensures that users transition seamlessly to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in Android Beta to get the latest update, then install your app from Google Play and test. If you don't have a Pixel or Nexus device, you can set up an Android 8.1 emulator for testing instead. If you notice any issues, fix them and update your app in Google Play right away -- without changing the app's platform targeting.

When you're ready, take advantage of new features and APIs in Android 8.1. See the developer preview site, the API 27 diff report, and the updated API reference for details.

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 with Android Oreo features like Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

We also recommend updating to the Android Support Library 27.0.0, which is available from Google's Maven repository. See the version notes for details on what's new.

Publish your updates to Google Play

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

To make sure your app runs well on Android 8.1 as well as older versions, we recommend using Google Play's beta testing feature to run an alpha test on small group of users. Then run a much open beta test on a much larger group of users. When you're ready to launch your update, you can use a staged rollout in your production channel. We're looking forward to seeing your app updates!

Give us your feedback

As always, your feedback is crucial, so please keep it coming!. We've set up different hotlists where you can report Android platform issues, app compatibility issues, and third-party SDKs and tools issues. We also have a dedicated hotlist for Neural Networks API issues.

You can also give us feedback through the Android Developer community or Android Beta community as we work towards the consumer release in December.

Moving Past GoogleApiClient

Posted by Sam Stern, Developer Programs Engineer

The release of version 11.6.0 of the Google Play services SDK moves a number of popular APIs to a new paradigm for accessing Google APIs on Android. We have reworked the APIs to reduce boilerplate, improve UX, and simplify authentication and authorization.

The primary change in this release is the introduction of new Task and GoogleApi based APIs to replace the GoogleApiClient access pattern.

The following APIs are newly updated to eliminate the use of GoogleApiClient:

  • Auth - updated the Google Sign In and Credentials APIs.
  • Drive - updated the Drive and Drive Resource APIs.
  • Fitness - updated the Ble, Config, Goals, History, Recording, Sensors, and Sessions APIs.
  • Games - updated the Achievements, Events, Games, Games Metadata, Invitations, Leaderboards, Notifications, Player Stats, Players, Realtime Multiplayer, Snapshots, Turn Based Multiplayer, and Videos APIs.
  • Nearby - updated the Connections and Messages APIs.

These APIs join others that made the switch in previous releases, such as the Awareness, Cast, Places, Location, and Wallet APIs.

The Past: Using GoogleApiClient

Here is a simple Activity that demonstrates how one would access the Google Drive API using GoogleApiClient using a previous version of the Play services SDK:

public class MyActivity extends AppCompatActivity implements
        GoogleApiClient.OnConnectionFailedListener,
        GoogleApiClient.ConnectionCallbacks {

    private static final int RC_SIGN_IN = 9001;

    private GoogleApiClient mGoogleApiClient;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        GoogleSignInOptions options =
               new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
                        .requestScopes(Drive.SCOPE_FILE)
                        .build();

        mGoogleApiClient = new GoogleApiClient.Builder(this)
                .enableAutoManage(this, this)
                .addConnectionCallbacks(this)
                .addApi(Auth.GOOGLE_SIGN_IN_API, options)
                .addApi(Drive.API)
                .build();
    }

    // ...
    // Not shown: code to handle sign in flow
    // ...

    @Override
    public void onConnectionFailed(@NonNull ConnectionResult connectionResult) {
        // GoogleApiClient connection failed, most API calls will not work...
    }

    @Override
    public void onConnected(@Nullable Bundle bundle) {
        // GoogleApiClient is connected, API calls should succeed...
    }

    @Override
    public void onConnectionSuspended(int i) {
        // ...
    }

    private void createDriveFile() {
        // If this method is called before "onConnected" then the app will crash,
        // so the developer has to manage multiple callbacks to make this simple
        // Drive API call.
        Drive.DriveApi.newDriveContents(mGoogleApiClient)
            .setResultCallback(new ResultCallback<DriveApi.DriveContentsResult>() {
                // ...
            });
    }
}

The code is dominated by the concept of a connection, despite using the simplified "automanage" feature. A GoogleApiClient is only connected when all APIs are available and the user has signed in (when APIs require it).

This model has a number of pitfalls:

  • Any connection failure prevents use of any of the requested APIs, but using multiple GoogleApiClient objects is unwieldy.
  • The concept of a "connection" is inappropriately overloaded. Connection failures can be result from Google Play services being missing or from authentication issues.
  • The developer has to track the connection state, because making some calls before onConnected is called will result in a crash.
  • Making a simple API call can mean waiting for two callbacks. One to wait until the GoogleApiClient is connected and another for the API call itself.

The Future: Using GoogleApi

Over the years the need to replace GoogleApiClient became apparent, so we set out to completely abstract the "connection" process and make it easier to access individual Google APIs without boilerplate.

Rather than tacking multiple APIs onto a single API client, each API now has a purpose-built client object class that extends GoogleApi. Unlike with GoogleApiClient there is no performance cost to creating many client objects. Each of these client objects abstracts the connection logic, connections are automatically managed by the SDK in a way that maximizes both speed and efficiency.

Authenticating with GoogleSignInClient

When using GoogleApiClient, authentication was part of the "connection" flow. Now that you no longer need to manage connections, you should use the new GoogleSignInClient class to initiate authentication:

public class MyNewActivity extends AppCompatActivity {

    private static final int RC_SIGN_IN = 9001;

    private GoogleSignInClient mSignInClient;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        GoogleSignInOptions options =
               new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
                        .requestScopes(Drive.SCOPE_FILE)
                        .build();

        mSignInClient = GoogleSignIn.getClient(this, options);
    }

    private void signIn() {
        // Launches the sign in flow, the result is returned in onActivityResult
        Intent intent = mSignInClient.getSignInIntent();
        startActivityForResult(intent, RC_SIGN_IN);
    }

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);

        if (requestCode == RC_SIGN_IN) {
            Task<GoogleSignInAccount> task = 
                    GoogleSignIn.getSignedInAccountFromIntent(data);
            if (task.isSuccessful()) {
                // Sign in succeeded, proceed with account
                GoogleSignInAccount acct = task.getResult();
            } else {
                // Sign in failed, handle failure and update UI
                // ...
            }
        }
    }
}

Making Authenticated API Calls

Making API calls to authenticated APIs is now much simpler and does not require waiting for multiple callbacks.

    private void createDriveFile() {
        // Get currently signed in account (or null)
        GoogleSignInAccount account = GoogleSignIn.getLastSignedInAccount(this);

        // Synchronously check for necessary permissions
        if (!GoogleSignIn.hasPermissions(account, Drive.SCOPE_FILE)) {
            // Note: this launches a sign-in flow, however the code to detect
            // the result of the sign-in flow and retry the API call is not
            // shown here.
            GoogleSignIn.requestPermissions(this, RC_DRIVE_PERMS, 
                    account, Drive.SCOPE_FILE);
            return;
        }

        DriveResourceClient client = Drive.getDriveResourceClient(this, account);
        client.createContents()
                .addOnCompleteListener(new OnCompleteListener<DriveContents>() {
                    @Override
                    public void onComplete(@NonNull Task<DriveContents> task) {
                        // ...
                    }
                });
    }

Before making the API call we add an inline check to make sure that we have signed in and that the sign in process granted the scopes we require.

The call to createContents() is simple, but it's actually taking care of a lot of complex behavior. If the connection to Play services has not yet been established, the call is queued until there is a connection. This is in contrast to the old behavior where calls would fail or crash if made before connecting.

In general, the new GoogleApi-based APIs have the following benefits:

  • No connection logic, calls that require a connection are queued until a connection is available. Connections are pooled when appropriate and torn down when not in use, saving battery and preventing memory leaks.
  • Sign in is completely separated from APIs that consume GoogleSignInAccount which makes it easier to use authenticated APIs throughout your app.
  • Asynchronous API calls use the new Task API rather than PendingResult, which allows for easier management and chaining.

These new APIs will improve your development process and enable you to make better apps.

Next Steps

Ready to get started with the new Google Play services SDK?

Happy building!