Hi, I’m Charmaine D’Silva,
and I’m a product manager on the Android team.
This video will introduce you to the top 12 tips
to get your apps ready for Android 12.
Before diving in the details, I want to talk about the compatibility framework.
Various platform changes may impact different parts of your app,
so it's helpful to isolate testing to specific behavior changes.
Through the compatibility framework, you'll be able to selectively toggle
or force enable changes for your app
so that you can focus on addressing each behavior change individually.
You can find these settings in developer options
or you can also configure them using ADB commands.
Like previous releases, Android 12 brings many improvements
to various parts of the operating system,
including user experience, performance, and privacy.
These improvements may come with behavior changes to existing APIs or system UIs.
With these changes, we understand that some of your apps
may run into compatibility issues on the new release.
We rely on the developer preview program
to give you an early look at the release and get your feedback.
In this video, we will review 12 notable platform changes that you should be aware of.
Let's get started.
It's very common for smartphone users to be multitasking on the device.
They could be listening to a podcast while ordering food
or checking their email while helping a friend with turn-by-turn navigation.
If your app has multitasking use cases, you'll likely be using foreground services
to implement long-running user-initiated tasks at a high priority.
Foreground services were designed for exactly these use cases that involve multitasking
and completing a user action.
However, when we looked into how foreground services were being used,
we found that almost half of them are started from the background.
Users are surprised with the unexpected
and non-actionable foreground services notifications
and find them very distracting.
Additionally, foreground services take up valuable system resources
and the operating system can’t prioritize resourcing them effectively.
So in Android 12, we disallow foreground services launches from the background.
This change will apply to apps that target Android 12 or above.
We know your app will still need to be able to do high-priority tasks in the background.
For short background tasks that need to be executed as soon as possible,
we're introducing Expedited Jobs that your app can migrate to.
These are low-latency jobs that can be invoked
from either the foreground or the background
to be able to be executed immediately.
Check out the Effective background tasks on Android video to learn more.
Another new privacy control we added in Android 12
are mic and camera toggles that allow the users the ability
to disable their microphone or camera access.
We designed these toggles such that apps that are following permissions best practices
need not do anything differently.
Your app will continue to think it’s accessing the microphone or camera,
but instead receive blank feeds when the microphone or camera are disabled.
The system’ll take care of prompting the user to remind them of the toggle state.
These controls will affect apps regardless of the target SDK level.
Finally, let's talk about app hibernation.
There’s a good chance you have apps on your device you haven’t used for months.
Installed apps take up system resources like storage
and you may have previously blocked their permissions.
Android 12 expands permissions auto-reset feature from Android 11
and puts unused apps in a hibernated state.
Apps that are hibernated will have a few things happen to them.
One, the system will revoke any previously granted permissions.
Two, the system would also free up storage by clearing up app cache.
Three, any jobs and push messages will also stop
and your app will behave as if a user force stopped it.
You can learn more about app hibernation and the other privacy changes
in the What’s New in Android Privacy video.
I’m now going to hand over to Narayan who’ll walk through the rest of the features.
Thank you.
Thanks a lot, Charmaine.
Hi, everyone.
I’m Narayan, and I’m an engineer in the Android team.
I’m going to start this off by talking a little bit about Bluetooth.
We've heard loud and clear from you that a more fine-grained permission model
is needed for discovering nearby devices like Bluetooth, smartwatches, and headsets.
So for apps that target Android 12,
you'll have the option to decouple nearby device discovery
from the find location permission for use cases like pairing devices.
You can use the new BLUETOOTH_SCAN permission
and the usesPermissionFlags attributes shown here
to declare that you will never derive location info
from Bluetooth devices such as beacons.
Once a device has paired,
you can use the new BLUETOOTH_CONNECT permission to interact with it.
Not only do these permission changes help promote privacy-friendly app design
but they also reduce user friction
because users won’t be asked to grant location permission if it isn’t needed.
Of course, if your app is pairing with companion devices,
the recommended best practice is to use the CompanionDeviceManager API
which provides a more streamlined UX, among other advantages.
Let's talk a bit about network MAC addresses.
In Android 12, we further restricted access to the network MAC address.
If your app targets Android 12, the getHardwareAddress API will return null.
For other API levels, it will return a fixed placeholder value.
You can also use the compatibility flags shown here
to temporarily force the API to return a placeholder value,
giving you a bit more time to migrate.
In general, you should avoid using low-level API
like getifaddrs or Netlink sockets for network connectivity operations.
You should always prefer to use the ConnectivityManager class instead.
As a reminder, when it comes to identifiers, it’s always best to use user-resettable IDs,
as they're more privacy friendly.
Depending on your use case,
you should strongly consider using options such as SSAID instead.
We've been evolving the platform over time to set safety rules to protect developers.
One such area we've tightened up an Android 12
is the exported attribute of your apps's components.
If your app targets Android 12,
you now need to explicitly specify the attribute
on any component with intent filters.
In other words, you have to make a conscious and explicit decision
to share your component.
If you don't, your app won't compile
and you'll see the error message shown here.
It’s time to scan your application manifest to make sure that the attribute
is properly set for all of your components.
We're also rolling out lint warnings in Android Studio
to help you detect these issues.
We're also making changes to notifications in Android 12.
Your apps will be affected if they use fully-custom notifications.
That is, those that use methods like setCustomContentView in the builder classes.
For apps targeting Android 12, the system applies a standard template
in order to provide a more consistent user experience for notifications.
This includes the app icon, the app name,
and expansion and collapsed state affordances.
You are strongly encouraged to update your app's target SDK level
and verify that notification layouts look right,
including expanded and collapsed states and heads-up notifications.
As many of you know, Android supports the notion of App Links
that lets HTTP URLs be directly linked to an installed app
bypassing the disambig dialog entirely.
They improve user experience by removing friction from user journeys.
Unfortunately though, we found that developers often make mistakes
in configuring their App Links,
sometimes causing more disambig dialogs to show up than are necessary.
So in Android 12, we’re improving App Links
to reduce user friction resulting from improper setup
and providing tools to detect problems.
We made App Links verification granular on a link-by-link basis.
So if you have any server-side integration issues,
errors will be limited to links that don't pass verification.
We’ve added ADB commands shown on the slide here to help you test things out.
Second, Android 12 takes the user directly to a browser
if no default app is installed.
And third, there’s new APIs in Android 12
that let you check for domain verification states,
and if needed, take the user to settings for them to approve domains for your app.
Make sure you check these tools out
to verify that your App Links setup is ready to go.
Time for WebViews.
If your app uses a WebView,
or if you manage a website or service that uses cookies,
we recommend testing your flows with WebView in Android 12.
WebView is based on Chromium
which has introduced changes to the handling of third-party cookies
through an attribute called SameSite.
This provides better security and privacy for your users.
You can test this out by either setting your app’s target SDK level to Android 12
or you can set a toggle in the WebView DevTools
to enable these new behaviors.
In your tests, be sure to watch for issues in logins, payments,
and any flows where the user starts on an insecure page
and transitions to a secure page.
Overscroll. Overscroll is an effect
when the user hits the content boundaries and continues to scroll,
either by explicit dragging or by a fling.
The current default Android overscroll behavior
is a glow effect that appears in the content edge
and reflects the XY coordinate changes.
For Android 12, overscroll will provide
a new system-wide stretch all effect to the overshoot behavior.
The goal here is to improve upon the existing overscrolled UX
to give it a more natural scroll stop indicator.
To test, update your app's target SDK level
and verify that scrolling containers have the new overscroll behavior.
Well, that brings us to the end of our 12 tips,
and I hope you found them useful.
There’s a lot more, though, too much for a single set of slides
or perhaps the margin of a notebook.
Among other things, we made changes to touch event handling,
notification trampolines, and exact alarms.
You can learn about all of these changes and many more
on the Developer website link shown here.
It contains a more comprehensive summary of our notable behavior changes
and also features on Android 12.
You can also filter this list based on categories and types.
I'd recommend giving it a read to make sure that your apps and you
are prepared for the changes in Android 12.
I hope you find them beneficial and easy to adapt to.
That’s it for me, and thanks a lot for watching.