Tag Archives: oreo

Android Wear SDK and Emulator Update

Posted by Hoi Lam, Lead Developer Advocate, Android Wear
Today we launched the latest version of the Android Wear SDK (2.2.0) with several watch face related enhancements. These include the addition of an unread notification indicator for all watch faces, which is planned to be part of the upcoming consumer release of Android Wear. With the Wear SDK 2.2.0, you can customize the notification indicator or display your own. This feature is available to the developer community early, via the SDK and emulator, so you can verify that the indicator fits the design of your watch face. In addition, we are adding enhancements to the ComplicationDrawable class and publishing the final version of the Wear emulator based on Android Oreo.

Introducing the unread notification indicator


Notification is a vital part of the Wear experience. As a result, starting from the next consumer release of Wear (version 2.9.0), a dot-shaped indicator will be displayed by default at the bottom of the watch face if there are new, unread notifications. Watch face developers can preview the indicator with their watch faces by using the latest version of the emulator. Developers can customise the indicator's accent color via WatchFaceStyle.setAccentColor - the default color is white as shown in the example below, but developers can set the color for the ring around the dot to an accent color of their choice, to match the rest of the watch face.
If the new indicator does not fit with the design of your watch face, you can switch it off using WatchFaceStyle.setHideNotificationIndicator and choose another option for displaying the notification, including: 1) displaying the number of unread notifications in the system tray using WatchFaceStyle.setShowUnreadCountIndicator, or 2) getting the number of unread notifications using WatchFaceStyle.getUnreadCount and displaying the number in a way that fits your watch face's unique style.

Enhancement to ComplicationDrawable


We launched the ComplicationDrawable class at last year's Google I/O, and we are continuing to improve it. In this latest SDK release, we added two enhancements:
  • Permission Handling - If the watch face lacks the correct permission to display the content of a complication, the complication type of TYPE_NO_PERMISSION is issued. ComplicationDrawable now handles this automatically and will launch a permission request in onTap. If you previously implemented your own code to start the permission screen, please check that the permission screen is not triggered twice and, if necessary, remove unneeded code.
  • Drawable Callback - If a complication contains an image or an icon, it can take a small amount of time to load after the other initial data arrives. Our previous recommendation therefore was that you redraw the screen every second. But this is unnecessary for watch faces that only update once per minute, for example. As a result, we have added new support for Drawable.Callback to ComplicationDrawable. Developers who update the screen less frequently than once per second should adopt this new callback to redraw the watch face when images have loaded.
For more, please see the Android Wear Release Notes which includes other information regarding the emulator.

More improvements to come


Many of you have noticed a steady release of enhancements to Android Wear over the last few months since the launch of Wear 2.0. We are developing many more for the months ahead and look forward to sharing more when the features are ready.



Getting your Android app ready for Autofill

Posted by Wojtek Kalicinski, Android Developer Advocate, Akshay Kannan, Product Manager for Android Authentication, and Felipe Leme, Software Engineer on Android Frameworks

Starting in Oreo, Autofill makes it easy for users to provide credit cards, logins, addresses, and other information to apps. Forms in your apps can now be filled automatically, and your users no longer have to remember complicated passwords or type the same bits of information more than once.

Users can choose from multiple Autofill services (similar to keyboards today). By default, we include Autofill with Google, but users can also select any third party Autofill app of their choice. Users can manage this from Settings->System->Languages>Advanced->Autofill service.

What's available today

Today, Autofill with Google supports filing credit cards, addresses, logins, names, and phone numbers. When logging in or creating an account for the first time, Autofill also allows users to save the new credentials to their account. If you use WebViews in your app, which many apps do for logins and other screens, your users can now also benefit from Autofill support, as long as they have Chrome 61 or later installed.

The Autofill API is open for anyone to implement a service. We are actively working with 1Password, Dashlane, Keeper, and LastPass to help them with their implementations towards becoming certified on Android. We will be certifying password managers and adding them to a curated section in the Play Store, which the "Add service" button in settings will link to. If you are a password manager and would like to be certified, please get in touch.

What you need to do as a developer

As an app developer, there are a few simple things you can do to take advantage of this new functionality and make sure that it works in your apps:

Test your app and annotate your views if needed

In many cases, Autofill may work in your app without any effort. But to ensure consistent behavior, we recommend providing explicit hints to tell the framework about the contents of your field. You can do this using either the android:autofillHints attribute or the setAutofillHints() method.

Similarly, with WebViews in your apps, you can use HTML Autocomplete Attributes to provide hints about fields. Autofill will work in WebViews as long as you have Chrome 61 or later installed on your device. Even if your app is using custom views, you can also define the metadata that allows autofill to work.

For views where Autofill does not make sense, such as a Captcha or a message compose box, you can explicitly mark the view as IMPORTANT_FOR_AUTOFILL_NO (or IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS in the root of a view hierarchy). Use this field responsibly, and remember that users can always bypass this by long pressing an EditText and selecting "Autofill" in the overflow menu.

Affiliate your website and mobile app

Autofill with Google can seamlessly share logins across websites and mobile apps ‒ passwords saved through Chrome can also be provided to native apps. But in order for this to work, as an app developer, you must explicitly declare the association between your website with your mobile app. This involves 2 steps:

Step 1: Host a JSON file at yourdomain.com/.well-known/assetlinks.json

If you've used technologies like App Links or Google Smart Lock before, you might have heard about the Digital Asset Links (DAL) file. It's a JSON file placed under a well known location in your website that lets you make public, verifiable statements about other apps or websites.

You should follow the Smart Lock for Passwords guide for information about how to create and host the DAL file correctly on your server. Even though Smart Lock is a more advanced way of signing users into your app, our Autofill service uses the same infrastructure to verify app-website associations. What's more, because DAL files are public, third-party Autofill service developers can also use the association information to secure their implementations.

Step 2: Update your App's Manifest with the same information

Once again, follow the Smart Lock for Passwords guide to do this, under "Declare the association in the Android app."

You'll need to update your app's manifest file with an asset_statements resource, which links to the URL where your assetlinks.json file is hosted. Once that's done, you'll need to submit your updated app to the Play Store, and fill out the Affiliation Submission Form for the association to go live.

When using Android Studio 3.0, the App Links Assistant can generate all of this for you. When you open the DAL generator tool (Tools -> App Links Assistant -> Open Digital Asset Links File Generator), simply make sure you enable the new checkbox labeled "Support sharing credentials between the app and website".

Then, click on "Generate Digital Asset Links file", and copy the preview content to the DAL file hosted on your server and in your app. Please remember to verify that the selected domain names and certificates are correct.

Future work

It's still very early days for Autofill in Android. We are continuing to make some major investments going forward to improve the experience, whether you use Autofill with Google or a third party password manager.

Some of our key areas of investment include:

  1. Autofill with Google: We want to provide a great experience out of the box, so we include Autofill with Google with all Oreo devices. We're constantly improving our field detection and data quality, as well as expanding our support for saving more types of data.
  2. WebView support: We introduced initial support for filling WebViews in Chrome 61, and we'll be continuing to test, harden, and make improvements to this integration over time, so if your app uses WebViews you'll still be able to benefit from this functionality.
  3. Third party app support: We are working with the ecosystem to make sure that apps work as intended with the Autofill framework. We urge you as developers to give your app a spin on Android Oreo and make sure that things work as expected with Autofill enabled. For more info, see our full documentation on the Autofill Framework.

If you encounter any issues or have any suggestions for how we can make this better for you, please send us feedback.

Making it safer to get apps on Android O

Posted by Edward Cunningham. Product Manager, Android Security

Eagle-eyed users of Android O will have noticed the absence of the 'Allow unknown sources' setting, which has existed since the earliest days of Android to facilitate the installation of apps from outside of Google Play and other preloaded stores. In this post we'll talk about the new Install unknown apps permission and the security benefits it brings for both Android users and developers.

Earlier this year we introduced Google Play Protect - comprehensive security services that are always at work to protect your device from harm. Google Play continues to be one of the safest places for Android users to download their apps, with the majority of Potentially Harmful Apps (PHAs) originating from third-party sources.

A common strategy employed by PHA authors is to deliver their apps via a hostile downloader. For example, a gaming app might not contain malicious code but instead might notify the user to install a PHA that masquerades as an important security update. (You can read more about hostile downloaders in the Android Security 2016 Year in Review). Users who have enabled the installation of apps from unknown sources leave themselves vulnerable to this deceptive behavior.

Left (pre-Android O): The install screen for a PHA masquerading as a system update.
Right (Android O): Before the PHA is installed, the user must first grant permission to the app that triggered the install.

In Android O, the Install unknown apps permission makes it safer to install apps from unknown sources. This permission is tied to the app that prompts the install— just like other runtime permissions—and ensures that the user grants permission to use the install source before it can prompt the user to install an app. When used on a device running Android O and higher, hostile downloaders cannot trick the user into installing an app without having first been given the go-ahead.

This new permission provides users with transparency, control, and a streamlined process to enable installs from trusted sources. The Settings app shows the list of apps that the user has approved for installing unknown apps. Users can revoke the permission for a particular app at any time.

At any time, users can review the apps that they've allowed for installing unknown apps. To make the permission-granting process easier, app developers can choose to direct users to their permission screen as part of the setup flow.

Developer changes

To take advantage of this new behavior, developers of apps that require the ability to download and install other apps via the Package Installer may need to make some changes. If an app uses a targetSdkLevel of 26 or above and prompts the user to install other apps, the manifest file needs to include the REQUEST_INSTALL_PACKAGES permission: 

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

Apps that haven't declared this permission cannot install other apps, a handy security protection for apps that have no intention of doing so. You can choose to pre-emptively direct your users to the Install unknown apps permission screen using the ACTION_MANAGE_UNKNOWN_APP_SOURCES Intent action. You can also query the state of this permission using the PackageManager canRequestPackageInstalls() API.

Remember that Play policies still apply to apps distributed on Google Play if those apps can install and update other apps. In the majority of cases, such behavior is inappropriate; you should instead provide a deep link to the app's listing on the Play Store.

Be sure to check out the updated publishing guide that provides more information about installing unknown apps, and stay tuned for more posts on security hardening in Android O.