Author Archives: Android Developers

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.

Announcing new SDK versioning in Google Play services and Firebase

Posted by Doug Stevenson, Developer Advocate

Starting today, the Android SDKs for Google Play services and Firebase will be using a new build and versioning scheme. This may require some changes to the way you build your Android app, so be sure to read here thoroughly to get all the details.

Here's a quick summary of what's new in these SDKs:

  • All dependencies now use semantic versioning.
  • Each dependency may be updated individually, removing the need to upgrade them all simultaneously in your app.
  • Each dependency has a faster cycle for bug fixes and new features.

Beginning with version 15 of all Play services and Firebase libraries, version numbers adhere to the semantic versioning scheme. As you know, semver is an industry standard for versioning software components, so you can expect that version number changes for each library indicate the amount of change in the library.

Each Maven dependency matching com.google.android.gms:play-services-* and com.google.firebase:firebase-* is no longer required to have the same version number in order to work correctly at build time and at run time. You will be able to upgrade each dependency independently from each other. As such, a common pattern for specifying the shared version number for Play and Firebase dependencies in Gradle builds will no longer work as expected. The pattern (now anti-pattern) looks like this: 

buildscript {
    ext {
        play_version = '15.0.0'
    }
}

dependencies {
    // DON'T DO THIS!!
    // The following use of the above buildscript property is no longer valid.
    implementation "com.google.android.gms:play-services-auth:${play_version}"
    implementation "com.google.firebase:firebase-auth:${play_version}"
    implementation "com.google.firebase:firebase-firestore:${play_version}"
}

The above Gradle configuration defines a buildscript property called play_version with the version of the Play and Firebase SDKs, and uses that to declare dependencies. This pattern has been helpful to keep all the dependency versions together, as previously required. However, this pattern no longer applies starting with version 15 for each library. Each dependency that you use may now be at different versions. You can expect that individual library updates may not be released at the same time - they may be updated independently.

In order to support this change in versioning, the Play services Gradle plugin has been updated. If you're using this plugin, it appears like this at the bottom of build.gradle in your app module: 

apply plugin: 'com.google.gms.google-services'

Here is what has changed in this plugin:

  • It checks for compatible versions of Play and Firebase libraries. This is similar to enabling the failOnVersionConflict() ResolutionStrategy.
  • Licensing information is embedded in each individual build artifact. If you use the oss-licenses plugin to manage license requirements, you should update it to the latest.

The first version of this plugin that works with the new versioning system is 3.3.0. When working with the new versions of Play and Firebase libraries, it should be added to your buildscript classpath dependencies as follows: 

classpath 'com.google.gms:google-services:3.3.0'

If you're not using this plugin, but you still want strict version checking of your dependencies, you can apply this new Gradle plugin instead: 

apply plugin: 'com.google.android.gms.strict-version-matcher-plugin'

In order to use this plugin, you will also need to add the following to your buildscript classpath, obtained from Google's Maven Repository: 

classpath 'com.google.android.gms:strict-version-matcher-plugin:1.0.0'

If you're not using Android Studio 3.1 to develop your app, you will need to upgrade in order to get the correct version checking behavior within the IDE. Get the newest version of Android Studio here.

With these changes in place, you are now able to adopt new versions of the various SDKs more freely, without a strict requirement to update everything at once. It also enables the development teams for each SDK to ship fixes and enhancements more quickly. Going forward, you can track the releases for Play services SDKs and Firebase SDKs with the provided links.

Time to celebrate the 2018 Google Play Award nominees

Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play

This year's Google Play Awards will take place on Monday, May 7th, kicking off the week of Google I/O. Celebrating our third year, we're excited to highlight nine categories; some you may recognize from previous years, along with new additions highlighting growth areas and trends we're focused on, such as building for emerging markets.

Each year, the Google Play Awards recognize top apps and games on Google Play. They represent some of the best experiences available on Android, with an emphasis on overall quality, strong design, technical performance, and innovation. The nominees were selected by various teams across Google, and all meet criteria thresholds covering high star rating, Android vitals, and have had a launch or major update since April 2017.

Congratulations to this year's nominees below and don't forget to check them out on the Google Play store at g.co/play/gpa2018.

Standout Well-Being App

Apps empowering people to live the best version of their lives, while demonstrating responsible design and engagement strategies

Best Accessibility Experience

Apps or games enabling device interaction in an innovative way that serves people with disabilities or special needs

Best Social Impact

Apps or games that create a positive impact in communities around the world (focused on health, education, crisis response, refugees, financial health & fundraising functions)

Standout Indie

Games from indie developers that focus on artistic design, gameplay mechanics, and overall polish

Best Community Building Game

Games built to connect gamers, encouraging social interaction and community building

Best AR or VR Experience

Apps or games offering highly engaging and immersive experiences with optimal use of ARCore or Daydream UI

Standout Build for Billions Experience

Apps or games with optimized performance, localization, and culturalization for emerging markets

Standout Startup

Apps from new developers that offer a unique experience while achieving strong organic install growth.

Best Breakthrough Hit

New apps or games with excellent overall design, user experience, engagement and retention, and strong organic install growth

Come back on Monday, May 7th when we announce the winners, and until then, make sure to try out some of these great apps and games on Google Play at g.co/play/gpa2018.

How useful did you find this blogpost?
★ ★ ★ ★ ★

Protecting WebView with Safe Browsing

Posted by Nate Fischer, Software Engineer

Since 2007, Google Safe Browsing has been protecting users across the web from phishing and malware attacks. It protects over three billion devices from an increasing number of threats, now also including unwanted software across desktop and mobile platforms. Today, we're announcing that Google Play Protect is bringing Safe Browsing to WebView by default, starting in April 2018 with the release of WebView 66.

Developers of Android apps using WebView no longer have to make any changes to benefit from this protection. Safe Browsing in WebView has been available since Android 8.0 (API level 26), using the same underlying technology as Chrome on Android. When Safe Browsing is triggered, the app will present a warning and receive a network error. Apps built for API level 27 and above can customize this behavior with new APIs for Safe Browsing.

An example of a warning shown when Safe Browsing detects a dangerous site. The style and content of the warning will vary depending on the size of the WebView.

You can learn more about customizing and controlling Safe Browsing in the Android API documentation, and you can test your application today by visiting the Safe Browsing test URL (chrome://safe-browsing/match?type=malware) while using the current WebView beta.

Android Things Release Candidate

Posted by Dave Smith, Developer Advocate for IoT

Earlier this year at CES, we showcased consumer products powered by Android Things from partners like Lenovo, LG, JBL, iHome, and Sony. We are excited to see Android Things enable the wider developer ecosystem as well. Today we are announcing the final preview release of Android Things, Developer Preview 8, before the upcoming stable release.

Feature complete SDK

Developer Preview 8 represents the final API surface exposed in the Android Things support library for the upcoming stable release. There will be no more breaking API changes before the stable v1.0 release of the SDK. For details on all the API changes included in DP8, see the release notes. Refer to the updated SDK reference to review the classes and methods in the final SDK.

This release also brings new features in the Android Things developer console to make building and managing production devices easier. Here are some notable updates:

Production-focused console enhancements

With an eye towards building and shipping production devices with the upcoming LTS release, we have made several updates to the Android Things developer console:

  • Enhanced OTA: Unpublish the current OTA build when issues are discovered in the field.
  • Visual storage layout: Configure the device storage allocated to apps and data for each build, and get an overview of how much storage your apps require.
  • Font/locale controls: Configure the set of supported fonts and locales packaged into each build.
  • Group sharing: Product sharing has been extended to include support for Google Groups.

App library

The new app library enables you to manage APKs more easily without the need to package them together in a separate zipped bundle. Track individual versions, review permissions, and share your apps with other console users. See the app library documentation for more details.

Permissions

On mobile devices, apps request permissions at runtime and the end user grants them. In earlier previews, Android Things granted these same permissions automatically to apps on device boot. Beginning in DP8, these permissions are granted using a new interface in the developer console, giving developers more control of the permissions used by the apps on their device.

This change does not affect development, as Android Studio grants all permissions by default. Developers using the command line can append the -g flag to the adb install command to get the same behavior. To test how apps on your device behave with certain permissions revoked, use the pm command: 

$ adb shell pm [grant|revoke] <permission-name> ...

App launch behavior

Embedded devices need to launch their primary application automatically after the device boots, and relaunch it if the app terminates unexpectedly. In earlier previews, the main app on the device could listen for a custom IOT_LAUNCHER intent to enable this behavior. Beginning in DP8, this category is replaced by the standard CATEGORY_HOME intent. 

<activity android:name=".HomeActivity">
    ...

    <!-- Launch activity automatically on boot, relaunch on termination. -->
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.HOME"/>
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Apps that contain an IOT_LAUNCHER intent filter will no longer be triggered on boot. Update your apps to use CATEGORY_HOME instead.

Feedback

Thanks to all of you in the developer community for sharing your feedback with us throughout developer preview. Join Google's IoT Developers Community on Google+ to let us know what you're building with Android Things and how we can improve the platform in future releases to help you build connected devices at scale!

DNS over TLS support in Android P Developer Preview

Posted by Erik Kline, Android software engineer, and Ben Schwartz, Jigsaw software engineer

The first step of almost every connection on the internet is a DNS query. A client, such as a smartphone, typically uses a DNS server provided by the Wi-Fi or cellular network. The client asks this DNS server to convert a domain name, like www.google.com, into an IP address, like 2607:f8b0:4006:80e::2004. Once the client has the IP address, it can connect to its intended destination.

When the DNS protocol was designed in the 1980s, the internet was a much smaller, simpler place. For the past few years, the Internet Engineering Task Force (IETF) has worked to define a new DNS protocol that provides users with the latest protections for security and privacy. The protocol is called "DNS over TLS" (standardized as RFC 7858).

Like HTTPS, DNS over TLS uses the TLS protocol to establish a secure channel to the server. Once the secure channel is established, DNS queries and responses can't be read or modified by anyone else who might be monitoring the connection. (The secure channel only applies to DNS, so it can't protect users from other kinds of security and privacy violations.)

DNS over TLS in P

The Android P Developer Preview includes built-in support for DNS over TLS. We added a Private DNS mode to the Network & internet settings.

By default, devices automatically upgrade to DNS over TLS if a network's DNS server supports it. But users who don't want to use DNS over TLS can turn it off.

Users can enter a hostname if they want to use a private DNS provider. Android then sends all DNS queries over a secure channel to this server or marks the network as "No internet access" if it can't reach the server. (For testing purposes, see this community-maintained list of compatible servers.)

DNS over TLS mode automatically secures the DNS queries from all apps on the system. However, apps that perform their own DNS queries, instead of using the system's APIs, must ensure that they do not send insecure DNS queries when the system has a secure connection. Apps can get this information using a new API: LinkProperties.isPrivateDnsActive().

With the Android P Developer Preview, we're proud to present built-in support for DNS over TLS. In the future, we hope that all operating systems will include secure transports for DNS, to provide better protection and privacy for all users on every new connection.

Time to Upgrade from GCM to FCM

Originally posted by Jen Person on the Firebase Blog.

In 2016, we unveiled Firebase Cloud Messaging (FCM) as the next evolution of Google Cloud Messaging (GCM). Since then, we've been working hard to make Firebase Cloud Messaging even more powerful than its predecessor. Like GCM, Firebase Cloud Messaging allows you to send notifications and data messages reliably to iOS, Android, and the Web at no cost. In addition, FCM includes a host of new features, such as an intuitive notifications interface in the Firebase console, better reporting, and native integrations with other Firebase products. With FCM, you can target and test notifications to re-engage your users with greater ease and efficiency.

We're excited to devote more time and attention to improving FCM. That's why today we're announcing that all developers will need to upgrade to FCM within a year. The GCM server and client APIs have been deprecated and will be removed as soon as April 11th, 2019. We recommend you upgrade sooner rather than later so you can start taking advantage of the new features we're building in FCM right away!


To help you through the upgrade, we've created a step-by-step migration guide and answered a few of the most common questions you'll probably have below.

What else is new in FCM?

Once you upgrade, you'll be able to use all of the new features and functionality available in FCM, like platform overrides and topic combinations. You'll also be able to send notifications directly from the Firebase console! What's more, FCM integrates seamlessly with other Firebase products like A/B Testing and Predictions.

Want to test different messages to see which one drives more conversions? You can use FCM with A/B Testing to run experiments to optimize your notifications. Want to engage users who are likely to churn or spend money in your app? You can use FCM with Predictions to target notifications to users based on their predicted behavior.

These are some of the awesome features you'll have at your fingertips with FCM. In the future, we'll be adding many more!

Will I still be able to send messages to my existing users?

If you have projects that are still using the GCM APIs, you will need to update your client and server code to use FCM before April 11, 2019. But rest assured, your existing GCM tokens will continue to work with FCM so you won't lose the ability to send messages to your existing users.

How do I upgrade?

The full process is outlined in our migration guide, or if you prefer video content, you can also check out this Firecast for details.

On a high level, upgrading consists of three main parts: console-side, app-side, and server-side.

  • In the Firebase console, you'll need to create a new Firebase project using your app's existing Cloud Project ID.
  • In your app, you'll need to make some code changes. The amount of changes will depend on what features of GCM you currently use, such as topic subscriptions and token generation.
  • On the server side, you'll need to change the server endpoint from GCM to FCM.

Keep in mind that you don't have to complete all three parts of the process in one sitting - you can take it at your own pace. For example, you can choose to configure the console today and work on the app code another time. You're also free to update your app's code right now, and tackle the server-side requirements later.

What happens to my users who don't update their apps?

As long as users have GCM logic in their apps, they will still receive messages. FCM is backwards compatible with GCM, so even if you don't update your server endpoint now, you can still update your app's logic, and vice versa.

What data will Firebase collect and use? I'm concerned about privacy.

Please see the Firebase terms and the Firebase Privacy and Security Policy. You can disable Google Analytics for Firebase to reduce the amount of data that is collected, but keep in mind this will also disable some FCM features.

What if I still have questions?

We're here to help you through the upgrade process. Check out this nifty FAQ page as a start. We also encourage you to post your questions on StackOverflow. Or, feel free to reach out to Firebase support through any of these means.

To save you clicking time, here are some of the links that are also worth a read. Start with the upgrade guide, and then check out the other links to find out more.

What if I already migrated?

Awesome! How'd it go? Tweet me at @ThatJenPerson to tell me what went well and what didn't. Sharing your experience helps us make improvements!

We look forward to welcoming you to FCM, the next evolution of GCM!

Protecting users with TLS by default in Android P

Posted by Chad Brubaker, Senior Software Engineer Android Security

Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting all data that enters or leaves an Android device with Transport Layer Security (TLS) in transit. As we announced in our Android P developer preview, we're further improving these protections by preventing apps that target Android P from allowing unencrypted connections by default.

This follows a variety of changes we've made over the years to better protect Android users.To prevent accidental unencrypted connections, we introduced the android:usesCleartextTraffic manifest attribute in Android Marshmallow. In Android Nougat, we extended that attribute by creating the Network Security Config feature, which allows apps to indicate that they do not intend to send network traffic without encryption. In Android Nougat and Oreo, we still allowed cleartext connections.

How do I update my app?

If your app uses TLS for all connections then you have nothing to do. If not, update your app to use TLS to encrypt all connections. If you still need to make cleartext connections, keep reading for some best practices.

Why should I use TLS?

Android considers all networks potentially hostile and so encrypting traffic should be used at all times, for all connections. Mobile devices are especially at risk because they regularly connect to many different networks, such as the Wi-Fi at a coffee shop.

All traffic should be encrypted, regardless of content, as any unencrypted connections can be used to inject content, increase attack surface for potentially vulnerable client code, or track the user. For more information, see our past blog post and Developer Summit talk.

Isn't TLS slow?

No, it's not.

How do I use TLS in my app?

Once your server supports TLS, simply change the URLs in your app and server responses from http:// to https://. Your HTTP stack handles the TLS handshake without any more work.

If you are making sockets yourself, use an SSLSocketFactory instead of a SocketFactory. Take extra care to use the socket correctly as SSLSocket doesn't perform hostname verification. Your app needs to do its own hostname verification, preferably by calling getDefaultHostnameVerifier() with the expected hostname. Further, beware that HostnameVerifier.verify() doesn't throw an exception on error but instead returns a boolean result that you must explicitly check.

I need to use cleartext traffic to...

While you should use TLS for all connections, it's possibly that you need to use cleartext traffic for legacy reasons, such as connecting to some servers. To do this, change your app's network security config to allow those connections.

We've included a couple example configurations. See the network security config documentation for a bit more help.

Allow cleartext connections to a specific domain

If you need to allow connections to a specific domain or set of domains, you can use the following config as a guide: 

<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
        <domain includeSubdomains="true">insecure.cdn.example.com</domain>
    </domain-config>
</network-security-config>

Allow connections to arbitrary insecure domains

If your app supports opening arbitrary content from URLs over insecure connections, you should disable cleartext connections to your own services while supporting cleartext connections to arbitrary hosts. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit. 

<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">example.com</domain>
        <domain includeSubdomains="true">cdn.example2.com</domain>
    </domain-config>
    <base-config cleartextTrafficPermitted="true" />
</network-security-config>

How do I update my library?

If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.

Android Studio switching to D8 dexer

Posted by Jeffrey van Gogh, Software Engineering Manager

D8 now default dex compiler

Faster, smarter app compilation is always a goal for the Android tools teams. That's why we previously announced D8, a next-generation dex compiler. D8 runs faster and produces smaller .dex files with equivalent or better runtime performance when compared to the historic compiler - DX.

We recently announced that D8 has become the default compiler in Android Studio 3.1. If you haven't previously tried D8, we hope that you notice better, faster dex compilation as you make the switch.

D8 was first shipped in Android Studio 3.0 as an opt-in feature. In addition to our own rigorous testing, we've now seen it perform well in a wide variety of apps. As a result, we're confident that D8 will work well for everyone who starts using it in 3.1. However, if you do have issues, you can always revert to DX for now via this setting in your project's gradle.properties file: 

android.enableD8=false

If you do encounter something that causes you to disable D8, please let us know!

Next Steps

Our goal is to ensure that everyone has access to a fast, correct dex compiler. So to avoid risking regressions for any of our users, we'll be deprecating DX in three phases

The first phase is intended to prevent prematurely deprecating DX. During this phase, DX will remain available in studio. We'll fix critical issues in it, but there won't be new features. This phase will last for at least six months, during which we'll evaluate any open D8 bugs to decide if there are regressions which would prevent some users from replacing DX with D8. The first phase won't end until the team addresses all migration blockers. We'll be paying extra attention to the bug tracker during this window, so If you encounter any of these regressions, please file an issue.

Once we've seen a six month window without major regressions from DX to D8, we'll enter the second phase. This phase will last for a year, and is intended to ensure that even complex projects have lots of time to migrate. During this phase, we'll keep DX available, but we'll treat it as fully deprecated; we won't be fixing any issues.

During the third and final phase, DX will be removed from Android Studio. At this point, you'll need to use a legacy version of the Android Gradle Plugin in order to continue to build with DX.

Android Studio switching to D8 dexer

Posted by Jeffrey van Gogh, Software Engineering Manager

D8 now default dex compiler

Faster, smarter app compilation is always a goal for the Android tools teams. That's why we previously announced D8, a next-generation dex compiler. D8 runs faster and produces smaller .dex files with equivalent or better runtime performance when compared to the historic compiler - DX.

We recently announced that D8 has become the default compiler in Android Studio 3.1. If you haven't previously tried D8, we hope that you notice better, faster dex compilation as you make the switch.

D8 was first shipped in Android Studio 3.0 as an opt-in feature. In addition to our own rigorous testing, we've now seen it perform well in a wide variety of apps. As a result, we're confident that D8 will work well for everyone who starts using it in 3.1. However, if you do have issues, you can always revert to DX for now via this setting in your project's gradle.properties file: 

android.enableD8=false

If you do encounter something that causes you to disable D8, please let us know!

Next Steps

Our goal is to ensure that everyone has access to a fast, correct dex compiler. So to avoid risking regressions for any of our users, we'll be deprecating DX in three phases

The first phase is intended to prevent prematurely deprecating DX. During this phase, DX will remain available in studio. We'll fix critical issues in it, but there won't be new features. This phase will last for at least six months, during which we'll evaluate any open D8 bugs to decide if there are regressions which would prevent some users from replacing DX with D8. The first phase won't end until the team addresses all migration blockers. We'll be paying extra attention to the bug tracker during this window, so If you encounter any of these regressions, please file an issue.

Once we've seen a six month window without major regressions from DX to D8, we'll enter the second phase. This phase will last for a year, and is intended to ensure that even complex projects have lots of time to migrate. During this phase, we'll keep DX available, but we'll treat it as fully deprecated; we won't be fixing any issues.

During the third and final phase, DX will be removed from Android Studio. At this point, you'll need to use a legacy version of the Android Gradle Plugin in order to continue to build with DX.