Tag Archives: Android

Congratulations to our US Grow with Google Developer Scholars!

Posted by Peter Lubbers, Head of Google Developer Training

Grow with Google in partnership with Udacity, is awarding 5,000 Nanodegree program scholarships to help aspiring developers in the US continue their digital skills training and prepare for jobs as Android or Mobile Web developers.

As part of the Grow with Google Developer Scholarship program, scholars completed an initial challenge course at Udacity - completing on average over 100 hours of coursework, building coding project portfolios and engaging with their local developer community. Today, Google and Udacity are excited to recognize the 5,000 top performers in the challenge course, and offer them a chance to continue their training through a Nanodegree program with a full scholarship.

By successfully completing a Nanodegree program, scholars earn an industry-recognized credential helping to create a path for increased job opportunities as well as prepare for one of Google's Developer Certifications: Associate Android Developer or Mobile Web Specialist. These developer training programs offer scholars the opportunity to build their skills and become job-ready, helping to close the gap in the more than 500,000 open computing jobs in the US.

We are incredibly inspired by the hard work and passion shown by all our Grow with Google developer scholars -- including these stellar scholars:

Bela from Tennessee, a mother of two working toward her goal of becoming a web developer. Bela recently shared her personal story of determination to complete her developer training.

Desmend from Illinois, who is taking what he learns in his Android developer course and sharing it with local high school students that he mentors -- teaching them about technology and the type of career opportunities offered to developers.

Sean from Alabama, a veteran using his course training to transition into the civilian workforce as an Android developer.

And Demetra from New York, who utilized the online training and forums to achieve her goal of advancing her skills in web development.

This scholarship effort is part of the Grow with Google initiative, which is aimed at helping create economic opportunities for Americans by offering free tools, training, and events. Udacity is excited to partner with Google on this powerful effort and together we look forward to seeing what these scholars will achieve in the coming year.

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.

Allow users to install any app on their managed Android devices

Until now, G Suite users with company-owned Android devices and those with work profiles could only install mobile apps that had been specifically whitelisted by their admin. In some organizations, however, such restrictions weren’t critical, and whitelisting required unnecessary time and effort. That’s why, going forward, we’re giving admins the option to allow their users to install any app in the managed Google Play store on Android devices that are corporate-owned or have work profiles.

Admins can select this option in the Admin console under Device management > App Management > Manage apps for Android devices.


If an admin selects “Allow all apps,” he or she can still whitelist specific apps. These whitelisted apps will appear on the managed Google Play homepage, but users will be able to find any app using the search tool.


For more information, visit the Help Center.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to all G Suite editions

Rollout pace:
Gradual rollout (up to 15 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center: Manage apps on mobile devices


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates

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.

Use your favorite password manager with Android Oreo


Security experts recommend strong, unique passwords for each service that you use. For most of us, however, it can be difficult to manage credentials across multiple websites and apps, especially if you’re trying to keep track of everything in your head.

In Android 8.0 Oreo, we made it simpler to use Autofill with a password manager, like LastPass, Dashlane, Keeper, or 1Password. Particularly on tiny devices like your phone, autofill can make your life easier by remembering things (with your permission), so that you don’t have to type out your name, address, or credit card over and over again.

With the new autofill services in Oreo, password managers can access only the information that’s required in order to autofill apps, making your data more secure. There’s a specific list of password managers (which you can find in Android Settings) that meet our security and functional requirements, and we'll be continuing to grow this list over time. If you already use a password manager, then you’ll be able to try the new experience today.

Screenshot_20180320-184752.png


How does it work?

Setting up Autofill on your device is easy. Simply go to Settings, search for “Autofill,” and tap “Autofill service.” If you already have a password manager installed, it will show up in this list. You can also tap “Add service” to download the password manager of your choice from the Play Store.

Once you’ve set a password manager as your Autofill service, the information stored in that app will show up in Autofill whenever you fill out forms (for example, your saved username and password will show up as a suggestion when you’re logging into an app for the first time).

We include Google as an autofill service on all devices running Android 8.0 and above, which lets you use data that you already have saved in Chrome to fill in passwords, credit cards, addresses, and other personal information.


2

Language and input settings

Screenshot_20180320-190647.png

Autofill service settings: here you can pick the app that you would like to use as your Autofill service

Whether you use Google or another password manager from the Play Store, the new Autofill experience on Oreo makes it easier to securely store and recall commonly typed information, like passwords and credit card numbers.

Source: Android


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.