Author: Android Developers

AndroidX Development is Now Even Better

Android Developers July 26, 2018 Android Developer, AndroidX, aosp

Posted by Aurimas Liutikas, software engineer on AndroidX team

AndroidX (previously known as Android Support Library) started out as a small set of libraries intended to provide backwards compatibility for new Android platform APIs and, as such, its development was strictly tied to the platform. As a result, all work was done in internal Google branches and then pushed to the public Android Open Source Project (AOSP) together with the platform push. With this flow, external contributions were limited to a narrow window of time where the internal and AOSP branches were close in content. On top of that, it was difficult to contribute — in order to do a full AndroidX build and testing, external developers had to check out >40GB of the full Android platform code.

Today, the scope of AndroidX has expanded dramatically and includes libraries such as AppCompat for easier UI development, Room for database management, and WorkManager for background work. Many of these libraries implement higher-level abstractions and are less tied to new revisions of the Android platform, and all libraries are designed with backwards compatibility in mind from the start. Several libraries, such as RecyclerView and Fragment, are purely AndroidX-side implementations with few ties to the platform.

Starting a little over two years ago, we began a process of unbundling — moving AndroidX out of Android platform builds into its own separate build. We had to do a great deal of work, including migrating our builds from make to Gradle as well as migrating all of our API tracking tools and documentation generation out of the platform build. With that process completed, we reached a point where a developer can now check out a minimal AndroidX project, open it in Android Studio, and build using the public SDK and public Android Gradle Plugin.

The Android developer community has long expressed a desire to contribute more easily to AndroidX; however, this was always a challenge due to the reasons described above. This changes today: AndroidX development is moving to public AOSP. That means that our primary feature development (except for top-secret integrations with the platform 😀) and bug fixes will be done in the open using the r.android.com Gerrit review tool and changes will be visible in the aosp/androidx-master-dev branch.

We are making this change to give better transparency to developers; it gives developers a chance to see features and bug fixes implemented in real-time. We are also excited about receiving bug fix contributions from the community. We have written up a short guide on how to go about contributing a patch.

In addition to regular development, AOSP will be a place for experimentation and prototyping. You will see new libraries show up in this repository; some of them may be removed before they ship, change dramatically during pre-alpha development, or merge into existing libraries. The general rule is that only the libraries on maven.google.com are officially ready for external developer usage.

Finally, we are just getting started. We apologize for any rough edges that you might have when contributing to AndroidX, and we request your feedback via the public AndroidX tracker if you hit any issues.

Updating your games for modern Android

Android Developers July 20, 2018 Android, Android Studio, Google Play, Requirements

Posted by Tom Greenaway, Senior Partner Developer Advocate

Last year we announced that starting from August 2018 Google Play will require all new apps and games to target a recent Android API level – set to API level 26 (Android 8.0 Oreo), or higher. Additionally, this requirement will extend to updates for existing apps and games starting from November 2018.

Every new Android version introduces changes that bring significant security and performance improvements – and enhance the user experience of Android overall. Updating your games to target the latest API level ensures that your users can benefit from these improvements, while still allowing your games to run on older Android versions.

Simple next steps:

  • Install the Android 8.0 Oreo SDK (API level 26) via Android Studio by navigating to (Tools > Android > SDK Manager > Android SDK > SDK Platforms).
  • Update your game to target API level 26 and see whether your game has any incompatibilities or issues as soon as possible. Update any external dependencies as necessary. Learn more about the incremental changes between versions of Android here.
  • If you are using an advertising network, SDK or plugin which is incompatible with API level 26, reach out to your contacts and find out their timeline for supporting target API level 26. The sooner they’re aware of these changes the better.
  • If you build your game with Unity, support for target API 26 is built into Unity 5.6.6 and beyond. Simply ensure the latest target API level is selected in your Android build settings for Unity (Build Settings > Android > Player Settings). For versions of Unity 5.6.5 and prior, consult this documentation which includes a workaround for versions dating back to 4.3.
  • For games built with Unreal, check your Android platform settings has the “Target SDK Version” set to 26.
  • If you use Cocos2D-X, check the target API level in the gradle.properties file that is generated.

Significant changes to be aware of:

  • Since API 23, we have required permissions be requested at runtime which helps streamline the app install process.
  • Since API 24, apps can no longer dynamically link against non-NDK libraries. If your app (including third-party static libraries) contains native code, you should only be using public NDK APIs.
  • If your game uses Android push notifications, the Google Play Services SDK in your game will need to be updated to version 10.2.1 or above for your game to support API level 26.
  • If your game uses opaque binary blobs (OBB), then your game must check if it can access the directory before attempting to access the OBB files themselves. We recommend explicitly requesting permission for access using the Runtime Permissions API, and gracefully handling cases wherein the permission is not granted. Additionally, add an entry in the manifest for the external storage access:
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    

Moving ahead

Remember, updating the target API level is just the first step – make sure your game is compatible with the behavior changes between your current target API level and API level 26. Check out further guidance on the changes in past versions of Android to help in your migration process. These policy changes are important for moving the Android ecosystem forward and keeping it healthy for our users – and yours.

How useful did you find this blog post?

Android Emulator – AMD Processor & Hyper-V Support

Android Developers July 9, 2018 AMD, Android, Android Emulator, Android Studio, HyperV

Posted by Jamal Eason, Product Manager, Android

Since the major revamp of the Android Emulator two years ago, we have focused on delivering a fast and feature-rich emulator to help you build great app experiences for users. Today, the Android Emulator is the top device deployed to from Android Studio — more than 2x over physical Android devices. We are humbled to hear from many of you that the Android Emulator has come a long way, but we are not done yet.

Making the Android Emulator faster is one of the top priorities for the Android Studio team. Over the last few releases, we have launched quick boot & emulator snapshots for quickly starting and resuming emulator sessions in under 2 seconds. Up until now, our emulator experience has almost universally worked on macOS® and Linux computers. But for users of Microsoft® Windows® or the Microsoft® Hyper-V platform, our hardware accelerated speed enhancements for the Android Emulator only worked with computers with Intel® processors. Support for AMD® processors and Microsoft Hyper-V hypervisor are two long-standing user requests from the Android developer community that we are happy to address with this Android Emulator update.

Today, you can download the latest Android Emulator release, which is enabled to run x86 based Android Virtual Devices (AVD) on computers that use AMD processors. This exciting update makes the Android Emulator more accessible to a new set of Android app developers that were previously limited to software emulation, but can now have hardware accelerated performance. Moreover, for those of you who use Hyper-V to run your local app backend, the Android Emulator can now also coexist with other Hyper-V-backed applications on Windows® 10.

Thanks to a new Microsoft Windows Hypervisor Platform (WHPX) API and recent open-source contributions from Microsoft, even more Android app developers can take advantage of all the speed improvements and features in the Android Emulator.

Android Emulator running on Windows 10 with AMD Processor
Screenshot Configuration: Asus ROG Strix GL 702ZC, Processor: AMD® Ryzen 7 1700 Processor, Chipset: AMD 5350, Graphics: AMD® Radeon RX580

Support for these technologies was initially available in the v27.3.8 Android Emulator canary release and today we are releasing this set of preview features (AMD processor & Hyper-V support) on the stable channel for more feedback. Alongside this update, we have added additional speed improvements in loading emulator snapshots for those developers using the Intel® Hardware Accelerated Execution Manager (HAXM).

How to use

Linux

If you use Linux for Android app development, the Android Emulator will continue to use the native Kernel-based Virtual Machine (KVM) hypervisor for both Intel and AMD based computers for a fast and performant virtualization solution. An update to the v27.3.8 Android Emulator will offer you the new snapshots UI along with improvements to performance, reliability and resource usage.

macOS

For OS X v10.10 Yosemite and higher, the Android Emulator uses the built-in Hypervisor.Framework by default, and falls back to using the Intel Hardware Accelerated Execution Manager (HAXM) if Hypervisor.Framework fails to initialize (such as when running on OS X v10.9 or earlier). Once you update to the latest Android Emulator on macOS, you will also have access to the new snapshots UI along with under the hood performance and reliability improvements.

Android Emulator – Snapshots Extended Controls

Microsoft Windows

On Intel x86-based computers, the Android Emulator will continue to use Intel HAXM by default. Intel HAXM is a mature and open-sourced hypervisor solution developed by Intel. Thanks to on-going development by Intel, the fastest emulator performance on Windows is still with Intel HAXM. To download the latest Intel HAXM v7.2.0, check for updates in the Android SDK Manager.

If you have an AMD processor in your computer you need the following setup requirements to be in place:

  • AMD Processor – Recommended: AMD® Ryzen processors
  • Android Studio 3.2 Beta or higher – download via Android Studio Preview page
  • Android Emulator v27.3.8+ – download via Android Studio SDK Manager
  • x86 Android Virtual Device (AVD) – Create AVD
  • Windows 10 with April 2018 Update
  • Enable via Windows Features: “Windows Hypervisor Platform”

Windows Hypervisor Platform setting in Windows 10

If you want to use Hyper-V at the same time as the Android Emulator on your Intel processor-based computer, you will also need the same Android Studio and Android Emulator versions as listed above, but with the additional requirements:

  • Enable via Windows Features: “Hyper-V” – Only available for Windows 10 Professional/Education/Enterprise
  • Intel Processor : Intel® Core processor that supports Virtualization Technology (VT-x), Extended Page Tables (EPT), and Unrestricted Guest (UG) features. Additionally VT-x needs to be enabled in the BIOS.

For more setup tips and troubleshooting details, check out the documentation page.

Again, for existing Windows users who have an Intel-based processor, the Android Emulator will continue to use the faster and recommended Intel HAXM configuration. For those using AMD processors, and those who use Hyper-V hypervisors, this should be an exciting step forward to start using the Android Emulator.

Next Steps & Feedback

Download the latest Android Emulator from the Android Studio 3.2 Beta SDK Manager for the latest performance updates across all supported platforms that you are using. We are going to continue to invest in performance improvements for each of the platforms and we look forward to your feedback and feature requests.

If you find a bug or issue, feel free to file an issue. Connect with us — the Android Studio development team ‐ on our Google+ page or on Twitter.

What’s new for text in Android P

Android Developers July 4, 2018 androidp, text, textclassifier, textview

Posted by Florina Muntenescu, Developer Advocate & Siyamed Sinir Android Text Technical Lead

In “What’s new in Android P Beta” we mentioned two of the new text features in Android.. Now that Android P Beta 2 and the final APIs are here, it’s time to dive deeper into what’s new for text. We know that TextView is one of the most critical components of the Android view system. This is why we continue to invest in both developer- and user-facing features and API improvements.

PrecomputedText

Displaying text can be complex, encompassing features like multiple fonts, line spacing, letter spacing, text direction, line breaking, hyphenation and more. TextView has to do a lot of work to measure and lay out the given text: reading the font file, finding a glyph, decide the shape, measure the bounding box, and caching the word in an internal word cache. What’s more, all of this work takes place on the UI thread, where it could potentially cause your app to drop frames.

We found that measuring text can take up to 90% of the time required to set the text. To solve this problem, in Android P and as part of Jetpack, we introduced a new API: PrecomputedText. This API is available as far back as API 14 via PrecomputedTextCompat.

PrecomputedText enables an app to perform the most time-consuming parts of text layout beforehand, even on a background thread, caching the layout result and returning valuable measurement data. The result of PrecomputedText.create(CharSequence, params) can then be set on a TextView. With this, only about 10% of the work remains to be done by the TextView.

Percentage of time taken to measure and layout text

Percentage of time taken to measure and layout text

// UI thread
val params: PrecomputedText.Params = textView.getTextMetricsParams()
val ref = WeakReference(textView)
executor.execute {
    // background thread
    val text = PrecomputedText.create("Hello", params)
    val textView = ref.get()
    textView?.post {
        // UI thread
        val textViewRef = ref.get()
        textViewRef?.text = text
    }
}

Magnifier

Even with features like Smart Text Selection, precisely selecting text can be challenging. Android P introduces the text Magnifier to improve the user experience of selecting text. The magnifier helps users precisely position the cursor or the text selection handles by viewing magnified text through a pane that can be dragged over the text.

Magnifying text in Android P

Magnifying text in Android P

We wanted users to have the same experience across all apps, whether in custom widgets or during custom text-rendering, so we provided a Magnifier widget that can be applied to any view that is attached to a window. The Magnifier widget can provide a zoomed-in version of any view or surface, not just text.

The Magnifier has 3 main methods: show, update and dismiss. For example, you could call these methods when implementing onTouchEvent-handling for your custom view. This would cause the Magnifier to follow the user’s finger along the screen.

fun onTouchEvent(event: MotionEvent): Boolean {
    when (event.actionMasked) {
        MotionEvent.ACTION_DOWN -> 
              magnifier.show(event.x, event.y)
        MotionEvent.ACTION_MOVE -> 
             magnifier.show(event.x, event.y)
        MotionEvent.ACTION_UP -> 
             magnifier.dismiss()
    }
}

Smart Linkify

The Linkify class, which has existed since API 1, allows adding links to text using regexes. On top of that, finding physical addresses spins up a WebView instance to produce the results, which can degrade the performance of the app requesting links. To make link resolution more accurate, especially for internationalized text, and to mitigate the performance degradation caused by the WebView, we created Smart Linkify. Smart Linkify can be accessed using TextClassifier API.

Smart Linkify uses machine-learning algorithms and models to recognize entities in text. This improves the reliability of the entities recognized. Smart Linkify can, based on entity type,suggest actions that the user can perform. For example, if Smart Linkify recognizes a phone number, the API suggests actions such as sending a text message, making a call, or adding to contacts.

Smart Linkify in Android P

Smart Linkify in Android P

To improve the performance of your app, move the work of generating and applying links to a background thread.

// UI thread
val text: Spannable = ...
val request = TextLinks.Request.Builder(text)
val ref = WeakReference(textView)
executor.execute {
    // background thread
    TextClassifier.generateLinks(request).apply(text)
    val textView = ref.get()
    textView?.post {
        // UI thread
        val textViewRef = ref.get()
        textViewRef?.text = text
    }
}

Line Height and Baseline Text Alignment

Designers sometimes provide layout specifications to developers that do not match existing TextView attributes perfectly. On Android P and in Jetpack we added three attributes, together with their corresponding functions, to help bridge this gap between how designers and developers work.

Setting line height

Before Android P, the spacing between lines could be controlled using the lineSpacingExtra and lineSpacingMultiplier attributes. However, designers will commonly provide these values as a simple line height, instead. For this reason, on Android P, we added the lineHeight attribute to set the line height of the text: that is, the distance between the top and bottom of a line (or distance between subsequent baselines). Under the hood, this attribute actually uses and modifies the existing lineSpacingExtra and lineSpacingMultiplier attributes.

Size of line height and font size

Size of line height and font size

<TextView
    android:layout_height="wrap_content"
    android:layout_width="match_parent"
    android:text="Lorem ipsum dolor sit amet"
    app:lineHeight="50sp"/>

// or in code
TextView.setLineHeight(@Px int)

Setting the baseline text alignment

To control the distances of the first and last baselines from the view boundaries, we added two new attributes: firstBaselineToTopHeight and lastBaselineToBottomHeight.

firstBaselineToTopHeight: Sets the distance between the TextView’s top boundary and the baseline of the first line of the TextView. Under the hood this attribute updates the top padding.

lastBaselineToBottomHeight: Sets the distance between the TextView’s bottom boundary and the baseline of the last line of the TextView. Under the hood, this attribute actually updates the bottom padding.

Distances between first base line to top and last baseline to bottom

Distances between first base line to top and last baseline to bottom

<TextView
    android:layout_height="wrap_content"
    android:layout_width="match_parent"
    android:text="Lorem ipsum dolor sit amet"
    app:firstBaselineToTopHeight="28sp"
    app:lastBaselineToBottomHeight="20sp"/>

// or in code
TextView.setFirstBaselineToTopHeight(@Px int)
TextView.setLastBaselineToBottomHeight(@Px int)

Text plays an important role in a vast majority of apps – it’s a crucial part of an app’s design language. Text is consumed by users, and it even renders emoji 😎. We’re continuing to invest in text, improving the experience of both app users and developers.

To learn more about working with text APIs and what’s new in Android P for text, check out the Google I/O 2018 talk on “Best practices with text”:

Congrats to the new Android Excellence apps and games on Google Play

Android Developers July 3, 2018 android developers, App, Develop, Featured, Game, Google Play

Posted by Kacey Fahey, Developer Marketing, Google Play

Join us in congratulating the latest apps and games entering the Android Excellence program on Google Play. This diverse group of apps and games is recognized for their high quality, great user experience, and strong technical performance. Whether you’re interested in learning meditation or a new language, or are looking for a game about butterflies or warships, we’re excited to dive in to these new collections.

Winning apps image

Check out a few of our highlighted apps.

  • Beelinguapp: Learn a new language with this unique app. Read and listen to stories with side by side text of the language you’re learning, while following along with your language as a reference.
  • Fortune City: If you’re looking for a fun app to help manage your personal finances, learn how Fortune City teaches good budgeting habits as you build a prospering metropolis.
  • ShareTheMeal: Feed a child in need with one tap on your phone, or create a team to fight hunger together with your friends, using this app by the World Food Programme.

Test your skills with these highlighted games.

  • Animal Crossing™: Pocket Camp: Take on the role of campsite manager as you collect items to decorate and build your ultimate dream campsite. Meet animals, build friendships and invite your favorite animals over for a fun time.
  • Cash, Inc.: Be the big boss of your business empire in this fun game. Work your way up to join a community of business elites and become the most famous money tycoon.
  • Shadowgun Legends: Save humanity from an alien invader in an epic Story Campaign spanning over 200+ mission on 4 diverse planets. Along the way, customize your character, team up with friends, and become a celebrity of the Shadowgun Universe.

See the full list of Android Excellence apps and games.

New Android Excellence apps New Android Excellence games
Beelinguapp

BTFIT

Fortune City

Letras.mus.br

LingoDeer

Memrise

PicsArt

Pocket Casts

ShareTheMeal

The Mindfulness App

Tokopedia

Trello

VivaReal

Wynk Music
Animal Crossing™: Pocket Camp

Cash, Inc.

Flutter: Starlight

Shadow Fight 3

Shadowgun Legends

War Heroes

World of Warships Blitz

Explore other great apps and games in the Editors’ Choice section on Google Play and discover best practices to help you build quality apps and games.

How useful did you find this blogpost?


Android P Beta 3 is now available

Android Developers July 2, 2018 Developer Preview

Posted by Dave Burke, VP of Engineering

Android P logo

Today we’re rolling out Beta 3 of Android P, our next milestone in this year’s Android P developer preview. With the developer APIs already finalized in the previous update, Beta 3 now takes us very close to what you’ll see in the final version of Android P, due later this summer.

Android P Beta 3 includes the latest bug fixes and optimizations for stability and polish, together with the July 2018 security updates. It’s a great way to test your apps now to make sure they are ready before the final release. Give Beta 3 a try and let us know what you think!

You can get Android P Beta 3 on Pixel devices by enrolling here. If you’re already enrolled and received the Android P Beta 2 on your Pixel device, you’ll automatically get the update to Beta 3. Partners who are participating in the Android P Beta program will also be updating their devices to Beta 3 over the coming weeks.

What’s in this update?

Today’s preview update includes the Beta 3 system images for Pixel devices and the Android Emulator, as well as an update to the Android Studio build tools to include D8 as an independent tool. Beta 3 is an early release candidate build of Android with near-final system behaviors and the official Android P APIs (API level 28).

With the Beta 3 system images and updated build tools, you’ve got everything you need to test your apps or extend them with Android P features like multi-camera support, display cutout, enhanced notifications, ImageDecoder, TextClassifier, and many others. In your testing, make sure to account for App standby buckets, privacy restrictions, and restrictions on non-SDK interfaces.

Get started in a few simple steps

Android P preview

First, make your app compatible and give your users a seamless transition to Android P. Just install your current app from Google Play on an Android P Beta device or emulator and test — the app should run and look great, and handle the Android P behavior changes properly. After you’ve made any necessary updates, we recommend publishing to Google Play right away without changing the app’s platform targeting.

If you don’t have a supported device, remember that you can instead set up an Android Virtual Device on the Android Emulator for your test environment. If you haven’t tried the emulator recently, you’ll find that it’s incredibly fast, boots in under 6 seconds, and even lets you model next-gen screens — such as long screens and screens with a display cutout.

Next, update your app’s targetSdkVersion to 28 as soon as possible, so Android P users of your app can benefit from the platform’s latest security, performance, and stability features. If your app is already targeting API 26+ in line with Google Play’s upcoming policies, then changing to target API 28 should be a small jump. When you change your targeting, make sure your app supports all of the applicable behavior changes.

It’s also important to test your apps for uses of non-SDK interfaces and reduce your reliance on them. As noted recently, Android P restricts access to selected non-SDK interfaces. Watch for logcat warnings that highlight direct uses of restricted non-SDK interfaces and try the new StrictMode method detectNonSdkApiUsage() to catch accesses programmatically. Where possible, you should move to using public equivalents from the Android SDK or NDK. If there’s no public API that meets your use-case, please let us know.

When you’re ready, dive into Android P and learn about the new features and APIs that you can use in your apps. To build with the new APIs, just download the official API 28 SDK and tools into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project’s compileSdkVersion and targetSdkVersion to API 28.

Visit the Developer Preview site for details and documentation. Also check out this video and the Google I/O Android playlist for more on what’s new in Android P for developers.

Publish to Google Play alpha, beta, or production channels

As soon as you’re ready, publish your APK updates that are compiled against, or optionally targeting, API 28. Publishing an update to Google Play during the preview lets you push updates to existing users to test compatibility on their devices.

To make sure that your updated app runs well on Android P as well as older versions, a common strategy is to use Google Play’s beta testing feature. With beta testing you can get early feedback from a small group of users — including Beta 3 users — and then do a staged rollout to production.

What’s next?

Thanks for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. Feel free to use our hotlists for platform issues, app compatibility issues, and third-party SDK issues.

Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer your technical questions about Android P on July 19 from 11:30-1 PM (Pacific Time). Look out for an announcement on r/androiddev in the coming weeks. We look forward to addressing your questions!

Automating your app releases with Google Play

Android Developers June 28, 2018 API, Google Play, Play Console, Releases

Posted by Nicholas Lativy, Software Engineer

At Google I/O we shared how Google’s own apps make use of Google Play for successful launches and updates and introduced the new Google Play Developer Publishing API Version 3.

The Publishing API enables you to integrate publishing operations into your existing release process or automated workflows by providing the ability to upload APKs and roll out releases. Here’s an overview of some of the improvements you can now take advantage of in Version 3 of the API.

Releases in the API

The Publishing API now uses the release model you are familiar with from the Play Console.

{
  "track": "production",
  "releases": [
    {
      "name": "Release One", 
      "versionCodes": ["100"],
      "status": "completed"
    }
  ]
}

This gives you full control over releases via the API allowing a number of operations which were previously available only in the Play Console. For example, you can now control the name of releases created via the API, and we have now relaxed the constraints on what can be rolled out via the API to match the Play Console.

Additional testing tracks

The API now supports releasing to any of the testing tracks you have configured for your application as well as the production track. This makes it possible to configure your continuous integration system to push a new build to your internal test track as soon as it’s ready for QA.

Staged rollout

Staged rollouts are the recommended way to deploy new versions of your app. They allow you to make your new release available to a small percentage of users and gradually increase this percentage as your confidence in the release grows.

Staged rollouts are now represented directly in the API as inProgress releases.

{
  "track": "production",
  "releases": [
    {
      "versionCodes": ["100"],
      "status": "completed"
    },
    {
      "versionCodes": ["200"],
      "status": "inProgress",
      "userFraction": 0.1
    }
  ]
}

You can now halt a staged rollout via the API by changing its status to halted. This makes it possible to automatically respond to any problems you detect while performing a rollout. If it turns out to be a false alarm, the API now also allows you to resume a halted release by changing its status back to inProgress.

Release notes

Release notes are a useful way to communicate to users new features you have added in a release. In V3 we have simplified how these are specified via the API by adding the releaseNotes field to release.

{
  "track": "production",
  "releases": [
    {
      "versionCodes": ["100"],
      "status": "completed",
      "releaseNotes": [
        {
          "language": "en-US",
          "text": "Now it's easier to specify release notes."
        },
        {
           "language": "it-IT",
           "text": "Ora è più semplice specificare le note sulla versione."
        }
    }
  ]
}

Draft releases

We know that while many developers are comfortable deploying test builds automatically, they like using the Play Console when rolling out to production.

So, in the V3 API we have added the ability to create and manage Draft Releases.

{
  "track": "production",
  "releases": [
    {
      "name": "Big Launch",
      "versionCodes": ["200"],
      "status": "draft"
    }
  ]
}

This allows you to upload APKs or App Bundles and create a draft release from your continuous integration system, and then have your product manager log in, check that everything looks good, and hit “Confirm and Rollout”.

We hope you find these features useful and take advantage of them for successful launches and updates with Google Play. If you’re interested in some of the other great tools for distributing your apps, check out the I/O sessions which have now been posted to the Android Developers YouTube Channel.

How useful did you find this blogpost?


Compiler-based security mitigations in Android P

Android Developers June 27, 2018 android p, security

Posted by Ivan Lozano, Information Security Engineer

Android’s switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security posture. In the past couple of releases, we’ve rolled out additional compiler-based mitigations to make bugs harder to exploit and prevent certain types of bugs from becoming vulnerabilities. In Android P, we’re expanding our existing compiler mitigations, which instrument runtime operations to fail safely when undefined behavior occurs. This post describes the new build system support for Control Flow Integrity and Integer Overflow Sanitization.

Control Flow Integrity

A key step in modern exploit chains is for an attacker to gain control of a program’s control flow by corrupting function pointers or return addresses. This opens the door to code-reuse attacks where an attacker executes arbitrary portions of existing program code to achieve their goals, such as counterfeit-object-oriented and return-oriented programming. Control Flow Integrity (CFI) describes a set of mitigation technologies that confine a program’s control flow to a call graph of valid targets determined at compile-time.

While we first supported LLVM’s CFI implementation in select components in Android O, we’re greatly expanding that support in P. This implementation focuses on preventing control flow manipulation via indirect branches, such as function pointers and virtual functions—the ‘forward-edges’ of a call graph. Valid branch targets are defined as function entry points for functions with the expected function signature, which drastically reduces the set of allowable destinations an attacker can call. Indirect branches are instrumented to detect runtime violations of the statically determined set of allowable targets. If a violation is detected because a branch points to an unexpected target, then the process safely aborts.

Assembly-level comparison of a virtual function call with and without CFI enabled.

Figure 1. Assembly-level comparison of a virtual function call with and without CFI enabled.

For example, Figure 1 illustrates how a function that takes an object and calls a virtual function gets translated into assembly with and without CFI. For simplicity, this was compiled with -O0 to prevent compiler optimization. Without CFI enabled, it loads the object’s vtable pointer and calls the function at the expected offset. With CFI enabled, it performs a fast-path first check to determine if the pointer falls within an expected range of addresses of compatible vtables. Failing that, execution falls through to a slow path that does a more extensive check for valid classes that are defined in other shared libraries. The slow path will abort execution if the vtable pointer points to an invalid target.

With control flow tightly restricted to a small set of legitimate targets, code-reuse attacks become harder to utilize and some memory corruption vulnerabilities become more difficult or even impossible to exploit.

In terms of performance impact, LLVM’s CFI requires compiling with Link-Time Optimization (LTO). LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.

For more technical details about CFI and how other forward-control checks are handled, see the LLVM design documentation.

For Android P, CFI is enabled by default widely within the media frameworks and other security-critical components, such as NFC and Bluetooth. CFI kernel support has also been introduced into the Android common kernel when building with LLVM, providing the option to further harden the trusted computing base. This can be tested today on the HiKey reference boards.

Integer Overflow Sanitization

The UndefinedBehaviorSanitizer’s (UBSan) signed and unsigned integer overflow sanitization was first utilized when hardening the media stack in Android Nougat. This sanitization is designed to safely abort process execution if a signed or unsigned integer overflows by instrumenting arithmetic instructions which may overflow. The end result is the mitigation of an entire class of memory corruption and information disclosure vulnerabilities where the root cause is an integer overflow, such as the original Stagefright vulnerability.

Because of their success, we’ve expanded usage of these sanitizers in the media framework with each release. Improvements have been made to LLVM’s integer overflow sanitizers to reduce the performance impact by using fewer instructions in ARM 32-bit and removing unnecessary checks. In testing, these improvements reduced the sanitizers’ performance overhead by over 75% in Android’s 32-bit libstagefright library for some codecs. Improved Android build system support, such as better diagnostics support, more sensible crashes, and globally sanitized integer overflow targets for testing have also expedited the rollout of these sanitizers.

We’ve prioritized enabling integer overflow sanitization in libraries where complex untrusted input is processed or where there have been security bulletin-level integer overflow vulnerabilities reported. As a result, in Android P the following libraries now benefit from this mitigation:

  • libui
  • libnl
  • libmediaplayerservice
  • libexif
  • libdrmclearkeyplugin
  • libreverbwrapper

Future Plans

Moving forward, we’re expanding our use of these mitigation technologies and we strongly encourage vendors to do the same with their customizations. More information about how to enable and test these options will be available soon on the Android Open Source Project.

Acknowledgements: This post was developed in joint collaboration with Vishwath Mohan, Jeffrey Vander Stoep, Joel Galenson, and Sami Tolvanen

Launching the Indie Games Accelerator in Asia – helping gaming startups find success on Google Play

Android Developers June 27, 2018 android developers, Featured, Google Play, Indie Games Accelerator, Launchpad Accelerator

Posted by Anuj Gulati, Developer Marketing Manager, Google Play and Sami Kizilbash, Developer Relations Program Manager, Google

Emerging markets now account for more than 40% of game installs on Google Play. Rapid smartphone adoption in these regions presents a new base of engaged gamers that are looking for high quality mobile gaming experiences. At Google Play, we are focused on helping local game developers from these markets achieve their full potential and make the most of this opportunity.

Indie Games Accelerator is a new initiative to support top indie game startups from India, Indonesia, Malaysia, Pakistan, Philippines, Singapore, Thailand and Vietnam who are looking to supercharge their growth on Android. This four month program is a special edition of Launchpad Accelerator, designed in close collaboration with Google Play, featuring a comprehensive gaming curriculum and mentorship from top mobile gaming experts.

Successful participants will be invited to attend two all-expense-paid gaming bootcamps at the Google Asia-Pacific office in Singapore, where they will receive personalized mentorship from Google teams and industry experts. Additional benefits include Google Cloud Platform credits, invites to exclusive Google and industry events, and more.

Visit the program website to find out more and apply now.

How useful did you find this blogpost?


Android Studio 3.2 Beta

Android Developers June 21, 2018 Android, Android Studio

Posted by Jamal Eason, Product Manager, Android

Starting today, you can download Android Studio 3.2 Beta. Previewed at Google I/O 2018, the latest release of the official Android IDE is focused on helping onboard you to all the new features launched around Google I/O — Android JetPack, Android P Developer Preview, and the new Android App Bundle format. There are also several other exciting new features included in Android Studio 3.2 to accelerate your app development, such as Emulator Snapshots and the Energy Profiler.

As the usage of Android Studio has grown in the 3.5 years since version 1.0, we have also become increasingly obsessed with quality. We continue to invest in quality because we know that millions of app developers spend almost everyday in Android Studio and need a reliable set of tools. Stability, build times, and other quality work will be the primary focus for our next release once we finish Android Studio 3.2. We also did not want to wait, so we have made checkins to address memory leaks and performance issues as well as fixed more than 450 bugs. Thank you for the continued feedback and please keep it coming so we can focus on the areas you care about most in the next version of Android Studio. If want to try out the latest features, and assess the improvements in quality, you can download Android Studio on the beta release channel.

What is inside of Android Studio 3.2

Building on the canary release of Android Studio 3.2, the Beta release includes:

  • Android App Bundle support – The Android App Bundle is a new publishing format that uses the Google Play’s Dynamic Delivery, which delivers a smaller, optimized APK that only contains the resources needed for a specific device. Without any code changes, you can take advantage of the app size savings of an Android App Bundle by navigating to Build Build Bundle / APK or BuildGenerate Signed Bundle / APK.

Build Android App Bundle

  • Emulator Snapshots – With Android Studio 3.2 you can create snapshots at any emulator state and then start a snapshot in under 2 seconds. You can pre-configure an Android Virtual Device (AVD) snapshot with the apps, data and settings that you want and then repeatedly go back to the same snapshot. Learn more.

Android Emulator Snapshots

  • Energy Profiler – The new Energy Profiler in the performance profiler suite can help you understand the energy impact of your app on an Android device. You can now visualize the estimated energy usage of system components, plus inspect background events that may contribute to battery drain.

Energy Profiler

Check out the full write-up of all the major features organized by development flow listed below and on the canary blog:

Develop

  • Navigation Editor
  • AndroidX Refactoring
  • Sample Data
  • Material Design Update
  • Android Slices
  • CMakeList editing
  • What’s New Assistant
  • New Lint Checks
  • Intellij Platform Update

Build

  • Android App Bundle
  • D8 Desugaring
  • R8 Optimizer

Test

  • Android Emulator Snapshots
  • Screen Record in Android Emulator
  • Virtual Scene Android Emulator Camera
  • ADB Connection Assistant

Optimize

  • Energy Profiler
  • System Trace
  • Profiler Sessions
  • Automatic CPU Recording
  • JNI Reference Tracking

Sessions at Google I/O ’18

With the release of Android Studio 3.2 at Google I/O ’18, the Android Studio team also presented a series of sessions about Android Studio. Watch the following videos to see the latest features in action and to get tips & tricks on how to use Android Studio:

Download & Feedback

Download the latest version of Android Studio 3.2 from the beta channel download page. If you are using a previous versions of Android Studio, make sure you update to Android Studio Beta 1 or higher. If you also want to maintain a stable version of Android Studio, you can run the stable release version and beta release versions of Android Studio at the same time. Learn more.

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v27.3+ downloaded via the Android Studio SDK Manager.

Please note, to ensure we maintain product quality, some of the features you saw in the canary channel like Navigation Editor are not enabled by default. To turn on canary release channel features go to File → Settings → Experimental → Editor → Enable Navigation Editor.

If you find a bug or issue, feel free to file an issue. Connect with us — the Android Studio development team ‐ on our Google+ page or on Twitter.

Android Things client library for Google Cloud IoT Core

Android Developers June 21, 2018

Posted by Wayne Piekarski, Developer Advocate for IoT +WaynePiekarski @WaynePiekarski

We’re releasing a client library to make it easy to use Google Cloud IoT Core from Android Things devices. With just a few lines of code, you can easily connect to the IoT Core MQTT bridge, authenticate the device, publish device telemetry and state, subscribe to configuration changes, and handle errors and network outages.

What is Cloud IoT Core?

Cloud IoT Core is a fully managed service on Google Cloud Platform that allows you to easily and securely connect, manage, and ingest data from millions of globally dispersed devices. Cloud IoT Core, in combination with other services which make up Google’s Cloud IoT platform, provides a complete solution for collecting, processing, analyzing, and visualizing IoT data in real time, to support improved operational efficiency, compliance, or revenue management. Android Things is designed to support everything from collecting telemetry data to powerful computer vision, audio processing, and machine learning applications, all on device, and using Cloud IoT Core, push your data into Google Cloud Platform for further analysis.

Cloud IoT Core client library

The Cloud IoT Core client library was designed to enable Android Things developers to get started with just a few lines of code. The client library handles the networking, threading, and message handling, implementing best practices for authentication, security, error handling, and offline operation.

Cloud IoT Core maintains a device registry that keeps track of approved devices, and each device uses a public key to authenticate with the server. Android Things provides many features to support secure IoT applications, including a hardware-backed Android Keystore that ensures cryptographic key material is protected. The client library supports both RSA and ECC keys, and implements the generation of JSON Web Tokens (JWTs) for authentication with Cloud IoT Core.

Once the connection is established, devices can publish their telemetry data to one or more buckets in the telemetry topic, as well as report their internal state to a separate device state topic. The device state is intended to store information such as software versions or the number of working sensors. The telemetry messages are for all other data from the device, such as actual sensor measurements. Devices can also subscribe to configuration changes published from Cloud IoT Core.

Because IoT devices operate in the real world with poor wireless conditions, the client library provides extensive support for handling errors, and for caching and retransmitting events later. For developers requiring custom offline behavior, the library’s queue is configurable and even replaceable. This provides detailed control over which events to save and the order in which they are sent when back online.

Device provisioning and authentication with Android Things

The Cloud IoT Core client library is part of our overall vision for device provisioning and authentication with Android Things. To learn more about this, watch the video of our presentation from Google I/O 2018:

Sample code

Getting started with the Cloud IoT Core client library is simple. You can simply add the following to the build.gradle file in your Android Things project:

implementation 'com.google.android.things:cloud-iot-core:1.0.0'

The library is also available as open source on GitHub if you prefer to build it yourself. We also have a sample that shows how to implement a sensor hub on Android Things, collecting sensor data from connected sensors and publishing them to a Google Cloud IoT Pub/Sub topic.

It is easy to start using the client library in your own code. The following Kotlin example demonstrates how to create a new configuration and client based on your project.

var configuration = IotCoreConfiguration.Builder().
                         .setProjectId("my-gcp-project")
                         .setRegistry("my-device-registry", "us-central1")
                         .setDeviceId("my-device-id")
                         .setKeyPair(keyPairObject)
                         .build()

var iotCoreClient = IotCoreClient.Builder()
              .setIotCoreConfiguration(configuration)
              .setOnConfigurationListener(onConfigurationListener)
              .setConnectionCallback(connectionCallback)
              .build()

iotCoreClient.connect()

Next, you can publish telemetry information or device state, using the following Kotlin examples.

private fun publishTelemetry(temperature: Float, humidity: Float) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"temperature" : $temperature,
        |"humidity": $humidity
        |}""".trimMargin().toByteArray()
    val event = TelemetryEvent(examplePayload, topicSubpath, TelemetryEvent.QOS_AT_LEAST_ONCE)
    iotCoreClient.publishTelemetry(event)
}

private fun publishDeviceState(telemetryFrequency: Int, enabledSensors: Array<String>) {
    // payload is an arbitrary, application-specific array of bytes
    val examplePayload = """{
        |"telemetryFrequency": $telemetryFrequency,
        |"enabledSensors": ${enabledSensors.contentToString()}
        |}""".trimMargin().toByteArray()
    iotCoreClient.publishDeviceState(examplePayload)
}

Additional resources

You can learn more about building for Android Things at the developer site. For more information about getting started with Cloud IoT Core, visit the information page and documentation. Finally, join Google’s IoT Developers Community on Google+ to let us know what you’re building with Android Things and Cloud IoT Core!

Better Biometrics in Android P

Android Developers June 21, 2018 android p, android security, Biometric authentication, BiometricPrompt, BiometricPrompt API, Biometrics

Posted by Vishwath Mohan, Security Engineer

To keep users safe, most apps and devices have an authentication mechanism, or a way to prove that you’re you. These mechanisms fall into three categories: knowledge factors, possession factors, and biometric factors. Knowledge factors ask for something you know (like a PIN or a password), possession factors ask for something you have (like a token generator or security key), and biometric factors ask for something you are (like your fingerprint, iris, or face).

Biometric authentication mechanisms are becoming increasingly popular, and it’s easy to see why. They’re faster than typing a password, easier than carrying around a separate security key, and they prevent one of the most common pitfalls of knowledge-factor based authentication—the risk of shoulder surfing.

As more devices incorporate biometric authentication to safeguard people’s private information, we’re improving biometrics-based authentication in Android P by:

  • Defining a better model to measure biometric security, and using that to functionally constrain weaker authentication methods.
  • Providing a common platform-provided entry point for developers to integrate biometric authentication into their apps.

A better security model for biometrics

Currently, biometric unlocks quantify their performance today with two metrics borrowed from machine learning (ML): False Accept Rate (FAR), and False Reject Rate (FRR).

In the case of biometrics, FAR measures how often a biometric model accidentally classifies an incorrect input as belonging to the target user—that is, how often another user is falsely recognized as the legitimate device owner. Similarly, FRR measures how often a biometric model accidentally classifies the user’s biometric as incorrect—that is, how often a legitimate device owner has to retry their authentication. The first is a security concern, while the second is problematic for usability.

Both metrics do a great job of measuring the accuracy and precision of a given ML (or biometric) model when applied to random input samples. However, because neither metric accounts for an active attacker as part of the threat model, they do not provide very useful information about its resilience against attacks.

In Android 8.1, we introduced two new metrics that more explicitly account for an attacker in the threat model: Spoof Accept Rate (SAR) and Imposter Accept Rate (IAR). As their names suggest, these metrics measure how easily an attacker can bypass a biometric authentication scheme. Spoofing refers to the use of a known-good recording (e.g. replaying a voice recording or using a face or fingerprint picture), while impostor acceptance means a successful mimicking of another user’s biometric (e.g. trying to sound or look like a target user).

Strong vs. Weak Biometrics

We use the SAR/IAR metrics to categorize biometric authentication mechanisms as either strong or weak. Biometric authentication mechanisms with an SAR/IAR of 7% or lower are strong, and anything above 7% is weak. Why 7% specifically? Most fingerprint implementations have a SAR/IAR metric of about 7%, making this an appropriate standard to start with for other modalities as well. As biometric sensors and classification methods improve, this threshold can potentially be decreased in the future.

This binary classification is a slight oversimplification of the range of security that different implementations provide. However, it gives us a scalable mechanism (via the tiered authentication model) to appropriately scope the capabilities and the constraints of different biometric implementations across the ecosystem, based on the overall risk they pose.

While both strong and weak biometrics will be allowed to unlock a device, weak biometrics:

  • require the user to re-enter their primary PIN, pattern, password or a strong biometric to unlock a device after a 4-hour window of inactivity, such as when left at a desk or charger. This is in addition to the 72-hour timeout that is enforced for both strong and weak biometrics.
  • are not supported by the forthcoming BiometricPrompt API, a common API for app developers to securely authenticate users on a device in a modality-agnostic way.
  • can’t authenticate payments or participate in other transactions that involve a KeyStore auth-bound key.
  • must show users a warning that articulates the risks of using the biometric before it can be enabled.

These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.

BiometricPrompt API

Starting in Android P, developers can use the BiometricPrompt API to integrate biometric authentication into their apps in a device and biometric agnostic way. BiometricPrompt only exposes strong modalities, so developers can be assured of a consistent level of security across all devices their application runs on. A support library is also provided for devices running Android O and earlier, allowing applications to utilize the advantages of this API across more devices .

Here’s a high-level architecture of BiometricPrompt.

The API is intended to be easy to use, allowing the platform to select an appropriate biometric to authenticate with instead of forcing app developers to implement this logic themselves. Here’s an example of how a developer might use it in their app:

Conclusion

Biometrics have the potential to both simplify and strengthen how we authenticate our digital identity, but only if they are designed securely, measured accurately, and implemented in a privacy-preserving manner.

We want Android to get it right across all three. So we’re combining secure design principles, a more attacker-aware measurement methodology, and a common, easy to use biometrics API that allows developers to integrate authentication in a simple, consistent, and safe manner.

Acknowledgements: This post was developed in joint collaboration with Jim Miller

Grow and optimize your subscriptions with new Google Play features

Android Developers June 20, 2018 Android app development, android developers, Featured, Google Play, monetization, subscriptions

Posted by Larry Yang and Angela Ying, Product Managers, Google Play

Subscriptions on Google Play continue to see huge growth, with subscribers growing over 80% year over year. At I/O 2018, we announced several improvements we’re making to the user experience to reduce barriers to subscription sign-up, and more tools to let you manage your business the way you want to.

More control for subscribers

While users derive a lot of value from their subscriptions, our research shows their fears of being “trapped” in a subscription without the ability to cancel or worry they’ll lose track of how much they’re spending create a hindrance to users signing up for your subscription apps. To address these fears, we recently launched a new subscriptions center, a one-stop shop for users to manage their subscriptions on Google Play.

Through the subscriptions center, users can:

  • View all of their subscriptions to see details and status
  • Manage and update payment methods, including setting up a backup payment method
  • Renew a subscription
  • Restore a cancelled subscription
  • Cancel a subscription

In addition, if a user cancels a subscription, we will now trigger a cancellation survey to give developers feedback as to why the user is cancelling. Currently you can see the data from the cancellation survey by querying our server side API.

The new subscriptions center also has a “Get Started” link in the empty state that lets users discover subscription apps through curated and localized collections.

With the launch of the subscriptions center, we’re also launching new deep links you can use to direct your users to manage their subscriptions from your app, over email or via the web. To implement, use the package name and SKU to construct the deep link, and then add the deep link as a button or link from anywhere in your app. View the Android Developers website for more information.

More control for you

In addition to creating a better experience for users, we’re also rolling out new tools that give you more flexibility in managing your business. One of the features we’ve heard requested most is price changes. Coming soon, you can easily ask users to accept a price change via the Google Play Console without having to set up a completely new SKU. Google Play will notify users of the change via emails, push notifications and in-app messaging, and if by renewal date the user hasn’t agreed, we’ll cancel their subscription. Sign up here if you are interested in participating in the early access program.

Other features we launched at I/O that help you better manage your subscription business include the ability to:

This is in addition to faster test renewals and flexible intro pricing we announced earlier this year.

To easily implement all of these, make sure you are using the Google Play Billing Library, which launched version 1.1 at I/O. The billing library is an abstraction layer on top of the AIDL file, and API updates are automatically picked up when you update your build dependency file the next time you compile your app. Price changes and upgrade/downgrade with the same expiration date are only available through the billing library. This will be the case for future launches as well.

Better for everyone

We strongly believe that by building a great user experience, we build a high quality subscriber base. And by giving you tools and insights to better manage your business, you have the flexibility to do what is best for your business and your customers.

How useful did you find this blogpost?


Google Play security metadata and offline app distribution

Android Developers June 19, 2018 Android Developer, Featured, Google Play

Posted by James Bender, Product Manager, Google Play

In December last year we announced that we would be making updates to app security to help verify product authenticity from Google Play. We are now adding a small amount of security metadata on top of APKs to verify that the APK was distributed by Google Play.

One of the reasons we’re doing this is to help developers reach a wider audience, particularly in countries where peer-to-peer app sharing is common because of costly data plans and limited connectivity.

In the future, for apps obtained through Play-approved distribution channels, we’ll be able to determine app authenticity while a device is offline, add those shared apps to a user’s Play Library, and manage app updates when the device comes back online. This will give people more confidence when using Play-approved peer-to-peer sharing apps.

This also benefits you as a developer as it provides a Play-authorized offline distribution channel and, since the peer-to-peer shared app is added to your user’s Play library, your app will now be eligible for app updates from Play.

No action is needed by developers or by those who use your app or game. We’re adjusting Google Play’s maximum APK size to take into account the small metadata addition, which is inserted into the APK Signing Block. In addition to improving the integrity of Google Play’s mobile app ecosystem, this metadata will also present new distribution opportunities for developers and help more people keep their apps up to date.

How useful did you find this blogpost?


#IMakeApps – Celebrating app makers worldwide

Android Developers June 18, 2018 Android Developer, App, Apps, Featured, Game, Google Play, Story

Posted by Patricia Correa, Director, Developer Marketing, Platforms & Ecosystems

The Android developer ecosystem is made up of exceptional individuals with different backgrounds, interests, and dreams. To celebrate the people who make up our community, starting today, and over the coming months, we’ll be meeting with developers, founders, product managers, designers, and others from around the world to hear more about their passions and discover what they do when they step away from their computers.

Watch stories featuring adventurer Niek Bokkers from Polarsteps (Netherlands), artist Faith Ringgold from Quiltuduko (USA) and chair restorer Hans Jørgen Wiberg from Be My Eyes (Denmark). You can also read more about them and their apps on g.co/play/imakeapps.

Share your story

We’d love to hear from you too. Use the hashtag #IMakeApps on your social channels, sharing the app or game you work on, your role in its creation, and an image that best depicts who you are outside of work. We will regularly select and share some of our favorites on our channels.

If you also want to get featured in an upcoming #IMakeApps film, tell us more about yourself and your app or game, by completing this self-nomination form.

Stay tuned for more #IMakeApps stories by following us on Twitter, YouTube and LinkedIn.

How useful did you find this blogpost?

Android P Beta 2 and final APIs!

Android Developers June 6, 2018 Developer Preview

Posted By Dave Burke, VP of Engineering

Android P Logo

Four weeks ago at Google I/O we released the first beta version of Android P, putting AI at the core of the operating system and focusing on intelligent and simple experiences.

We talked about some of Android’s newest features in the keynotes and went deep on the developer APIs during the breakouts. If you missed the livestream, make sure to check out the full playlist of Android talks.

Today we’re releasing Android P Beta 2, an update that includes the final Android P APIs, the latest system images, and updated developer tools to help you get ready for the consumer release coming later in the summer.

You can get Android P Beta 2 on Pixel devices by enrolling here. If you’re already enrolled and received the Android P Beta 1 on your Pixel device, you’ll automatically get the update to Beta 2. Partners that are participating in the Android P Beta program will be updating their devices over the coming weeks.

Enhance your app with Android P features and APIs

Android P Beta 2 is the latest update of our upcoming Android P platform and includes the final APIs (API level 28) as well as the official SDK. You can get started building with the Android P features and APIs today. Here are a few we want you to try — head over to the features overview for more.

Machine learning at the core

Adaptive battery image

We partnered with DeepMind on a feature we call Adaptive Battery that uses machine learning to prioritize system resources for the apps the user cares about most. If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. Make sure to check out the details in the power documentation to see how it works and where the impacts could be, and test your apps to make sure they are ready.

App Actions is a new way to help you raise the visibility of your app and help drive engagement. Actions take advantage of machine learning on Android to surface your app to the user at just the right time, based on your app’s semantic intents and the user’s context. Actions work on Android P and earlier versions of the platform and they’ll be available soon for you to start using. Sign up here to be notified when Actions are available.

Slices are a new way to surface rich, templated content in places like Google Search and Assistant. They’re interactive, and through Android Jetpack they’re compatible all the way back to KitKat. Check out the Getting Started guide to learn how to build with Slices — you can use the SliceViewer tool to see how your Slices look. Over time we plan to expand the number of places that your Slices can appear, including remote display in other apps.

Simplicity, polish

Android P adds platform support for screens with display cutouts, and we’ve added new APIs to let you deliver a rich, edge-to-edge experience on the latest screens. Cutout support works seamlessly for apps, with the system managing status bar height to separate your content from the cutout. If you have immersive content, you can use the display cutout APIs to check the position and shape of the cutout and request full-screen layout around it.

All developers should check out the docs to learn how to manage the cutout area and avoid common compatibility issues that can affect apps. Make sure to test your app on a device that has a display cutout, such as one of the Android P Beta devices.

Immersive content display.

Apps with immersive content can display content fullscreen on devices with a display cutout.

If your app uses messaging notifications, take advantage of the changes in MessagingStyle that make notifications even more useful and actionable. You can now show conversations, attach photos and stickers, and even suggest smart replies. You’ll soon be able to use ML Kit to generate smart reply suggestions your app.

MessagingStyle notifications

MessagingStyle notifications

MessagingStyle notifications with conversations and smart replies [left], images and stickers [right].

Security

Verify purchase icon

With a range of biometric sensors in use for authentication, we’ve made the experience more consistent across sensor types and apps. Android P introduces a system-managed dialog to prompt the user for any supported type of biometric authentication. Apps no longer need to build their own dialog — instead they use the BiometricPrompt API to show the standard system dialog. In addition to Fingerprint (including in-display sensors), the API supports Face and Iris authentication.

If your app is drawing its own fingerprint auth dialogs, you should switch to using the BiometricPrompt API as soon as possible.

More

If your app uses the device camera, try the new multi-camera APIs that let you access streams simultaneously from two or more physical cameras. On devices with dual cameras, you can create innovative features not possible with a single camera — such as seamless zoom, bokeh, and stereo vision. You can get started today using any of the Android P Beta devices that offers a dual camera.

Audio apps can use the Dynamics Processing API for access to a multi-stage, multi-band dynamics processing effect to modify the audio coming out of Android devices and optimize it according to the preferences of the listener or the ambient conditions.

Dynamics Processing API
Take a look at the Android P features overview for a complete list of the new features and APIs.

Get started in a few simple steps

Android Virtual Device

First, make your app compatible and give your users a seamless transition to Android P. Just install your current app from Google Play on a Android P Beta device or emulator and test — the app should run and look great, and handle Android P behavior change for all apps properly. After you’ve made any necessary updates, we recommend publishing to Google Play right away without changing the app’s platform targeting.

If you don’t have a supported device, remember that you can set up an Android Virtual Device on the Android Emulator as your test environment instead. If you haven’t tried the emulator recently, you’ll find that it’s incredibly fast, boots in under 6 seconds, and even lets you model next-gen screens — such as long screens and screens with display cutout.

Next, update your app’s targetSdkVersion to 28 as soon as possible, so Android P users of your app can benefit from the platform’s latest security, performance, and stability features. If your app is already targeting API 26+ in line with Google Play’s upcoming policies, then changing to target 28 should be a small jump.

It’s also important to test your apps for uses of non-SDK interfaces and reduce your reliance on them. As noted previously, in Android P we’re starting a gradual process to restrict access to selected non-SDK interfaces. Watch for logcat warnings that highlight direct uses of restricted non-SDK interfaces and try the new StrictMode method detectNonSdkApiUsage() to catch accesses programmatically. Where possible, you should move to using public equivalents from the Android SDK or NDK. If there’s no public API that meets your use-case, please let us know.

When you’re ready, dive into Android P and learn about the new features and APIs to extend your apps. To build with the new APIs, just download the official API 28 SDK and tools into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project’s compileSdkVersion and targetSdkVersion to API 28.

Visit the Developer Preview site for details and documentation. Also check out this video and the Google I/O Android playlist for more on what’s new in Android P for developers.

Publish to Google Play alpha, beta, or production channels

Starting today you can publish your APK updates that are compiled against, or optionally targeting, API 28. Publishing an update to Google Play during the preview lets you push updates to users to test compatibility on existing devices, including devices running Android P Beta 2.

To make sure that your updated app runs well on Android P 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 Android P Beta 2 users — and then do a staged rollout to production.

How to get Android P Beta 2

For Pixel devices, you can enroll your device in the Android Beta program and you’ll automatically receive the update to Android P Beta 2 over-the-air. If you’re already enrolled and received Beta 1, watch for the update coming your way soon. Partners that are participating in the Android P Beta program will be updating their devices over the coming weeks.

You can see the full list of supported partner and Pixel devices at android.com/beta. For each device you’ll find specs and links to the manufacturer’s dedicated site for downloads, support, and to report issues.

Thanks for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. Feel free to use our hotlists for platform issues, app compatibility issues, and third-party SDK issues.

We’re looking forward to seeing your apps on Android P!

Project Capillary: End-to-end encryption for push messaging, simplified

Android Developers June 5, 2018 Android, Authentication, encryption, fcm, GCM, push messaging, security

Posted by Giles Hogben, Privacy Engineer and Milinda Perera, Software Engineer

Developers already use HTTPS to communicate with Firebase Cloud Messaging (FCM). The channel between FCM server endpoint and the device is encrypted with SSL over TCP. Ho…

Insider Attack Resistance

Android Developers May 31, 2018 insider attack resistance, mobile encryption, Pixel, Pixel 2, secure hardware, security, tamper-resistant hardware security

Posted by Shawn Willden, Staff Software Engineer

Our smart devices, such as mobile phones and tablets, contain a wealth of personal information that needs to be kept safe. Google is constantly trying to find new and better ways to protect that valuable information on Android devices. From partnering with external researchers to find and fix vulnerabilities, to adding new features to the Android platform, we work to make each release and new device safer than the last. This post talks about Google’s strategy for making the encryption on Google Pixel 2 devices resistant to various levels of attack—from platform, to hardware, all the way to the people who create the signing keys for Pixel devices.

We encrypt all user data on Google Pixel devices and protect the encryption keys in secure hardware. The secure hardware runs highly secure firmware that is responsible for checking the user’s password. If the password is entered incorrectly, the firmware refuses to decrypt the device. This firmware also limits the rate at which passwords can be checked, making it harder for attackers to use a brute force attack.

To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.

In the past, device makers have focused on safeguarding these keys by storing the keys in secure locations and severely restricting the number of people who have access to them. That’s good, but it leaves those people open to attack by coercion or social engineering. That’s risky for the employees personally, and we believe it creates too much risk for user data.

To mitigate these risks, Google Pixel 2 devices implement insider attack resistance in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user’s cooperation. Specifically, it is not possible to upgrade the firmware that checks the user’s password unless you present the correct user password. There is a way to “force” an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user’s data, effectively destroying it.

The Android security team believes that insider attack resistance is an important element of a complete strategy for protecting user data. The Google Pixel 2 demonstrated that it’s possible to protect users even against the most highly-privileged insiders. We recommend that all mobile device makers do the same. For help, device makers working to implement insider attack resistance can reach out to the Android security team through their Google contact.

Acknowledgements: This post was developed in joint collaboration with Paul Crowley, Senior Software Engineer

All the (Android) Things at Google I/O

Android Developers May 25, 2018 #io18, Android, Android Things, android things 1.0, I/O 2018

Melissa Daniels, Program Manager for Android Things

Android Things enables you to build and maintain IoT devices at scale. We recently released Android Things 1.0 with long-term support for production devices, so you can easily take an IoT device from prototype to commercial product.

We packed Google I/O this year with Android Things content to inspire and empower the developer community, from talks and codelabs to interactive demos and a scavenger hunt. Here’s a closer look at the fun stuff we had on display that you won’t see on the shelves of retail stores.

Demos

We introduced a handful of new interactive Android Things demos across I/O, showcasing the AI and ML capabilities of the platform, so if you didn’t get an opportunity to attend this year, here’s a few of our favorites– perfect for exploring from wherever you are in the world!

Smart Flowers: Flos Mobilis

What do you get when you combine machine learning, Android Things and robotics? Flos Mobilis, a continuum robot where each flower is backed by an i.MX7D development board and a camera to run an embedded neural net model that controls the motion of the flower. This is all done offline with no data stored or transmitted.

Smart Flowers: Flos Affectus

What if a robot could respond to the way you feel? Flos Affectus is a cluster of robotic flowers that “bloom” and “un-bloom” depending on the expression detected on the user’s face. The 4 broad expressions Flos Affectus is trained to detect are: happy, sad, angry, surprised. Using a camera embedded in the head of the alpha flower, the flower cluster is able to detect the user’s face and infer the facial emotion. The flower cluster runs offline with no data stored or transmitted and demonstrates movement capabilities and on-device machine learning models.

Rosie the Android

Initially designed by a team of Google engineers for the annual Grace Hopper conference, Rosie the Android is a 5 foot selfie-taking Android, complete with machine-learning capabilities. Inspired by Rosie the Riveter, she’s a fully controllable robot that can take photos, respond to commands, wheel around and interact with those around her.

Did you take a selfie with Rosie at I/O? Redeem your unique access code at g.co/rosie

Smart Projector

Smart Projector is built on Lantern, an Android Things project exploring the relationship between surfaces and content — augmenting real-world objects and environments with glanceable, meaningful data. It leverages the Google Experiments project known as Quick Draw, using the world’s largest doodling data set that has been shared publicly to help with machine learning research.

To learn more about Lantern or to start building your own, start here.

3D Printer

This modified Printrbot Smalls 3D Printer uses a real-time subsystem that showcases the flexibility of Android Things– a microcontroller does the low-latency motor control, while Android Things handles OpenGL rendering. By keeping most of the logic on a high-level platform like Android you make development and debugging much easier, thanks to Android’s great tooling.

The future of 3D printing? Making real-time control as easy and portable as the rest of Android Things.

Codelabs

Phew! That was just the tip of the demo iceberg. With so many demos and so many ways to use Android Things, it’s easy to start imagining all the things you can build! At I/O, we helped a lot of developers get started building their first Android Things device using the Android Things Starter Kit. We’re making these codelabs available, so you can get to them whenever you need, or build your own.

Videos

Missed the I/O talks? Catch the recordings of each Android Things talk, so you can start, pause, and rewind at your own leisure. Or, just lean back and watch them all.

What’s new in Android Things

Build effective OEM-level apps on Android Things

Build real consumer devices with Android Things

Electronic design for Android Things System on Modules

Women Techmakers panel: experiences developing on Android Things

Product design: how to build better products with Android Things

Device provisioning and authentication with Android Things

Update production devices in the field with the Android Things Console

Start building!

On top of all the resources we just mentioned, we have a corpus of information on our developer documentation, and our new community website where you can see more inspiring projects and even submit your own. So, what are you waiting for? Pick up an Android Things Starter Kit and start building something today!

Faster Adoption with Project Treble

Android Developers May 9, 2018 #io18, Android, android p, Featured, Project Treble

Posted by Iliyan Malchev, Project Treble Architect

Android P Beta available at android.com/beta

As Android continues to evolve, each new release of the OS brings new features, new user experiences, and better security. It is important that these new releases find their way to mobile devices as fast as possible.

Yesterday, we announced that the following devices, in addition to Pixel and Pixel 2, now support Android P Beta: Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21, OnePlus 6 and Essential PH‑1. Android P Beta provides an opportunity for developers and early adopters around the world to try the latest Android release, test their apps, and provide feedback.

In this post, we provide an update to Project Treble and the technology that allowed us to bring Android Beta to more phones this year.

Building the Foundation

Bringing the new Android release quickly to the hands of users takes a combined effort between Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. This process is technically challenging and requires aligning the schedules between our industry partners.

To reduce the technical difficulties, we launched Project Treble as part of Android Oreo.

The Silicon Manufacturers

Next, to capitalize on the foundation we built, we collaborated closely with the silicon manufacturers, where the journey of making an Android device always begins.

Any device with the latest version of Android must be based on an SoC with the proper software support for it. This software, commonly referred to as the Board Support Package (BSP), contains not only the chip-specific vendor implementation, but also all of the Android Open Source Project (AOSP) and pieces of the framework that are missing from AOSP itself (e.g., carrier-specific telephony functionality).

The life cycle of an Android Dessert release passes through Silicon Manufacturer Partners, Device Makers and Carriers, until it gets to the hands of the end-users.

These BSPs are the starting point for all device launches. OEMs adapt the vendor implementation to their hardware and add their own custom framework components.

While silicon manufacturers always want the latest version of Android in their BSPs, the costs have been prohibitive. By making it possible for newer AOSP frameworks to run on older, already-released vendor implementations, Project Treble dramatically reduces the need for continuous investment in older silicon to support each Android release. Silicon manufacturers have to do all this work just once, rather than every time there is a new release of Android.

Solving the Timing Problem

However, that first time still has to happen. Below is a chart, which illustrates the effort the various actors expend over time as they go through each release. You can think of it as code churn or bug count over time.

Overlapping timelines and efforts for dessert adoption among Android, Chip Support and OEMs increase the overall effort to get the Android release out.

The chart shows how there is very little time in the year for Google, silicon manufacturers, and the OEMs to all this work. Any overlap between phases causes code churn and introduces significant schedule risk. For OEMs who target the holiday season, it is often safer to launch on an older BSP with a year-old or even older Android version. This dynamic has been at the heart of the slow uptake of the latest Android release, even on flagship devices.

Qualcomm, Samsung and MediaTek co-develop their BSP with Android.

To solve this, we’ve worked closely with Qualcomm, MediaTek and Samsung SLSI to co-develop their BSPs, starting with Android P. Their BSPs are now ready for Android P on a much-accelerated schedule, reducing the overall effort significantly. These silicon manufacturers are now able to provide a stable and high-quality release much earlier than before, allowing OEMs to bring the latest innovations of Android to their customers across the globe.

Devices can launch earlier with Project Treble as the timeline for developing Android and Chipset Support overlaps.

This is an important step in accelerating the adoption of Android releases that bring numerous benefits to our partners, users, and Android developers. We look forward to seeing many more partners launch or upgrade devices to Android P.

Page 1 of 5
Scroll Up