ComplicationDrawable
WatchFaceStyle.setAccentColor
WatchFaceStyle.setHideNotificationIndicator
WatchFaceStyle.setShowUnreadCountIndicator,
WatchFaceStyle.getUnreadCount
TYPE_NO_PERMISSION
onTap
Drawable.Callback
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.
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 any developer to implement a service. We are actively working with 1Password, Dashlane, Keeper, and LastPass to help them with their implementations and will be working with other password managers shortly. We are also creating a new curated collection on the Play Store, which the "Add service" button in Settings will link to. If you are a password manager developer and would like us to review your app, please get in touch.
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:
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.
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:
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.
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.
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:
If you encounter any issues or have any suggestions for how we can make this better for you, please send us feedback.
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.
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.
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:
targetSdkLevel
REQUEST_INSTALL_PACKAGES
<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.
ACTION_MANAGE_UNKNOWN_APP_SOURCES
canRequestPackageInstalls()
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.
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
