Android – Reader@mReotEch.com

Android Studio 3.2

Posted by Jamal Eason, Product Manager, Android

Today, Android Studio 3.2 is available for download. Android Studio 3.2 is the best way for app developers to cut into the latest Android 9 Pie release and build the new Android App bundle. Since announcing this update of Android Studio at Google I/O '18, we have refined and polished 20+ new features and focused our efforts on improving the quality for this stable release of Android Studio 3.2.

Every developer should use Android Studio 3.2 to transition to using an Android App Bundle, the new app publishing format. With very minimal work, you can generate an app bundle with Android Studio. Once you upload your app bundle to Google Play you can distribute smaller, optimized apps to your users. Early adopters have already seen between 11% - 64% in app size savings with app bundles over the legacy APK app size.

Another feature you do not want to miss is the Energy Profiler. This new profiler gives you a set of tools that will help you diagnose and improve the energy impact of your app. Better device battery life is one of the top most user requests, and with the Energy Profiler in Android Studio 3.2, you can do your part in improving device battery life by making sure your app is using the right amount of energy at the right time.

Lastly, you should also check out the new Android Emulator Snapshots feature. By using this feature, you can quickly take a snapshot of the current state of your emulator which includes the current state of the screen, apps, and settings. You can resume or boot into your emulator snapshot in under 2 seconds. For any app developer looking for super- fast boot times, or seeking to run tests in a predictable Android environment, Android Emulator Snapshots is a game changing feature for app development

On top of these major features, there are 20 new features plus many under-the-hood quality refinements in Android Studio 3.2. By using Android Studio 3.2, you can also develop for the latest technologies ranging from Android Jetpack, to the latest in Google Artificial Intelligence (AI) APIs with Android Slices.

Thank you to those who gave your early feedback on both the canary and beta releases. Your feedback helped us improve the quality and features in Android Studio 3.2. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 3.2 is ready to download for you to get started.

Below is a full list of new features in Android Studio 3.2, organized by key developer flows.

Develop

Slices support - Slices is a new way to tap into the built-in Android AI capabilities by surfacing app content in Google Search suggestions and the Google Assistant. Android Studio 3.2 has a built-in template to help you extend your app with the new Slice Provider APIs as well as new lint checks to ensure that you're following best practices when constructing the slices. To use, right-click on a project folder, and navigate to New→ Other→ Slice Provider. Learn more.

Slices Provider Template

Sample Data - This feature allows you to use placeholder data to aid in the design of your app. This will help you visualize layouts that depend on runtime data. You can add built-in sample data to populate views such as RecyclerViews, ImageViews, and TextViews via a popup-window in the Layout Editor. Learn more.

Material Design Update - When you start migrating from the Android Design support library to the new MaterialComponents app theme and library, Android Studio 3.2 will offer you access to new and updated widgets such as BottomAppBar, buttons, cards, text fields, new font styles and more. Learn more.

CMakeList Editing Support - For those using C/C++ in their app, Android Studio has better support for CMake. With this release of Android Studio 3.2, code completion and syntax highlighting now works on common CMakeList build script commands.

What's New Assistant - Android Studio 3.2 has a new assistant panel that opens automatically after an update to inform you about the latest changes to the IDE. You can also open the panel by navigating to Help → What's New in Android Studio.

AndroidX Refactoring Support - One of the components of Android Jetpack is the introduction of the Android extension libraries (AndroidX) as a replacement for the Android Support Libraries. To add AndroidX to a new project you just need to add android.useAndroidX=true to your gradle.properties file. Additionally, Android Studio 3.2 has a new built-in refactoring action to help migrate your project the new namespace and dependencies. Also if you have any Maven dependencies that have not migrated to the AndroidX namespace, the Android Studio build system will automatically convert those project dependencies as well. Learn more.

IntelliJ Platform Update - Android Studio 3.2 includes the IntelliJ 2018.1.6 platform release. This IntelliJ release adds many improvements to dataflow analysis, debugging, new inspections, inline external annotations, partial Git commits, plus much more. Learn more.
Kotlin Update - Android Studio 3.2 bundles Kotlin 1.2.61, with support for the Kotlin-friendly Android 9 Pie SDK. Learn more.

Build

Android App Bundle - The Android App Bundle is the new app publishing format designed to help you deliver smaller APKs to your users and reduce download size of your app. Google Play's new app serving model, called Dynamic Delivery, processes your app bundle to generate and serve optimized APKs for each user's device configuration, so they download only the code and resources they need to run your app. With Android Studio 3.2 or via the command line, you can easily build your code as an app bundle and get the benefit of smaller APKs based on language, screen density, and ABIs with no changes to your app code. Learn more.

Build Android App Bundle

D8 Desugaring - In some cases, new Java Language features require new bytecodes and language APIs. However, older Android devices may not support these features. Desugaring allows you to use these features on older devices by replacing new bytecodes and language APIs with older ones during the build process. D8 desugaring is turned on by default for Android Studio 3.2 and you can now use most of the latest language changes while targeting older devices.

R8 Optimizer - Starting with Android Studio 3.2, we are starting the transition to use R8 as a replacement for ProGuard to optimize and shrink Java language bytecode. R8 is still experimental, so we do not recommend publishing your app using R8 yet, but it is a good time to give the Android Studio team early feedback so we can make any adjustments before R8 fully replaces ProGuard. Learn more.

Test

Emulator Snapshots - The latest release of the Android Emulator allows you to create a snapshot of the current state of your emulator and boot up and switch into any snapshot in under 2 seconds. Built upon the Android Emulator Quickboot feature, Android Snapshots are even faster to save and load with this stable release due to under-the-hood speed enhancements. When testing and developing your app, Android snapshots allow you to pre-configure an Android Virtual Device (AVD) snapshot with the presets, apps, data and settings that you want in-place, and repeatedly go back to the same snapshot. Learn more.

Android Emulator Snapshots

Microsoft^® Hyper-V™ Support - You can now run the Android Emulator on Windows^® 10 computers that have Hyper-V enabled. Intel HAXM is still the default hypervisor for the fastest Android Emulator experience. However,thanks to recent open source contributions by Microsoft, and the addition of the new Windows Hypervisor Platform (WHPX) API, the Android Emulator can coexist with other Hyper-V-backed applications, like local Virtual Machines, using the new Hyper-V Support. Learn more.
AMD^® Processor Support - AMD Processors are now supported by the Android Emulator on Windows 10. Previously running the Android Emulator was limited to slow software emulation when running Windows, but developers who have an AMD processor can now have hardware accelerated performance. Learn more.
Screen Record in Android Emulator - You can now record both screen and audio on any Android API level with the new screen record feature in the Android Emulator. In the past, screen recording on a physical Android device only worked on Android 4.4 KitKat (API 19) and above with no audio, with limited Android Emulator support. With the latest Android Emulator (v28.0.+) you no longer have this restriction. As an added bonus, there is a built-in conversion to output to GIF and WebM. You can trigger the new screen record feature via the Android Emulator Extended Controls panel, command line and from Android Studio. Lean more
Virtual Scene Camera for Android Emulator - The new Virtual Scene camera in the Android Emulator helps you to develop for ARCore, Google's platform for building augmented reality experiences. The emulator is calibrated to work with ARCore APIs for AR apps and also allows you to inject virtual scene bitmap images. The virtual scene camera can also be used as a regular HAL3 compatible camera. Learn more.
ADB Connection Assistant - Android Studio 3.2 has a new assistant system to help troubleshoot your Android ADB device connections issues. The ADB Connection Assistant walks you through common troubleshooting steps to connect your Android device to your development machine. You can trigger the assistant from the Run dialog box or by navigating to Tools → Connection Assistant . Learn more.

Optimize

Energy Profiler - Battery life is a key concern for many phone users, and your app may impact battery life more than you realize. The new Energy Profiler in the Android Studio 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. To use the energy profiler, ensure you are connected to an Android device or emulator running Android 8.0 Oreo (API 26) or higher. Learn more.

Energy Profiler

System Trace - The new System Trace feature in the CPU Profiler allows you to inspect how your app interacts with system resources in fine-grained detail. Inspect exact timings and durations of your thread states, visualize where your CPU bottlenecks are across all cores, and add custom trace events to analyze. To use system trace, start profiling your app, click into the CPU Profiler, and then choose the System Trace recording configuration. Learn more.

Profiler Sessions - We now automatically save Profiler data as "sessions" to revisit and inspect later while you have Android Studio open. We've also added the ability to import and export your CPU recordings and heap dumps for later analysis or inspection with other tools. Learn more.

Automatic CPU Recording - You can now automatically record CPU activity using the Debug API. After you deploy your app to a device, the profiler automatically starts recording CPU activity when your app calls startMethodTracing(String tracePath), and stops recording when your app calls stopMethodTracing(). Similarly, you can also now automatically start recording CPU activity on app start-up by enabling Start Recording a Method Trace on Startup option in your run configuration. Learn more.

JNI Reference Tracking - For those of you who have C/C++ code in your Android app, Android Studio 3.2 now allows you to inspect the memory allocations of your JNI code in the Memory Profiler. As long as you deploy your app to a device running Android 8.0 Oreo (API 26) and higher, you can drill down into the allocation call stack from your JNI reference. To use the feature, start a memory profiler session, and select the JNI Heap from the Live Allocation drop-down menu. Learn more.

To recap, the latest canary of Android Studio 3.2 includes these new major features:

Develop

AndroidX Refactoring
Sample Data
Material Design Update
Android Slices
CMakeList editing
What's New Assistant
New Lint Checks
Intellij Platform Update
Kotlin Update

Build

Android App Bundle
D8 Desugaring
R8 Optimizer

Test

Android Emulator Snapshots
Screen Record in Android Emulator
Virtual Scene Android Emulator Camera
AMD Processor Support
Hyper-V Support
ADB Connection Assistant

Optimize

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

Check out the release notes for more details.

Getting Started

Download the latest version of Android Studio 3.2 from the download page. If you are using a previous canary release of Android Studio, make sure you update to Android Studio Canary 14 or higher. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary 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 v28.0.7+ downloaded via the Android Studio SDK Manager.

We appreciate any feedback on things you like, and issues or features you would like to see. Please note, to maintain high product quality, a couple features (e.g. Navigation Editor) you saw in earlier release channels are not enabled by default in the stable release channel. 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.

Samsung and Google Collaborate on RCS Messaging for Android

Samsung Electronics and Google announced they are working together to offer an enhanced smartphone messaging experience, accelerating the industry initiative toward global Rich Communication Services (RCS) coverage and interoperability. This collaboration will ensure that Android Messages and Samsung Messages will work seamlessly together and with RCS messagin g, enabling features like the ability to chat over WiFi, create rich group chats, see typing indicators and read receipts, and share high-resolution photos and videos across platforms.

Working together, Google and Samsung will ensure that their messaging clients, Android Messages and Samsung Messages, work seamlessly with each company’s RCS technology, including cloud and business messaging platforms. To date, Google and Samsung have collaborated to introduce RCS to select Samsung devices; as part of this expanded collaboration, Samsung will work to bring these RCS features to existing mobile phones^* beginning with the Galaxy S8 and S8+. New Samsung Galaxy smartphones will also natively support RCS messaging^**, starting with those on a set of carriers that have or will soon launch RCS. This means that consumers and brands will be able to enjoy richer chats with both Android Messages and Samsung Messages users.

“At Samsung, we adhere to a model of open collaboration to bring premium experiences to our customers across products,” said Patrick Chomet, EVP and Head of Product & Services Innovation Team, Mobile Communications Business at Samsung Electronics. “By furthering our robust partnership with Google, we will bring a richer messaging experience to our customers, letting them seamlessly chat with their friends and family across messaging platforms. This collaboration will help further the industry’s momentum toward advanced messaging and global RCS coverage.”

“We’ve been working with the mobile industry to upgrade the messaging experience on Android with RCS,” said Anil Sabharwal, Vice President for Communications Products and Photos at Google. “Samsung has been a major contributor to this initiative, and our partnership will further advance our shared vision of a substantially improved messaging experience on Android for users, brands and the broader Android ecosystem.”

As a further benefit of this expanded partnership, developers and brands that create RCS Business Messaging experiences (based on GSMA Universal Profile 2.0) using the Google or Samsung Messaging-as-a-Platform (MaaP) services will be able to reach both Android Messages and Samsung Messages users, bringing richer business messaging to many more users.

This collaboration further accelerates the adoption and availability of RCS globally, enabling an enhanced messaging experience across the entire Android ecosystem.

^*Will include Samsung Galaxy S8, S8+, S8 Active, S9, S9+, Note8, Note9, and select A and J series running Android 9.0 or later. Subject to carrier and market availability.

^**RCS capabilities will be available for select Galaxy smartphones on carriers that support RCS.

About Google

Google’s mission is to organize the world’s information and make it universally accessible and useful. Through products and platforms like Search, Maps, Gmail, Android, Google Play, Chrome and YouTube, Google plays a meaningful role in the daily lives of billions of people and has become one of the most widely-known companies in the world. Google is a subsidiary of Alphabet.

Make the most of Notifications with the redesigned Wear OS by Google

Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

Today we announced that we are evolving the design of Wear OS by Google to help you get the most out of your time - providing quicker access to your information and notifications. Notifications can come from the automatic bridging of the phone's notification or be generated by a local Wear app running on the watch. Whether you are a phone developer, a Wear app developer, or both, there are a few things you will need to know about the new notification stream.

The new notification stream

Until now, each notification took up the entire screen in Wear OS. Although this provided more space to include things like inline action, it also meant it took a long time for the user to go through all their notifications. The new notification stream is more compact, and can display multiple notifications on the same screen. This means users can process their notification streams more quickly.

What this means for developers

Concise notification content is even more important. The new unexpanded notification on Wear will show up to three lines of text. Because this is already more information than a single line unexpanded notification on the user's phone, if your notification works on the phone unexpanded, it should be fine on Wear.
Brand notification with color. The default title and icon color for notification is white. Developers can now convey their brand identities by customizing the color of the title and icon tint using setColor.
Custom notification layout will no longer be supported. Previously developers used setDisplayIntent to inflate a custom activity inside the notification stream. We have found that the custom layout often does not take into account of the device form factor, and is difficult to keep up to date as Wear OS's notification experience evolves. As a result, we will no longer support this in notifications.
Inline action is being reviewed. To save space, the new layout no longer display inline action in the stream and setHintDisplayActionInline will be ignored. Users can continue to access notification actions including inline action when they tap to expand the notification. Our design team is reviewing whether we should include inline action in a future release. As a result, before a decision is made, we are not deprecating the related APIs. We will keep the developer community updated in due course.

As always, the current best practices for notification still apply. In particular, for messaging apps developers, we strongly encourage the use of MessagingStyle notification and enabling on-device Smart Reply through setAllowGeneratedReplies.

We will start rolling these changes out in the next month, so watch for updates on your Wear OS by Google smartwatch!

Avast security products win awards | Avast

You deserve protection online, no matter what device or operating system you are using. When we started Avast, over 30 years ago, our motto was “cybersecurity for everyone.” Today, those words still serve as our guiding star, and we are committed to providing everybody with all the tools necessary to be safe and secure in their digital worlds.

Fake app infects your Android with spyware | Avast

In 2016, an app called “Sex Game” was available in the Google Play store. And while it was legitimate, the bluntly titled app did not last long in the store. Soon it was gone.

Evolution of Android Security Updates

Posted by Dave Kleidermacher, VP, Head of Security - Android, Chrome OS, Play

At Google I/O 2018, in our What's New in Android Security session, we shared a brief update on the Android security updates program. With the official release of Android 9 Pie, we wanted to share a more comprehensive update on the state of security updates, including best practice guidance for manufacturers, how we're making Android easier to update, and how we're ensuring compliance to Android security update releases.

Commercial Best Practices around Android Security Updates

As we noted in our 2017 Android Security Year-in-Review, Android's anti-exploitation strength now leads the mobile industry and has made it exceedingly difficult and expensive to leverage operating system bugs into compromises. Nevertheless, an important defense-in-depth strategy is to ensure critical security updates are delivered in a timely manner. Monthly security updates are the recommended best practice for Android smartphones. We deliver monthly Android source code patches to smartphone manufacturers so they may incorporate those patches into firmware updates. We also deliver firmware updates over-the-air to Pixel devices on a reliable monthly cadence and offer the free use of Google's firmware over-the-air (FOTA) servers to manufacturers. Monthly security updates are also required for devices covered under the Android One program.

While monthly security updates are best, at minimum, Android manufacturers should deliver regular security updates in advance of coordinated disclosure of high severity vulnerabilities, published in our Android bulletins. Since the common vulnerability disclosure window is 90 days, updates on a 90-day frequency represents a minimum security hygiene requirement.

Enterprise Best Practices

Product security factors into purchase decisions of enterprises, who often consider device security update cadence, flexibility of policy controls, and authentication features. Earlier this year, we introduced the Android Enterprise Recommended program to help businesses make these decisions. To be listed, Android devices must satisfy numerous requirements, including regular security updates: at least every 90 days, with monthly updates strongly recommended. In addition to businesses, consumers interested in understanding security update practices and commitment may also refer to the Enterprise Recommended list.

Making Android Easier to Update

We've also been working to make Android easier to update, overall. A key pillar of that strategy is to improve modularity and clarity of interfaces, enabling operating system subsystems to be updated without adversely impacting others. Project Treble is one example of this strategy in action and has enabled devices to update to Android P more easily and efficiently than was possible in previous releases. The modularity strategy applies equally well for security updates, as a framework security update can be performed independently of device specific components.

Another part of the strategy involves the extraction of operating system services into user-mode applications that can be updated independently, and sometimes more rapidly, than the base operating system. For example, Google Play services, including secure networking components, and the Chrome browser can be updated individually, just like other Google Play apps.

Partner programs are a third key pillar of the updateability strategy. One example is the GMS Express program, in which Google is working closely with system-on-chip (SoC) suppliers to provide monthly pre-integrated and pre-tested Android security updates for SoC reference designs, reducing cost and time to market for delivering them to users.

Security Patch Level Compliance

Recently, researchers reported a handful of missing security bug fixes across some Android devices. Initial reports had several inaccuracies, which have since been corrected. We have been developing security update testing systems that are now making compliance failures less likely to occur. In particular, we recently delivered a new testing infrastructure that enables manufacturers to develop and deploy automated tests across lower levels of the firmware stack that were previously relegated to manual testing. In addition, the Android build approval process now includes scanning of device images for specific patterns, reducing the risk of omission.

Looking Forward

In 2017, about a billion Android devices received security updates, representing approximately 30% growth over the preceding year. We continue to work hard devising thoughtful strategies to make Android easier to update by introducing improved processes and programs for the ecosystem. In addition, we are also working to drive increased and more expedient partner adoption of our security update and compliance requirements. As a result, over coming quarters, we expect the largest ever growth in the number of Android devices receiving regular security updates.

Bugs are inevitable in all complex software systems, but exploitability of those bugs is not. We're working hard to ensure that the incidence of potentially harmful exploitation of bugs continues to decline, such that the frequency for security updates will reduce, not increase, over time. While monthly security updates represents today's best practice, we see a future in which security updates becomes easier and rarer, while maintaining the same goal to protect all users across all devices.

Alternative input methods for Android TV

Posted by Benjamin Baxter, Developer Advocate and Bacon Connoisseur

All TVs have the same problem with keyboard input: It is very cumbersome to hunt and peck for each letter using a D-pad with a remote. And if you make a mistake, trying to correct it compounds the problem.

APIs like Smart Lock and Autofill, can ease user's frustrations, but for certain types of input, like login, you need to collect complex input that is difficult for users using the on-screen keyboard.

With the Nearby Connections API, you can use a second screen to gather input from the user with less friction.

How Nearby Connections works

From the documentation:

"Nearby Connections is an offline peer-to-peer socket model for communication based on advertising and discovering devices in proximity.

Usage of the API falls into two phases: pre-connection, and post-connection.

In the pre-connection phase, Advertisers advertise themselves, while Discoverers discover nearby Advertisers and send connection requests. A connection request from a Discoverer to an Advertiser initiates a symmetric authentication flow that results in both sides independently accepting (or rejecting) the connection request.

After a connection request is accepted by both sides, the connection is established and the devices enter the post-connection phase, during which both sides can exchange data."

In most cases the TV is the advertiser and the phone is the discoverer. In the example below, the assumed second device is a phone. The API and patterns described in this article are not limited to a phone. For example, a tablet could also be the second screen device.

Login Example

There are many times when keyboard input is required. Authenticating users and collecting billing information (like zip codes and name on card) are common cases. This example handles a login flow that uses a second screen to see how Nearby Connections can help reduce friction.

1. The user opens your app on her TV and needs to login. You can show a screen of options similar to the setup flow for a new TV.

2. After the user chooses to login with their phone, the TV should start advertising and send the user to the associated login app on their phone, which should start discovering.

There are a variety of solutions to open the app on the phone. As an example, Android TV's setup flow has the user open the corresponding app on their mobile device. Initiating the hand-off is a more a UX concern than a technology concern.

3. The phone app should display the advertising TV and prompt the user to initiate the connection. After the (encrypted -- see Security Considerations below for more on this) connection is established the TV can stop advertising and the phone can stop discovering.

"Advertising/Discovery using Nearby Connections for hours on end can affect a device's battery. While this is not usually an issue for a plugged-in TV, it can be for mobile devices, so be conscious about stopping advertising and discovery once they're no longer needed."

4. Next, the phone can start collecting the user's input. Once the user enters their login information, the phone should send it to the TV in a BYTES payload over the secure connection.

5. When the TV receives the message it should send an ACK (using a BYTES payload) back to the phone to confirm delivery.

6. When the phone receives the ACK, it can safely close the connection.

The following diagram summarizes the sequence of events:

UX considerations

Nearby Connections needs location permissions to be able to discover nearby devices. Be transparent with your users. Tell them why they need to grant the location permission on their phone.

Since the TV is advertising, it does not need location permissions.

Start advertising: The TV code

After the user chooses to login on the phone, the TV should start advertising. This is a very simple process with the Nearby API.

override fun onGuidedActionClicked(action: GuidedAction?) {
    super.onGuidedActionClicked(action)
    if( action == loginAction ) {
        // Update the UI so the user knows to check their phone
        navigationFlowCallback.navigateToConnectionDialog()
        doStartAdvertising(requireContext()) { payload ->
            handlePayload(payload)
        }
    }
}

When the user clicks a button, update the UI to tell them to look at their phone to continue. Be sure to offer a way to cancel the remote login and try manually with the cumbersome onscreen keyboard.

This example uses a GuidedStepFragment but the same UX pattern applies to whatever design you choose.

Advertising is straightforward. You need to supply a name, a service id (typically the package name), and a `ConnectionLifeCycleCallback`.

You also need to choose a strategy that both the TV and the phone use. Since it is possible that the users has multiple TVs (living room, bedroom, etc) the best strategy to use is P2P_CLUSTER.

Then start advertising. The onSuccessListener and onFailureListener tell you whether or not the device was able to start advertising, they do not indicate a device has been discovered.

fun doStartAdvertising(context: Context) {
    Nearby.getConnectionsClient(context).startAdvertising(
        context.getString(R.string.tv_name),
        context.packageName,
        connectionLifecycleCallback,
        AdvertisingOptions.Builder().setStrategy(Strategy.P2P_CLUSTER).build()
    )
    .addOnSuccessListener {
        Log.d(LoginStepFragment.TAG, "We are advertising!")
    }
    .addOnFailureListener {
        Log.d(LoginStepFragment.TAG, "We cannot start advertising.")
        Toast.makeText(
            context, "We cannot start advertising.", Toast.LENGTH_LONG)
                .show()
    }
}

The real magic happens in the `connectionLifecycleCallback` that is triggered when devices start to initiate a connection. The TV should accept the handshake from the phone (after performing the necessary authentication -- see Security Considerations below for more) and supply a payload listener.

val connectionLifecycleCallback = object : ConnectionLifecycleCallback() {

    override fun onConnectionInitiated(
            endpointId: String, 
            connectionInfo: ConnectionInfo
    ) {
        Log.d(TAG, "Connection initialized to endpoint: $endpointId")
        // Make sure to authenticate using `connectionInfo.authenticationToken` 
        // before accepting
        Nearby.getConnectionsClient(context)
            .acceptConnection(endpointId, payloadCallback)
    }

    override fun onConnectionResult(
        endpointId: String, 
        connectionResolution: ConnectionResolution
    ) {
        Log.d(TAG, "Received result from connection: ${connectionResolution.status.statusCode}")
        doStopAdvertising()
        when (connectionResolution.status.statusCode) {
            ConnectionsStatusCodes.STATUS_OK -> {
                Log.d(TAG, "Connected to endpoint: $endpointId")
                otherDeviceEndpointId = endpointId
            }
            else -> {
                otherDeviceEndpointId = null
            }
        }
    }

    override fun onDisconnected(endpointId: String) {
        Log.d(TAG, "Disconnected from endpoint: $endpointId")
        otherDeviceEndpointId = null
    }
}

The payloadCallback listens for the phone to send the login information needed. After receiving the login information, the connection is no longer needed. We go into more detail later in the Ending the Conversation section.

Discovering the big screen: The phone code

Nearby Connections does not require the user's consent. However, the location permission must be granted in order for discovery with Nearby Connections to work its magic. (It uses BLE scanning under the covers.)

After opening the app on the phone, start by prompting the user for location permission if not already granted on devices running Marshmallow and higher.

Once the permission is granted, start discovering, confirm the connection, collect the credentials, and send a message to the TV app.

Discovering is as simple as advertising. You need a service id (typically the package name -- this should be the same on the Discoverer and Advertiser for them to see each other), a name, and a `EndpointDiscoveryCallback`. Similar to the TV code, the flow is triggered by callbacks based on the connection status.

Nearby.getConnectionsClient(context).startDiscovery(
        context.packageName,
        mobileEndpointDiscoveryCallback,
        DiscoveryOptions.Builder().setStrategy(Strategy.P2P_CLUSTER).build()
        )
        .addOnSuccessListener {
            // We're discovering!
            Log.d(TAG, "We are discovering!")
        }
         .addOnFailureListener {
            // We were unable to start discovering.
            Log.d(TAG, "We cannot start discovering!")
        }

The Discoverer's listeners are similar to the Advertiser's success and failure listeners; they signal if the request to start discovery was successful or not.

Once you discover an advertiser, the `EndpointDiscoveryCallback` is triggered. You need to keep track of the other endpoint to know who to send the payload, e.g.: the user's credentials, to later.

val mobileEndpointDiscoveryCallback = object : EndpointDiscoveryCallback() {
    override fun onEndpointFound(
        endpointId: String, 
        discoveredEndpointInfo: DiscoveredEndpointInfo
    ) {
        // An endpoint was found!
        Log.d(TAG, "An endpoint was found, ${discoveredEndpointInfo.endpointName}")
        Nearby.getConnectionsClient(context)
            .requestConnection(
                context.getString(R.string.phone_name), 
                endpointId, 
                connectionLifecycleCallback)
    }

    override fun onEndpointLost(endpointId: String) {
        // A previously discovered endpoint has gone away.
        Log.d(TAG, "An endpoint was lost, $endpointId")
    }
}

One of the devices must initiate the connection. Since the Discoverer has a callback for endpoint discovery, it makes sense for the phone to request the connection to the TV.

The phone asks for a connection supplying a `connectionLifecycleCallback` which is symmetric to the callback in the TV code.

val connectionLifecycleCallback = object : ConnectionLifecycleCallback() {
    override fun onConnectionInitiated(
        endpointId: String,
        connectionInfo: ConnectionInfo
    ) {
        Log.d(TAG, "Connection initialized to endpoint: $endpointId")
        // Make sure to authenticate using `connectionInfo.authenticationToken` before accepting
        Nearby.getConnectionsClient(context)
                .acceptConnection(endpointId, payloadCallback)
    }

    override fun onConnectionResult(
        endpointId: String,
        connectionResolution: ConnectionResolution
    ) {
        Log.d(TAG, "Connection result from endpoint: $endpointId")
        when (connectionResolution.status.statusCode) {
            ConnectionsStatusCodes.STATUS_OK -> {
                Log.d(TAG, "Connected to endpoint: $endpointId")
                otherDeviceEndpointId = endpointId
                waitingIndicator.visibility = View.GONE
                emailInput.editText?.isEnabled = true
                passwordInput.editText?.isEnabled = true

                Nearby.getConnectionsClient(this).stopDiscovery()
            }
            else -> {
                otherDeviceEndpointId = null
            }
        }
    }

    override fun onDisconnected(endpointId: String) {
        Log.d(TAG, "Disconnected from endpoint: $endpointId")
        otherDeviceEndpointId = null
    }
}

Once the connection is established, stop discovery to avoid keeping this battery-intensive operation running longer than needed. The example stops discovery after the connection is established, but it is possible for a user to leave the activity before that happens. Be sure to stop the discovery/advertising in onStop() on both the TV and phone.

override fun onStop() {
    super.onStop()
    Nearby.getConnectionsClient(this).stopDiscovery()
}

Just like a TV app, when you accept the connection you supply a payload callback. The callback listens for messages from the TV app such as the ACK described above to clean up the connection.

After the devices are connected, the user can use the keyboard and send their authentication information to the TV by calling `sendPayload()`.

fun sendCreditials() {

    val email = emailInput.editText?.text.toString()
    val password = passwordInput.editText?.text.toString()

    val creds = "$email:$password"
    val payload = Payload.fromBytes(creds.toByteArray())
    Log.d(TAG, "sending payload: $creds")
    if (otherDeviceEndpointId != null) {
        Nearby.getConnectionsClient(this)
                .sendPayload(otherDeviceEndpointId, payload)
    }
}

Ending the conversation

After the phone sends the payload to the TV (and the login is successful), there is no reason for the devices to remain connected. The TV can initiate the disconnection with a simple shutdown protocol.

The TV should send an ACK to the phone after it receives the credential payload.

val payloadCallback = object : PayloadCallback() {
    override fun onPayloadReceived(endpointId: String, payload: Payload) {
        if (payload.type == Payload.Type.BYTES) {
            payload.asBytes()?.let {
                val body = String(it)
                Log.d(TAG, "A payload was received: $body")
                // Validate that this payload contains the login credentials, and process them.

                val ack = Payload.fromBytes(ACK_PAYLOAD.toByteArray())
                Nearby.getConnectionsClient(context).sendPayload(endpointId, ack)
            }
        }
    }

    override fun onPayloadTransferUpdate(
        endpointId: String,
        update: PayloadTransferUpdate
    ) {    }
}

The phone should have a `PayloadCallback` that initiates a disconnection in response to the ACK. This is also a good time to reset the UI to show an authenticated state.

private val payloadCallback = object : PayloadCallback() {
    override fun onPayloadReceived(endpointId: String, payload: Payload) {
        if (payload.type == Payload.Type.BYTES) {
            payload.asBytes()?.let {
                val body = String(it)
                Log.d(TAG, "A payload was received: $body")

                if (body == ACK_PAYLOAD) {
                    waitingIndicator.visibility = View.VISIBLE
                    waitingIndicator.text = getString(R.string.login_successful)
                    emailInput.editText?.isEnabled = false
                    passwordInput.editText?.isEnabled = false
                    loginButton.isEnabled = false

                    Nearby.getConnectionsClient(this@MainActivity)
                        .disconnectFromEndpoint(endpointId)
                }
            }
        }
    }

    override fun onPayloadTransferUpdate(
        endpointId: String,
        update: PayloadTransferUpdate
    ) {    }
}

Security considerations

For security (especially since we're sending over sensitive information like login credentials), it's strongly recommended that you authenticate the connection by showing a code and having the user confirm that the two devices being connected are the intended ones -- without this, the connection established by Nearby Connection is encrypted but not authenticated, and that's susceptible to Man-In-The-Middle attacks. The documentation goes into greater detail on how to authenticate a connection.

Does your app offer a second screen experience?

There are many times when a user needs to supply input to a TV app. The Nearby API provides a way to offload the hardships of an onscreen-dpad-driven keyboard to an easy and familiar phone keyboard.

What use cases do you have where a second screen would simplify your user's life? Leave a comment or send me (@benjamintravels) or Varun (@varunkapoor, Team Lead for Nearby Connections) a tweet to continue the discussion.

AV-Comparatives: Trend Micro Mobile Security for Android Provides 100% Malware Protection for Mobile Users

With the introduction of Android v8.0 (Android Oreo) in August of 2017, among other OS improvements Google introduced its built-in malware protection for Android call Play Protect (dependent on Google Play Services 11 or later). Play Protect checks apps and APK files downloaded from Google Play or third-party sources, using real-time and on-demand scanners, while also providing safe browsing and device loss protections.

While built-in antimalware is a welcome addition in a dangerous Android Internet environment, Google Play Protect is not yet quite up-to-snuff, as shown in the recent tests performed by AV-Comparatives’ Mobile Security Review 2018 conducted in July and revised in August. In that test cycle, its protection rate was actually quite low (only a 51% catch rate among 2,604 recent malware samples tested.) It’s also not much help in Asian countries, nor in any other region where use of other non-Google-owned Android app stores is rampant; nor is it included in Android 7/7.1, 6.0, or 5/5.1, which retain the lion’s share of Android users (some 79%).

Android users clearly need better protection—and here, Trend Micro Mobile Security for Android steps up to the plate. It achieved 100%-protection rate in the same AV-Comparative tests, with no false positives, and received an Approved Mobile Product badge, standing securely among the five leading products in a field of twelve, while also having little effect on battery life (less than 3%). Achieving a rating of 100% protection is particularly good when you consider Trend Micro Mobile Security for Android has achieved this result in AV-Comparatives’ tests for the last four years running. They also acknowledge it to be “a comprehensive app offering malware protection, an anti-theft module [Lost Device Protection], and additional, helpful features for managing the device.” These additional helpful management features include a System Tuner and an App Manager, alongside the full-fledged functionality of a Security Scanner, a Safe Surfing function, a Wi-Fi Checker, Parental Controls, Social Network Privacy for Facebook and Twitter, and a Call Blocking function.

Visit AV-Comparatives’ Mobile Security Review 2018 to download a PDF of the review.

Visit Trend Micro Mobile Security for more information, or to buy the program for Android or iOS.

The post AV-Comparatives: Trend Micro Mobile Security for Android Provides 100% Malware Protection for Mobile Users appeared first on .

Streaming support spec for hearing aids on Android

Posted by Seang Chau, Vice President, Engineering

According to the World Health Organization¹, around 466 million people worldwide have disabling hearing loss. This number is expected to increase to 900 million people by the year 2050. Google is working with GN Hearing to create a new open specification for hearing aid streaming support on future versions of Android. Users with hearing loss will be able to connect, pair, and monitor their hearing aids so they can hear their phones loudly and clearly.

Hearing aid users expect a high quality, low latency experience with minimal impact on phone and hearing aid battery life. We've published a new hearing aid spec for Android smartphones: Audio Streaming for Hearing Aids (ASHA) on Bluetooth Low Energy Connection-Oriented Channels. ASHA is designed to have a minimal impact on battery life with low-latency while maintaining a high quality audio experience for users who rely on hearing aids. We look forward to continually evolving the spec to even better meet the needs of our users.

The spec details the pairing and connectivity, network topology, system architecture, and system requirements for implementing hearing aids using low energy connection-oriented channels. Any hearing aid manufacturer can now build native hearing aid support for Android.

The protocol specification is available here.

Updating Wear OS Google Play Store policy to increase app quality

Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

Today we are announcing a new initiative to improve Wear app quality and their presentation in the Google Play Store. The Wear app review process, which has been in place since the launch of Android Wear 2.0, is currently optional. It will become mandatory for apps to be listed on the Wear OS by Google version of the Google Play Store from the following dates:

New Wear apps: 1 October 2018
Existing Wear apps: 4 March 2019.

The review process for mobile apps remains unchanged, and is independent of the Wear app review. Mobile app updates will not be blocked if they fail the Wear app review.

We hope this lightweight app review process will improve the quality of Wear app experiences across the wide range of devices available to your users. In addition, since screenshots are required for the Wear app review, this will improve the discovery and presentation of your Wear apps in the Google Play Store.

See a comprehensive list of review criteria here. The following are common issues we see during Wear app reviews:

Support for different screen types - Wear OS by Google is available in both round and square screens, and some round devices also have a chin. Developers are advised to test on all screen types. If a physical device is unavailable, please use the Wear OS by Google emulator.
Wear OS by Google app screenshot - To pass the review, the app needs to have at least one Wear OS app screenshot. To keep pre-release Wear apps private, the Google Play Store will not show the Wear screenshots unless the Wear App is in production or open testing. Currently, the Google Play Store only supports uploading one set of screenshots across all production and test versions. For existing Wear apps, we recommend developers keeping their production Wear app screenshots unchanged when uploading new open test or closed test Wear apps.

Opting out of app review for early prototypes

We understand that some developers need to experiment with their Wear apps in the early stages of app development, and a Wear app review at this stage might not be appropriate. In this case, developers have two options:

Manually deploy Wear APKs to their users, or
Leverage internal testing features via the Google Play console, which enables developers to test with up to 100 internal testing accounts.

Please note that the open test and closed test channels will be subject to Wear app review to help front-load the quality assurance process and to avoid leaving reviews to the last minute.

Thank you for your continuing support of Wear OS by Google.

Looking forward with Google Play

Posted by Purnima Kochikar, Director, Google Play, Apps & Games

On Monday we released Android 9 Pie. As we continue to push the Android platform forward, we're always looking to provide new ways to distribute your apps efficiently, help people discover and engage with your work, and improve the overall security of our ecosystem. Google Play has had a busy year so far with some big milestones around helping you reach more users, including:

Shrinking download size: Android App Bundle & Dynamic Delivery has helped reduce app sizes by up to 65%, leading to increased downloads and fewer uninstalls.
Helping improve quality: New tools in the Play Console have helped you reduce crash rates by up to 70%.
Improving discovery: Improvements to the discovery experience have increased Google Play Store visits by 30% over the last 12 months.
Keeping users safe: Google Play Protect scans more than 50 billion apps a day and Android API level 26 adoption requirements improve app security and performance.

Google Play is dedicated to helping you build and grow quality app businesses, reach the more than 2 billion Android devices globally and provide your users with better experiences. Here are some of the important areas we're prioritizing this year:

Innovative Distribution

We've added more testing tools to the popular Play Console to help developers de-risk app launches with internal and external test tracks and staged rollouts to get valuable early feedback. This year we've expanded the Start on Android program globally that provides developers new to Android additional guidance to optimize their apps before launch. Google Play Instant remains a huge bet to transform app discovery and improve conversions by letting users engage without the friction of installing. We're seeing great results from early adopters and are working on new places to surface instant experience, including ads, and making them easier to build throughout the year.

Improving App Quality

Google Play plays an important role helping developers understand and fix quality and performance issues. At I/O, we showcased how we expanded the battery, stability and rendering of Android vitals reporting to include app start time & permission denials, enabling developers to cut application not responding errors by up to 95%. We also expanded the functionality of automated device testing with the pre-launch report to enable games testing. Recently, we increased the importance of app quality in our search and discovery recommendations that has resulted in higher engagement and satisfaction with downloaded games.

Richer Discovery

Over the last year we've rolled out more editorial content and improved our machine learning to deliver personalized recommendations for apps and games that engage users. Since most game downloads come from browsing (as opposed to searching or deep linking into) the store, we've put particular focus on games discovery, with a new games home page, special sections for premium and new games, immersive video trailers and screenshots, and the ability to try games instantly. We've also introduced new programs to help drive app downloads through richer discovery. For example, since launching our app pre-registration program in 2016, we've seen nearly 250 million app pre-registrations. Going forward, we'll be expanding on these programs and others like LiveOps cards to help developers engage more deeply with their audience.

Expanding Commerce Platform

Google Play now collects payments in 150 markets via credit card, direct carrier billing (DCB), Paypal, and gift cards. Direct carrier billing is now enabled across 167 carriers in 64 markets. In 2018, we have focused on expanding our footprint in Africa and Latam with launches in Ghana, Kenya, Tanzania, Nigeria, Peru & Colombia. And users can now buy Google Play credit via gift cards or other means in more 800,000 retail locations around the world. This year, we also launched seller support in 18 new markets bringing the total markets with seller support to 98. Our subscription offering continues to improve with ML-powered fraud detection and even more control for subscribers and developers. Google Play's risk modeling automatically helps detect fraudulent transactions and purchase APIs help you better analyze your refund data to identify suspicious activity.

Maintaining a Safe & Secure Ecosystem

Google Play Protect and our other systems scan and analyze more than 50 billion apps a day to keep our ecosystem safe for users and developers. In fact, people who only download apps from Google Play are nine times less likely to download a potentially harmful app than those who download from other sources. We've made significant improvements in our ability to detect abuse—such as impersonation, inappropriate content, fraud, or malware—through new machine learning models and techniques. The result is that 99% of apps with abusive content are identified and rejected before anyone can install them. We're also continuing to run the Google Play Security Rewards Program through a collaboration with Hacker One to discover other vulnerabilities.

We are continually inspired by what developers build—check out #IMakeApps for incredible examples—and want every developer to have the tools needed to succeed. We can't wait to see what you do next!

The Best and Safest Phones for Kids of All Ages | Avast

Some kids take their first steps into the digital world at the tender age of one, when they discover Elmo apps on the family iPad. By the time we give them their first cell phones, they’re already familiar with the web, basic internet etiquette, and the way mobile devices work — let’s face it, they’re a savvy generation.

Start your day on a high note with musical alarms on the Google Clock app

Starting today, you’ll be able to wake up to your favorite music on Spotify with the Google Clock app. Swap out the classic alarm sounds for your favorite pump-up song, a calming soundtrack or a mood-boosting melody.

To get started with musical alarms, make sure the latest versions of your Spotify and Clock apps are installed and connected on your device—this works for both Free and Premium Spotify users. Then choose your perfect wake up music. You can browse recently played music, choose from Spotify’s curated morning playlists, or search for a specific soundtrack.

Now when your musical alarm goes off, it will be a whole lot easier to get moving. After switching off your alarm, you’ll have the option to continue listening to Spotify throughout your day.

This feature will be rolling out globally this week on the Play Store, and will be available on all devices running Android 5.0 (Lollipop) and above.

Mobile Apps Must Roll Back Welcome Mat for Cybercriminals

Mobile devices may seem like the pinnacle of digital sophistication, but in terms of security, they lag far behind laptops and desktops—meaning that the mobile trove of valuable consumer information, browsing histories and location tracking is more vulnerable to attack.

Updating your games for modern Android

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 has created more choice, not less

If you buy an Android phone, you’re choosing one of the world’s two most popular mobile platforms—one that has expanded the choice of phones available around the world.

Today, the European Commission issued a competition decision against Android, and its business model. The decision ignores the fact that Android phones compete with iOS phones, something that 89 percent of respondents to the Commission’s own market survey confirmed. It also misses just how much choice Android provides to thousands of phone makers and mobile network operators who build and sell Android devices; to millions of app developers around the world who have built their businesses with Android; and billions of consumers who can now afford and use cutting-edge Android smartphones.

Today, because of Android, there are more than 24,000 devices, at every price point, from more than 1,300 different brands, including Dutch, Finnish, French, German, Hungarian, Italian, Latvian, Polish, Romanian, Spanish and Swedish phone makers.

The phones made by these companies are all different, but have one thing in common—the ability to run the same applications. This is possible thanks to simple rules that ensure technical compatibility, no matter what the size or shape of the device. No phone maker is even obliged to sign up to these rules—they can use or modify Android in any way they want, just as Amazon has done with its Fire tablets and TV sticks.

To be successful, open-source platforms have to painstakingly balance the needs of everyone that uses them. History shows that without rules around baseline compatibility, open-source platforms fragment, which hurts users, developers and phone makers. Android’s compatibility rules avoid this, and help make it an attractive long-term proposition for everyone.

Creating flexibility, choice and opportunity

Today, because of Android, a typical phone comes preloaded with as many as 40 apps from multiple developers, not just the company you bought the phone from. If you prefer other apps—or browsers, or search engines—to the preloaded ones, you can easily disable or delete them, and choose other apps instead, including apps made by some of the 1.6 million Europeans who make a living as app developers.

In fact, a typical Android phone user will install around 50 apps themselves. Last year, over 94 billion apps were downloaded globally from our Play app store; browsers such as Opera Mini and Firefox have been downloaded more than 100 million times, UC Browser more than 500 million times.

This is in stark contrast to how things used to be in the 1990s and early 2000s—the dial-up age. Back then, changing the pre-installed applications on your computer, or adding new ones, was technically difficult and time-consuming. The Commission’s Android decision ignores the new breadth of choice and clear evidence about how people use their phones today.

A platform built for the smartphone era

In 2007, we chose to offer Android to phone makers and mobile network operators for free. Of course, there are costs involved in building Android, and Google has invested billions of dollars over the last decade to make Android what it is today. This investment makes sense for us because we can offer phone makers the option of pre-loading a suite of popular Google apps (such as Search, Chrome, Play, Maps and Gmail), some of which generate revenue for us, and all of which help ensure the phone ‘just works’, right out of the box. Phone makers don’t have to include our services; and they’re also free to pre-install competing apps alongside ours. This means that we earn revenue only if our apps are installed, and if people choose to use our apps instead of the rival apps.

Good for partners, good for consumers

The free distribution of the Android platform, and of Google’s suite of applications, is not only efficient for phone makers and operators—it’s of huge benefit for developers and consumers. If phone makers and mobile network operators couldn’t include our apps on their wide range of devices, it would upset the balance of the Android ecosystem. So far, the Android business model has meant that we haven't had to charge phone makers for our technology, or depend on a tightly controlled distribution model.

We’ve always agreed that with size comes responsibility. A healthy, thriving Android ecosystem is in everyone’s interest, and we’ve shown we’re willing to make changes. But we are concerned that today’s decision will upset the careful balance that we have struck with Android, and that it sends a troubling signal in favor of proprietary systems over open platforms.

Rapid innovation, wide choice, and falling prices are classic hallmarks of robust competition and Android has enabled all of them. Today’s decision rejects the business model that supports Android, which has created more choice for everyone, not less. We intend to appeal.

#AndroidWorks

How creating an Action can complement your Android app

Posted by Neto Marin - Actions on Google Developer Advocate

There are millions of apps in the Android ecosystem, so helping yours get discovered can require some investment. Your app needs to offer something that differentiates it from other similar apps to stand out to users.

Building a companion Action is a fast and simple way to increase your Android app's potential reach by creating a new entrypoint from devices covered by the Google Assistant. This lets you bring your services to users without needing to install anything through voice, and can bring people into your app when it can provide more value.

Your companion Action complements your Android app's experience by offering some of your services through the Google Assistant, which is available on more than 500 million devices including speakers, phones, cars, headphones, and more. Creating an Action provides a frictionless way for users to start engaging with your services wherever the Google Assistant is available.

Creating an Action for the Assistant will extend your brand presence, bringing your services to new devices and contexts as users interact with the Google Assistant.

Feature what your app does better

It is probably a mistake to try to rewrite all of your Android app as a conversational Action, since voice is a different modality with different constraints and usage patterns. Instead, you should start by selecting the most important or popular features in your app that translate well into a voice context and can be more easily accomplished there. Then, you can create your conversational experience to offer these features on Google Assistant devices. Check out the Conversation design site, which has several articles and guides about how to create a great voice UI.

Let's take a look at a hypothetical example. Imagine you have a mobile commerce app. Some features include searching for products, navigating to different categories, adding payment information, and checking out. You could build an Action for the Assistant with most of the same functionality, but we encourage you to look for what makes the most sense in a conversational experience.

In this case, your Action could focus on everything that a user would want to know after they've purchased a product through your Android app or web page. You could offer a quick way to get updates about a purchase's status (if you provide different states for payment/purchase process) and shipment information, or provide an interface for re-ordering a user's favorite products. Then, your users would be able to ask something like, "Hey Google, ask Voice Store about my last purchase."

Or, to reach users who have never made a purchase before, you could create an Action to offer exciting deals for common products. For example, you could create an Action that is invoked with, "Hey Google, ask Voice Store what are the deals on TVs today".

As you can see, starting with a "hero" use case for your Action is an exciting way to introduce conversational features that complement your Android app, and it will take less time than you think.

At Google I/O 2018, we presented a talk, "Integrating your Android apps with the Google Assistant" which contains more details and examples for developers.

Delivering user's purchases across surfaces

In-app purchases, subscriptions, and one-time products have proven successful for Android developers when it comes to monetization, allowing developers to offer different kinds of digital goods and additional value for paying users. These types of monetization are proven to drive user conversion and make the app more profitable.

Google Play Billing offers a series of tools, APIs, and documentation to help developers manage the subscription life-cycle, build server-side validation, and much more. If you are new to in-app billing, check out the Google Play Billing Overview page.

Now, Android developers can expand where users can access these goods or upgraded experiences by offering them through Actions, as well. This expansion is accomplished by honoring the user's entitlements on Google Play across different surfaces and devices, reaching users when they can't (or don't want to) use an app, like while cooking or driving.

For non-Android platforms, you'll need to ask your users to link their accounts. You can then use your user's account history to identify what purchases they've made on other surfaces.

Check the Accessing Digital Purchases page for a step-by-step guide on how to enable access to the user's purchases and request and parse the purchase data.

What's next?

If you are not familiar with Actions on Google yet, start by checking out our overview page, which describes the platform in detail and tells you all you need to know to create your Actions for the Google Assistant.

Stay tuned for more posts about how to improve your Android app experience with Actions on Google.

Thanks for reading!

Android Emulator – AMD Processor & Hyper-V Support

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.

Android Studio 3.2 Beta

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 Build → Generate 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:

What's new in Android development tools
An overview of all the recent features in Android Studio for Android app developers. The session includes demos and a tour de force presentation of relevant features that will accelerate developers' workflow on the latest Android APIs.
What's new with the Android build system
A deep dive into the new features of the Android build system.
What's new with ConstraintLayout and Android Studio design tools
This session covers the new features in ConstraintLayout 2.0, as well as the latest functionality added in Android Studio design tools, highlighting how to effectively take advantage of them for designing, prototyping, and building a graphical user interface application.
Improve app performance with Android Studio Profilers
This talk demonstrates how to diagnose and troubleshoot performance problems with your app using Android Studio Profilers. It covers examples of how to use the CPU, memory, network profilers, and highlight what's new.
Best practices using compilers in Android Studio
This session discusses in-depth what is happening to the various compilers used in Android: Java 8 language feature desugaring, the new dexer (D8) and shrinker (R8), and work done on the Kotlin compiler for Android use.
Android Jetpack: manage UI navigation with Navigation Controller
This session discusses how to use the Navigation Editor in Android Studio, XML or the Java API to define your navigation graph, and how that simplifies navigating around your app and handling deep linking.

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.

Wear OS developer preview reenabling alarms and jobs for background apps

Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

From the outset of the Wear OS by Google developer preview, battery life has been a major focus area. When we talked to the developer community, the update that attracted the most feedback was the disabling of alarms and jobs for background apps. After listening to developer feedback and reviewing the battery statistics, we are reversing this change. This should be reflected in all connected Wear OS preview devices, so there is no need to reflash your device.

App Standby Buckets

The decision came as we reviewed the feedback and saw that a strict on/off setting prevents reasonable usage and promotes anti-patterns. Going forward, we plan to leverage the App Standby Buckets feature in Android P to fine-tune a suitable setting for Wear OS devices. The exact setting for alarms and jobs for background apps is still being iterated on. Developers are advised to follow the best practices to make sure their apps behave well, whichever bucket the apps are in.

Input and data privacy in background apps

Another area that developers should pay attention to is the strengthening of input and data privacy for background apps in Android P. Depending on an app's requirements, developers may need to use a foreground service to enable access to the device sensor throughout the day.

Please give us your feedback

We expect to provide more updates to this preview before the final production release. Please submit any bugs you find via the Wear OS by Google issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.

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

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. However, messages are not encrypted end-to-end (E2E) between the developer server and the user device unless developers take special measures.

To this end, we advise developers to use keys generated on the user device to encrypt push messages end-to-end. But implementing such E2E encryption has historically required significant technical knowledge and effort. That is why we are excited to announce the Capillary open source library which greatly simplifies the implementation of E2E-encryption for push messages between developer servers and users' Android devices.

We also added functionality for sending messages that can only be decrypted on devices that have recently been unlocked. This is designed to support decrypting messages on devices using File-Based Encryption (FBE): encrypted messages are cached in Device Encrypted (DE) storage and message decryption keys are stored in Android Keystore, requiring user authentication. This allows developers to specify messages with sensitive content, that remain encrypted in cached form until the user has unlocked and decrypted their device.

The library handles:

Crypto functionality and key management across all versions of Android back to KitKat (API level 19).
Key generation and registration workflows.
Message encryption (on the server) and decryption (on the client).
Integrity protection to prevent message modification.
Caching of messages received in unauthenticated contexts to be decrypted and displayed upon device unlock.
Edge-cases, such as users adding/resetting device lock after installing the app, users resetting app storage, etc.

The library supports both RSA encryption with ECDSA authentication and Web Push encryption, allowing developers to re-use existing server-side code developed for sending E2E-encrypted Web Push messages to browser-based clients.

Along with the library, we are also publishing a demo app (at last, the Google privacy team has its own messaging app!) that uses the library to send E2E-encrypted FCM payloads from a gRPC-based server implementation.

What it's not

The open source library and demo app are not designed to support peer-to-peer messaging and key exchange. They are designed for developers to send E2E-encrypted push messages from a server to one or more devices. You can protect messages between the developer's server and the destination device, but not directly between devices.
It is not a comprehensive server-side solution. While core crypto functionality is provided, developers will need to adapt parts of the sample server-side code that are specific to their architecture (for example, message composition, database storage for public keys, etc.)

You can find more technical details describing how we've architected and implemented the library and demo here.

All the (Android) Things at Google I/O

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!

Keeping 2 billion Android devices safe with machine learning

Posted by Sai Deep Tetali, Software Engineer, Google Play Protect

At Google I/O 2017, we introduced Google Play Protect, our comprehensive set of security services for Android. While the name is new, the smarts powering Play Protect have protected Android users for years.

Google Play Protect's suite of mobile threat protections are built into more than 2 billion Android devices, automatically taking action in the background. We're constantly updating these protections so you don't have to think about security: it just happens. Our protections have been made even smarter by adding machine learning elements to Google Play Protect.

Security at scale

Google Play Protect provides in-the-moment protection from potentially harmful apps (PHAs), but Google's protections start earlier.

Before they're published in Google Play, all apps are rigorously analyzed by our security systems and Android security experts. Thanks to this process, Android devices that only download apps from Google Play are 9 times less likely to get a PHA than devices that download apps from other sources.

After you install an app, Google Play Protect continues its quest to keep your device safe by regularly scanning your device to make sure all apps are behaving properly. If it finds an app that is misbehaving, Google Play Protect either notifies you, or simply removes the harmful app to keep your device safe.

Our systems scan over 50 billion apps every day. To keep on the cutting edge of security, we look for new risks in a variety of ways, such as identifying specific code paths that signify bad behavior, investigating behavior patterns to correlate bad apps, and reviewing possible PHAs with our security experts.

In 2016, we added machine learning as a new detection mechanism and it soon became a critical part of our systems and tools.

Training our machines

In the most basic terms, machine learning means training a computer algorithm to recognize a behavior. To train the algorithm, we give it hundreds of thousands of examples of that behavior.

In the case of Google Play Protect, we are developing algorithms that learn which apps are "potentially harmful" and which are "safe." To learn about PHAs, the machine learning algorithms analyze our entire catalog of applications. Then our algorithms look at hundreds of signals combined with anonymized data to compare app behavior across the Android ecosystem to find PHAs. They look for behavior common to PHAs, such as apps that attempt to interact with other apps on the device, access or share your personal data, download something without your knowledge, connect to phishing websites, or bypass built-in security features.

When we find apps exhibit similar malicious behavior, we group them into families. Visualizing these PHA families helps us uncover apps that share similarities to known bad apps, but have yet remained under our radar.

After we identify a new PHA, we confirm our findings with expert security reviews. If the app in question is a PHA, Google Play Protect takes action on the app and then we feed information about that PHA back into our algorithms to help find more PHAs.

Doubling down on security

So far, our machine learning systems have successfully detected 60.3% of the malware identified by Google Play Protect in 2017.

In 2018, we're devoting a massive amount of computing power and talent to create, maintain and improve these machine learning algorithms. We're constantly leveraging artificial intelligence and our highly skilled researchers and engineers from all across Google to find new ways to keep Android devices safe and secure. In addition to our talented team, we work with the foremost security experts and researchers from around the world. These researchers contribute even more data and insights to keep Google Play Protect on the cutting edge of mobile security.

To check out Google Play Protect, open the Google Play app and tap Play Protect in the left panel.

Acknowledgements: This work was developed in joint collaboration with Google Play Protect, Safe Browsing and Play Abuse teams with contributions from Andrew Ahn, Hrishikesh Aradhye, Daniel Bali, Hongji Bao, Yajie Hu, Arthur Kaiser, Elena Kovakina, Salvador Mandujano, Melinda Miller, Rahul Mishra, Damien Octeau, Sebastian Porst, Chuangang Ren, Monirul Sharif, Sri Somanchi, Sai Deep Tetali, Zhikun Wang, and Mo Yu.

Faster Adoption with 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).

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.

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.

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.

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.

Wear OS by Google: AoG support and new enhanced battery saver mode

Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

At Google I/O, we launched the Wear OS by Google developer preview 2. This update added support for Actions on Google (AoG) and more power-related enhancements including a new battery saver mode.

This developer preview includes updated Android Emulator images and a downloadable system image for the Huawei Watch 2 Bluetooth or Huawei Watch 2 Classic Bluetooth. This preview release is intended for developers only and not for daily or consumer use. Therefore, the preview release is only available via manual download and flash. Please refer to the release notes for known issues before downloading and flashing your device.

Support for Actions on Google

We have revamped the Google Assistant on Wear OS to support features such as visual cards, follow-on suggestion chips, and text-to-speech. For developers, we added support for Actions on Google to Wear OS and existing Actions will work on Wear OS out of the box. Be sure to observe best practices for Actions on Google to get the best results such as short concise dialog and adopting to both visual and vocal feedback. This feature does not depend on Android P and is being rolled out to all Wear 2.0 users.

Enhanced battery saver mode

In this Android P developer preview, we are launching an enhanced battery saver mode. While the watch is in this mode, the watch shows a power-efficient watch face and turns off a set of services including radios, the touch screen, and tilt to wake. Users can get the time by pressing the side button. A long press allows the user to switch back to a fully-operational mode and perform tasks such as paying with NFC or replying to a message. Developers should assume that their apps, watch faces, and complication data providers are not available in enhanced battery saver mode.

Update on power saving features

We received much feedback on the power saving features in the last developer preview. As a result, we have updates on two features:

Roll back of Wi-Fi off when BT is disconnected: To improve power consumption, the last developer preview would not connect to Wi-Fi when disconnected from Bluetooth. After listening carefully to user and developer feedback, we decided to roll back this change.
Limited background activity and foreground service: A number of health and fitness developers have said their apps require background monitoring of the user's motion and other vitals throughout the day. The developers said their apps cannot perform background monitoring if background services are unable to set alarms and jobs. For these types of exceptional use cases, we recommend that the apps use foreground services to anchor alarms and jobs. For other use-cases, developer should look at both foreground service as well as limiting jobs and alarms to while the watch is on charger. We are still fine tuning this feature, your feedback and use-cases will be most helpful in helping us get this right.

Smart Reply for bridged notifications

Smart Reply has been enabled for bridged notifications from the user's smartphone for some time. With the latest developer preview, we are introducing simplified Chinese support for our users in China. This feature is powered by an on-device model using TensorFlow Lite and the model is optimized for low-memory, low-power devices.

To use this feature, developers should set setAllowGeneratedReplies of the reply action to true. Here's a sample code snippet with the important part highlighted in bold:

NotificationCompat.Action action =
    new NotificationCompat.Action.Builder(R.drawable.ic_reply_white_24dp,
        replyLabel, replyPendingIntent)
        .addRemoteInput(remoteInput)
        .setAllowGeneratedReplies(true) // <--- true to enable smart replies
        // Wear OS requires a hint to display the reply action inline.
        .extend(new NotificationCompat.Action.WearableExtender()
            .setHintDisplayActionInline(true))
        .build();

In addition, for messaging apps, we recommend that developers use MessagingStyle notifications. This can give the algorithm a more structured data set on which to base its recommendations.

Please give us your feedback

Google I/O 2018: What’s new in Android

Posted By Stephanie Cuthbertson, Product Management Director, Android

As Android has grown exponentially over the past ten years, we've also seen our developer community grow dramatically. In countries like China, India, and Brazil, the number of developers using our IDE almost tripled - in just two years. With such growth, we feel an even greater responsibility to invest in our developer experience. Guided by your feedback, we've focused our efforts on making mobile development fast and easy, helping you get more users by making apps radically smaller, and increasing engagement to keep users coming back. We're also pretty excited to see Android Things go to 1.0, creating new opportunities for you to develop - everything from major consumer devices, to cool remote control vehicles! As Day 1 of Google I/O kicks off, let's take a closer look at these major themes from the Developer Keynote:

Development: making mobile development fast and easy

Android Jetpack — Today, we announced Android Jetpack, designed to accelerate your app development. Android Jetpack is the next generation of Android components, bringing together the benefits of the Support Library -- backwards compatibility and immediate updates -- to a larger set of components, making it quick and easy to build robust, high quality apps. Android Jetpack manages activities like background tasks, navigation, and lifecycle management, so you can eliminate boilerplate code and focus on what makes your app great. Android Jetpack is designed to work well with Kotlin, saving you even more code with Android KTX. The new Android Jetpack components released today include WorkManager, Paging, Navigation, and Slices.

Kotlin — Since announcing support for Kotlin last year, the developer community has embraced the language. Most importantly, 95% of developers tell us they are very happy with using Kotlin for their Android development. And, the more developers use it, the more that number rises. The number of Play Store apps using Kotlin grew 6x in the last year. 35% of pro developers use it, and that number is growing each month. We are continuing to improve the Kotlin developer experience across our libraries, tooling, runtime, documentation and training. Android KTX is launching today as part of Android Jetpack to optimize the Kotlin developer experience. Tooling continues to improve with Android Studio, Lint support, and R8 optimizations. We have even tuned the Android Runtime (ART) in Android P, so that apps built with Kotlin can run faster. We have rolled out Kotlin code snippets in our official documentation, and are publishing a Kotlin version of the API reference documentation today. Earlier this week, we launched a new Kotlin Bootcamp on Udacity, which is a great resource for developers who are new to Kotlin. Lastly, we now have a Kotlin specialization in the Google Developers Experts Program. If you still haven't used Kotlin, I hope you you give it a try.
Android Studio 3.2 Canary — Android Studio 3.2 features tools for Android Jetpack including a visual Navigation Editor and new code refactoring tools. The canary release also includes build tools to create the new Android App Bundle format, Snapshots in the Android Emulator for fast start time, new R8 optimizer for smaller download and install app code size, a new Energy Profiler to measure app impact on battery life, and more. You can download the latest version of Android Studio 3.2 from the canary channel download page.

Distribution: making apps radically smaller

Android App Bundle & Google Play Dynamic Delivery — Introducing the new app model for Android. Dramatically reduce app size with a new publishing format—the Android App Bundle. In Android Studio, you'll now build an app bundle that contains everything your app needs for any device—all the languages, every device screen size, every hardware architecture. Then, when a user downloads your app, Google Play's new Dynamic Delivery will only deliver the code and resources matching the user's device. People see a smaller install size on the Play Store, can download your app more quickly, and save space on their devices.
(Left) An example of all resources being delivered to a device via a legacy APK.
(Right) An example of Dynamic Delivery serving just what’s needed to a device.
Dynamic features via the Android App Bundle — The Android App Bundle also enables modularization so that you can deliver features on-demand, instead of during install. You can build dynamic feature modules in the latest Android Studio canary release. Join our beta program to publish them on Google Play.
Google Play Console — New features and reports in the Play Console will help you improve your app's performance and grow your business. Read about the improvements to the dashboard, statistics, Android vitals, pre-launch report, acquisition report, and subscriptions dashboard. You can also upload, test, and publish apps using our new publishing format, the Android App Bundle.
Google Play Instant — After launching in beta at GDC, today we announced that all game developers can build instant apps and we're thrilled to welcome Candy Crush Saga. Google Play Instant is now available on over 1 billion devices worldwide from the Play Store, search, social and most places you can tap a link. To make instant apps easier to build, we are launching a Unity plugin and beta integration with Cocos creator this week. Recently, we've started testing Google Play Instant compatibility with AdWords, allowing people to try out games directly from ads, across all the channels reached by Universal App campaigns.

Engagement: bringing users back more and more.

Slices — Slices are UI templates that display a rich array of dynamic, and interactive content from your app, across Android and within Google surfaces. Slices can include live-data, scrolling content, inline actions, and deep-linking into your app so users can do everything from playing music to checking reservation updates. Slices can also contain interactive controls like toggles and sliders. You can get started building Slices today, and they will begin appearing for users soon.

Actions — Actions are a new way to make your app's capabilities and content more accessible, so that people can easily get to it at the right moment. App Actions will appear to users based on usage and relevance, across multiple Google and Android surfaces, such as the Google Search App, the Play Store, the Google Assistant, and the Launcher. App Actions will be available for all developers to try soon, please sign up here if you'd like to be notified. You can also choose to build a Conversational Action as a companion experience to your app. This works on a variety of Assistant-enabled devices, such as speakers and smart displays. Both types of Actions use a new common catalog of intents.

Actions are a new way to make your app's capabilities and content more accessible, so that people can easily get to it at the right moment.

Smarter devices: a powerful platform for IoT devices

Android Things 1.0 — Android Things is Google's managed OS that enables developers to build and maintain Internet of Things devices at scale. Earlier this year at CES, we announced Lenovo, Harman, LG, and iHome are all building Assistant-enabled products powered by Android Things. After a developer preview with over 100,000 SDK downloads and feedback from more than 10,000 developers, we announced Android Things 1.0 this week. Four new System-on-Modules (SoMs) are now supported on the platform with guaranteed long-term support for three years and additional options for extended support, making it easier to go from prototypes to production. To make product development more seamless than ever, the accompanying Android Things Console is also ready for production. It helps developers easily manage and update their devices with the latest stability fixes and security updates provided by Google.

To get started with Android Things, visit our developer site and the new Community Hub to explore kits, sample code, community projects, and join Google's IoT Developers Community to stay updated. We introduced a limited program to partner with the Android Things team for technical guidance and support building your product. If your company is interested, sign up for our OEM Partner Program.
In addition to all these new developments, we're on the ground in over 140 countries, growing and expanding the developer community through programs such as Women Techmakers and Google Developer Groups (GDGs). We're investing in training programs like Google Developers Certification, building more courses through Udacity and other partners, to help developers deepen their technical capability. Today, 225 Google Developers Agency Program members from 50 agencies in 15 countries, are Android Certified. As part of our Google Developers Experts Program, we also now have more than 90 Android Developer Experts around the world actively supporting developers, start-ups and companies to build and launch innovative apps.
We also continue to recognize the great work from top app and game developers. This year, we held our third annual Google Play Awards. The nominees represent some of the best experiences available on Android, with an emphasis on overall quality, strong design, technical performance, and innovation. Check out the winners and nominees.
During Google I/O, attendees and viewers have an opportunity to dive deep with 48 Android & Play breakout sessions. Thank you for all your wonderful feedback, and please keep giving us your advice on where we should go next.

Use Android Jetpack to Accelerate Your App Development

Posted by Chris Sells, Benjamin Poiesz, Karen Ng, Product Management, Android Developer Tools

Today we're excited to introduce Android Jetpack, the next generation of components, tools and architectural guidance to accelerate your Android app development.

Android Jetpack was inspired by the Support Library, a set of components to make it easy to take advantage of new Android features while maintaining backwards compatibility; it's currently used by 99% of every app in the Play Store. Following on that success, we introduced the Architecture Components, designed to make it easier to deal with data in the face of changes and the complications of the app lifecycle. Since we introduced those components at I/O just one year ago, an overwhelming number of you have adopted them. Companies such as LinkedIn, Zillow and iHeartRadio are seeing fewer bugs, higher testability and more time to focus on what makes their app unique.

The Android developer community has been clear -- not only do you like what we've done with these existing components, but we know that you want more! And so more is what you get.

What is Android Jetpack?

Android Jetpack is a set of components, tools and guidance to make great Android apps. The Android Jetpack components bring together the existing Support Library and Architecture Components and arranges them into four categories:

Android Jetpack components are provided as "unbundled" libraries that are not part of the underlying Android platform. This means that you can adopt each component at your own speed, at your own time. When new Android Jetpack functionality is available, you can add it to your app, deploy your app to the Play Store and give users the new features all in a single day (if you're quick)! The unbundled Android Jetpack libraries have all been moved into the new androidx.* namespace (as described in detail in this post).

In addition, your app can run on various versions of the platform because Android Jetpack components are built to provide their functionality independent of any specific version, providing backwards compatibility.

Further, Android Jetpack is built around modern design practices like separation of concerns and testability as well as productivity features like Kotlin integration. This makes it far easier for you to build robust, high quality apps with less code. While the components of Android Jetpack are built to work together, e.g. lifecycle awareness and live data, you don't have to use all of them -- you can integrate the parts of Android Jetpack that solve your problems while keeping the parts of your app that are already working great.

We know that these benefits are important to you because of feedback like this:

"We had been thinking of trying out MVVM in our code base. Android Architecture Components gave us an easy template to implement it. And it's helped make our code more testable as well; the ability to unit test ViewModels has definitely increased code robustness."

-- Sumiran Pradhan, Sr. Engineer, Zillow

If you want to learn more about how companies are using Android Jetpack components, you can read the developer stories on the Android Developer site.

And finally, as you can see from the Android Jetpack diagram above, today we're announcing new components as well.

What's New

Android Jetpack comes with five new components:

WorkManager alpha release
Navigation alpha release
Paging stable release
Slices alpha release
Android KTX (Kotlin Extensions) alpha release

WorkManager

The WorkMananager component is a powerful new library that provides a one-stop solution for constraint-based background jobs that need guaranteed execution, replacing the need to use things like jobs or SyncAdapters. WorkManager provides a simplified, modern API, the ability to work on devices with or without Google Play Services, the ability to create graphs of work, and the ability to query the state of your work. Early feedback is very encouraging but we love to make sure that your use cases are covered, too. You can see what we have so far and provide feedback on our alpha on the WorkManager component.

Navigation

While activities are the system provided entry points into your app's UI, their inflexibility when it comes to sharing data between each other and transitions has made them a less than ideal architecture for constructing your in-app navigation. Today we are introducing the Navigation component as a framework for structuring your in-app UI, with a focus on making a single-Activity app the preferred architecture. With out of the box support for Fragments, you get all of the Architecture Components benefits such as Lifecycle and ViewModel while allowing Navigation to handle the complexity of FragmentTransactions for you. Further, the Navigation component allows you to declare transitions that we handle for you, automatically builds the correct Up and Back behavior, includes full support for deep links, and provides helpers for connecting Navigation into the appropriate UI widgets, like the navigation drawer and bottom navigation. But that's not all! The Navigation Editor in Android Studio 3.2 allows you to see and manage your navigation properties visually:

The Navigation component is also in alpha and we'd love your feedback.

Paging

Data presented in an app can be large and costly to load, so it's important to avoid downloading, creating, or presenting too much at once. The Paging component version 1.0.0 makes it easy to load and present large data sets with fast, infinite scrolling in your RecyclerView. It can load paged data from local storage, the network, or both, and lets you define how your content gets loaded. It works out of the box with Room, LiveData, and RxJava.

Slices

And finally, to round out the set of new features making their debut in Android Jetpack is the Slices component. A "slice" is a way to surface your app's UI inside of the Google Assistant as a result of a search:

You can learn all about the Slices component and how to integrate it into your app on the Android Developer website.

Android KTX

And last but not least, one goal of Android Jetpack takes advantage of Kotlin language features that make you more productive. Android KTX lets you transform Kotlin code like this:

view.viewTreeObserver.addOnPreDrawListener(
  object : ViewTreeObserver.OnPreDrawListener {
    override fun onPreDraw(): Boolean {
      viewTreeObserver.removeOnPreDrawListener(this)
      actionToBeTriggered()
      return true
    }
});

into more concise Kotlin code like the following:

view.doOnPreDraw { actionToBeTriggered() }

This is just the first step in bringing Kotlin support to Android Jetpack components; our goal is to make Android Jetpack great for Kotlin developers (and of course Java developers!).You can read more about Android KTX on the Android Developer web site.

Getting Started

You can get started with Android Jetpack at developer.android.com/jetpack. You'll find docs and videos for Android Jetpack, see what's new in Android Jetpack components, participate in the community and give us feedback. We've also created a YouTube playlist devoted to Android Jetpack, so you can tune in for information about Android Jetpack, components, tools and best practices.

Getting Started with Android Jetpack will tell you how to bring the Android Jetpack components into your existing apps and help you get started with new Android Jetpack apps. Android Studio 3.2 has great tooling support for Android Jetpack. For building new apps, use the Activity & Fragment+ViewData activity, which you can get to from File | New | New Project in Android Studio:

What's Next

With Android Jetpack, we're taking the benefits of the Support Library and the Architecture Components and turning it up a notch with new components, Android Studio integration and Kotlin support. And while Android Jetpack provides the next generation components, tools and guidance to accelerate your Android development, we've got a lot more that we want to do and we want your help. Please go to developer.android.com/jetpack and let us know what we can do to make your experience building Android apps even better.

What’s new in Android P Beta

Posted By Dave Burke, VP of Engineering

Earlier today we unveiled a beta version of Android P, the next release of Android. Android P puts AI at the core of the operating system and focuses on intelligent and simple experiences. You can read more about the new user features here.

For developers, Android P beta offers a range of ways to take advantage of these new smarts, especially when it comes to increasing engagement with your apps.

You can get Android P beta on Pixel devices by enrolling here. And thanks to Project Treble, you can now get the beta on top devices from our partners as well -- Essential, Nokia, Oppo, Sony, Vivo, and Xiaomi, with others on the way.

Visit android.com/beta for the full list of devices, and details on how to get Android P beta on your device. To get started developing with Android P beta, visit developer.android.com/preview.

A smarter smartphone, with machine learning at the core

Android P makes a smartphone smarter, helping it learn from and adapt to the user. Your apps can take advantage of the latest in machine intelligence to help you reach more users and offer new kinds of experiences.

Adaptive Battery

Battery is the number one priority we hear from mobile phone users, regardless of the device they are using. In Android P we've partnered with DeepMind on a new feature we call Adaptive Battery that optimizes how apps use battery.

Adaptive Battery uses machine learning to prioritize access to system resources for the apps the user cares about most. It puts running apps into groups with different restrictions using four new "App Standby buckets" ranging from "active" to "rare". Apps will change buckets over time, and apps not in the "active" bucket will have restrictions in: jobs, alarms, network and high-priority Firebase Cloud Messages.

If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. We recommend testing your app in each of the four buckets. Check out the documentation for the details.

App Actions

App Actions are a new way to raise the visibility of your app to users as they start their tasks. They put your app's core capabilities in front of users as suggestions to handle their tasks, from key touch-points across the system like the Launcher and Smart Text Selection, Google Play, Google Search app, and the Assistant.

Actions use machine learning to surface just the right apps to users based on their context or recent interactions. Because Actions highlight your app where and when it's most relevant, they're a great way to reach new users and re-engage with existing users.

To support App Actions, just define your app's capabilities as semantic intents. App Actions use the same catalog of common intents as conversational Actions for the Google Assistant, which surface on voice-activated speakers, Smart displays, cars, TVs, headphones, and more. There's no API surface needed for App Actions, so they will work on any supported Android platform version.

Actions will be available soon for developers to try, sign up here if you'd like to be notified.

Slices

Along with App Actions we're introducing Slices, a new way for your apps to provide remote content to users. With Slices you can surface rich, templated UI in places like Google Search and Assistant. Slices are interactive with support for actions, toggles, sliders, scrolling content, and more.

Slices are a great new way to engage users and we wanted them to be available as broadly as possible. We added platform support in Android P, and we built the developer APIs and templates into Android Jetpack, our new set of libraries and tools for building great apps. Through Jetpack, your Slices implementation can target users all the way back to Kitkat -- across 95% of active Android devices. We'll also be able to update the templates regularly to support new use cases and interactions (such as text input).

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.

Smart reply in notifications

The Smart Reply feature in Gmail and Inbox are excellent examples of how machine intelligence can positively transform an app experience. In Android P we've brought Smart Replies to Notifications with an API to let you provide this optimization to your users. To make it easier to populate replies in your notifications, you'll soon be able to use ML Kit -- see developers.google.com/mlkit for details.

Text Classifier

In Android P we've extended the ML models that identify entities in content or text input to support more types like Dates and Flight Numbers and we're making those improvements available to developers through the TextClassifier API. We're also updating the Linkify API that automatically creates links to take advantage of these TextClassification models and have enriched the options the user has for quick follow on actions. Developers will have additional options of linkifying any of the entities recognized by the TextClassifier service. Smart Linkify has significant improvements in accuracy and precision of detection and performance.

Even better, the models are now updated directly from Google Play, so your apps can take advantage of model improvements using the same APIs. Once the updated models are installed, all of the entity recognition happens on-device and data is not sent over the network.

Simplicity

We put a special emphasis on simplicity in Android P, evolving Android's UI to streamline and enhance user tasks. For developers, the changes help improve the way users find, use, and manage your apps.

New system navigation

We're introducing a new system navigation in Android P that gives users easier access to Home, Overview, and the Assistant from a single button on every screen. The new navigation simplifies multitasking and makes discovering related apps much easier. In the Overview, users have a much larger view of what they were doing when they left each app, making it much easier to see and resume the activity. The Overview also provides access to search, predicted apps, and App Actions, and takes users to All Apps with another swipe.

Text Magnifier

In Android P we've also added a new Magnifier widget, designed to make it easier to select text and manipulate the text cursor in text. By default, classes that extend TextView automatically support the magnifier, but you can use the Magnifier API to attach it to any custom View, which opens it up to a variety of uses.

Background restrictions

We're making it simple for users to identify and manage apps that are using battery in the background. From our work on Android Vitals, Android can detect battery-draining app behaviors such as excessive wake locks and others. Now in Android P, Battery Settings lists such apps and lets users restrict their background activities with a single tap.

When an app is restricted, its background jobs, alarms, services, and network access are affected. To stay off of the list, pay attention to your Android Vitals dashboard in the Play Console, which can help you understand performance and battery issues.

Background Restrictions ensures baseline behaviors that developers can build for across devices and manufacturers. Although device makers can add restrictions on top of the core set, they must provide user controls via Battery Settings.

We've added a standard API to let apps check whether they are restricted, as well as new ADB commands to let you manually apply restrictions to your apps for testing. See the documentation for details. We also plan to add restrictions related metrics to your Play Console Android Vitals dashboard in the future.

Enhanced audio with Dynamics Processing

Android P introduces a new Dynamics Processing Effect in the Audio Framework that lets developers improve audio quality. With Dynamics Processing, you can isolate specific frequencies and lower loud or increase soft sounds to enhance the acoustic quality of your application. For example, your app can improve the sound of someone who speaks quietly in a loud, distant or otherwise acoustically challenging environment.

The Dynamics Processing API gives you access to a multi-stage, multi-band dynamics processing effect that includes a pre-equalizer, a multi-band compressor, a post-equalizer and a linked limiter. It lets you modify the audio coming out of Android devices and optimize it according to the preferences of the listener or the ambient conditions. The number of bands and active stages is fully configurable, and most parameters can be controlled in realtime, such as gains, attack/release times, thresholds, etc.

To see what you can do with the Dynamics Processing Effect, please see the documentation.

Security

Biometric prompt

Android P provides a standard authentication experience across the growing range of biometric sensors. Apps can use the new BiometricPrompt API instead of displaying their own biometric auth dialogs. This new API replaces the FingerprintDialog API added in DP1. In addition to supporting Fingerprints (including in-display sensors), it also supports Face and Iris authentication, providing a system-wide consistent experience. There is a single USE_BIOMETRIC permission that covers all device-supported biometrics. FingerprintManager and the corresponding USE_FINGERPRINT permission are now deprecated, so please switch to BiometricPrompt as soon as possible.

Protected Confirmation

Android P introduces Android Protected Confirmation, which use the Trusted Execution Environment (TEE) to guarantee that a given prompt string is shown and confirmed by the user. Only after successful user confirmation will the TEE then sign the prompt string, which the app can verify.

Stronger protection for private keys

We've added StrongBox as a new KeyStore type, providing API support for devices that provide key storage in tamper-resistant hardware with isolated CPU, RAM, and secure flash. You can set whether your keys should be protected by a StrongBox security chip in your KeyGenParameterSpec.

Android P Beta

Bringing a new version of Android to users takes a combined effort across Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. The process is technically challenging and can take time -- to make it easier, we launched Project Treble last year as part of Android Oreo. Since then we've been working with partners on the initial bring-up and now we're seeing proof of what Treble can do.

Today we announced that 6 of our top partners are joining us to release Android P Beta on their devices -- Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21UD and X21, and Essential PH‑1. We're inviting early adopters and developers around the world to try Android P Beta on any of these devices -- as well as on Pixel 2, Pixel 2 XL, Pixel, and Pixel XL.

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. For Pixel devices, you can now enroll your device in the Android Beta program and automatically receive the latest Android P Beta over-the-air.

Try Android P Beta on your favorite device today and let us know your feedback! Check out our post on Faster Adoption with Project Treble for more details.

Make your apps compatible

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

To test for compatibility, just install your current app from Google Play onto a device or emulator running Android P Beta and work through the user flows. The app should run and look great, and handle the Android P behavior changes properly. In particular, pay attention to adaptive battery, Wi-Fi permissions changes, restrictions on use of camera and sensors from the background, stricter SELinux policy for app data, and changes in TLS enabled by default, and Build.SERIAL restriction.

Compatibility through public APIs

It's important to test your apps for uses of non-SDK interfaces. As noted previously, in Android P we're starting a gradual process to restrict access to selected non-SDK interfaces, asking developers -- including app teams inside Google -- to use the public equivalents instead.

If your apps are using private Android interfaces and libraries, you should move to using public APIs from the Android SDK or NDK. The first developer preview displayed a toast warning for uses of non-SDK interfaces -- starting in Android P Beta, uses of non-SDK interfaces that are not exempted will generate errors in your apps -- so you'll now get exceptions thrown instead of a warning.

To help you identify reflective usage of non-SDK APIs, we've added two new methods in StrictMode. You can use detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI, and you can use permitNonSdkApiUsage() to suppress StrictMode warnings for those accesses. This can help you understand your app's use of non-SDK APIs -- even if the APIs are exempted at this time, it's best to plan for the future and eliminate their use.

In cases where there is no public API that meets your use-case, please let us know immediately. We want to make sure that the initial rollout only affects interfaces where developers can easily migrate to public alternatives. More about the restrictions is here.

Test with display cutout

It's also important to test your app with display cutout. Now you can use several of our partner devices running Android Beta to make sure your app looks its best with a display cutout. You can also use the emulated cutout support that's available on any Android P device through Developer options.

Get started with Android P

When you're ready, dive into Android P and learn about the many new features and APIs you can take advantage of in your apps. To make it easier to explore the new APIs, take a look at the API diff reports (API 27->DP2, DP1->DP2) along with the Android P API reference. Visit the Developer Preview site for details. Also check out this video highlighting what's new for developers in Android P Beta.

To get started with Android P, download the P Developer Preview SDK and tools into Android Studio 3.1 or use the latest version of Android Studio 3.2. If you don't have a device that runs Android P Beta, you can use the Android emulator to run and test your app.

As always, your feedback is critical, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.

Hello World, AndroidX

Posted by Alan Viverette (/u/alanviverette), Kathy Kam (@kathykam) , Lukas Bergstrom (@lukasb)

Today, we launch an early preview of the new Android extension libraries (AndroidX) which represents a new era for the Support Library. Please preview the change and give us your feedback. Since this is an early preview, we do not recommend trying this on any production projects as there are some known issues.

The Support Library started over 7+ years ago to provide backwards compatibility to framework APIs. Over the years, the library has grown to include device-specific UX, debugging, testing and other utilities. The adoption of the Support Library has been phenomenal; most Android apps use the Support Library today. We want to increase our investment in this area, and it is critical that we lay a solid foundation.

In that vein, we took a step back and chatted with many of you. The feedback has been consistent and unanimous; the organic growth of the library has become confusing. There are components and packages named "v7" when the minimal SDK level we support is 14! We want to make it clear for you to understand the division between APIs that are bundled with the platform and which are static libraries for app developers that work across different versions of Android.

With that in mind, say "Hello World" to "AndroidX". As previously noted in the Android KTX announcement, we are adding new features under this package, and updating some existing ones.

android.* vs androidx.* namespaces

Writing Android apps means depending on two kinds of classes:

Classes like PackageManager, which are bundled with the operating system and can have different APIs and behavior for different Android versions
Classes like AppCompatActivity or ViewModel, which are unbundled from the operating system and ship in your apk. These libraries are written to provide a single API surface with behavior that's as consistent as possible across Android versions.

Many times, unbundled libraries can be a better choice, since they provide a single API surface across different Android versions. This refactor moves the unbundled libraries - including all of the Support Library and Architecture Components - into the AndroidX package, to make it clear to know which dependencies to include.

Revised naming for packages and Maven artifacts

We redesigned the package structure to encourage smaller, more focused libraries that relieve pressure on apps and tests that aren't using Proguard or Multidex. Maven groupIds and artifactIds have been updated to better reflect library contents, and we have moved to prefixing library packages with their groupId to create an obvious link between the class that you are using and the Maven artifact from which it came.

Generally, you can expect the following mapping from old to new packages:

Old	New
`android.support.**`	`androidx.@`
`android.databinding.**`	`androidx.databinding.@`
`android.design.**`	`com.google.android.material.@`
`android.support.test.**`	(in a future release) `androidx.test.@`

The Architecture Components libraries have also been moved under androidx and their package names simplified to reflect their integration with core libraries. A sample of changes to these libraries:

Old	New
`android.arch.**`	`androidx.@`
`android.arch.persistence.room.**`	`androidx.room.@`
`android.arch.persistence.**`	`androidx.sqlite.@`

Additionally, following the introduction in 28.0.0-alpha1 of Material Components for Android as a drop-in replacement for Design Library, we have refactored the design package to reflect its new direction.

For a complete listing of mappings from 28.0.0-alpha1 (android.support) to 1.0.0-alpha1 (androidx), please see the full AndroidX refactoring map. Please note that there may be minor changes to this map during the alpha phase.

Per-artifact strict semantic versioning

Starting with the AndroidX refactor, library versions have been reset from 28.0.0 to 1.0.0. Future updates will be versioned on a per-library basis, following strict semantic versioning rules where the major version indicates binary compatibility. This means, for example, that a feature may be added to RecyclerView and used in your app without requiring an update to every other library used by your app. This also means that libraries depending on androidx may provide reasonable guarantees about binary compatibility with future releases of AndroidX -- that a dependency on a 1.5.0 revision will still work when run against 1.7.0 but will likely not work against 2.0.0.

Migration from 28.0.0-alpha1

Moving your app from android.support to androidx-packaged dependencies has two major parts: source refactoring and dependency translation.

Source refactoring updates your Java code, XML resources, and Gradle configuration to reference the refactored classes and Maven artifacts. This feature is available in Android Studio Canary 14 for applications targeting Android P.

If you depend on a library that references the older Support Library, Android Studio will update that library to reference androidx instead via dependency translation. Dependency translation is automatically applied by the Android Gradle Plugin 3.2.0-alpha14, which rewrites bytecode and resources of JAR and AAR dependencies (and transitive dependencies) to reference the new androidx-packaged classes and artifacts. We will also provide a standalone translation tool as a JAR.

What's next?

We understand this is a big change for existing projects and codebases. Our intention is to provide a strong foundation that sets Android library projects up for more sustainable growth, better modularity, and smaller code size.

We hope that these changes also make it easier for developers to discover features and implement high-quality apps in less time; however, we understand that migration takes time and may not fit into everyone's production schedule. For this reason, we will continue to provide parallel updates to an android.support-packaged set of libraries for the duration of the P preview SDK timeframe. These updates will continue the 28.0.0 versioning scheme that began with 28.0.0-alpha1 in March 2018, and they will continue to be source-compatible with existing projects that depend on the android.support package.

The stable release of 28.0.0 will be the final feature release packaged as android.support. All subsequent feature releases will only be made available as androidx-packaged artifacts.

We'd love to hear from you as we iterate on this exciting future. Send us feedback by posting comments below, and please file any bugs you run into on AOSP.

We look forward to a new era of Android libraries!

Building for Automotive: A sneak peek at Google I/O 2018

Posted by John Posavatz, Product Manager, Android Auto

Since 2015, Android developers have been building and growing great apps for cars. Drivers are benefiting from thoughtfully designed apps that provide safe and seamless connected experiences, whether they drive one of many Android Auto compatible cars or use the Android Auto app on their phones.

Today, thousands of apps for Android Auto are available through the Google Play Store for millions of drivers in over 30 countries around the world. And because the Google Assistant is available on Android Auto, developers are able to build voice-powered experiences on their apps that let drivers get things done while keeping their eyes on the road.

But it doesn't end there -- great driving apps will soon reach beyond Android Auto users. Last year, carmakers Volvo Cars and Audi announced the development of new connected cars powered by Android. As an important next step, we are now working with Volvo Cars to bring the Play Store and the Google Assistant directly into their next-generation cars, along with Google Maps. The opportunities for developers are endless -- their apps are able to reach millions of Android Auto users today, and drivers of Android-powered cars in the future.

This week at Google I/O, we are sharing some updates that help developers build an even better in-car experience and become a part of the evolving ecosystem. We will be demonstrating those changes in our Sandbox by collaborating with several app developers, including iHeartRadio, Pandora, Pocket Casts, Spotify, Telegram, WhatsApp as well as Google's own apps (including Android Messages, Play Books and Play Music).

New visual templates

First, a fresh new design enables media apps to make their content more accessible through new visual templates. For example, browsable content is placed front and center as soon as you open up an app, enabling you to easily recognize and quickly start listening to songs and podcasts.

Media search enhancements

Second, new search capabilities allow media apps to directly integrate their results into Android Auto. This allows drivers to quickly discover tracks that are related to what they're currently listening to, such as a song's live version, or a song with the same name from a different artist.

Group messaging and RCS

Finally, we now support group messaging and RCS. Using the Google Assistant, you can easily communicate with a group of friends while keeping your hands on the wheel.

If you're attending I/O, come check out the Automotive session at Google I/O on May 9 at 9:30am PST. We will also be displaying three cars in the Sandbox area that showcase different integrations in real life, including a preview of Volvo's future infotainment system displayed in the current XC40. If you're not at I/O, you can still catch the livestream of the session. Developers can also sign up to learn more about the media and messaging updates as we release more information.