The latest Android and Google Play news for app and game developers.
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? ★ ★ ★ ★ ★
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.
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:
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:
-g
adb install
pm
$ 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.
IOT_LAUNCHER
<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!
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.)
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().
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.
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.
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!
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.
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.
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.
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.
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.
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.
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!
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.
android:usesCleartextTraffic
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.
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.
No, it's not.
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.
getDefaultHostnameVerifier()
HostnameVerifier.verify()
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.
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>
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>
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.
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.
Play Console
