[MUSIC PLAYING]
DANIEL GALPIN: Hello and good morning, and I'm Dan Galpin.
And according to a recent Google Search that I did,
it turns out that there are lots of things that people are
scared of, things like airplanes and flying and snakes
and spiders and going to the dentist and public speaking,
and even the number 13 for those triskaidekaphobics out there.
But a new release of Android is nothing to fear,
even if it is the 13th release.
So I'm going to cover two things in this talk--
the basic process for dealing with migrating to a new Android
platform release along with how this applies to Android 13,
specifically in terms of the changes it brings
and how they might apply to your app,
and how to dig deeper into this content with other ADS talks.
Remember, there are three kinds of people,
those who can count and those who cannot.
When migrating to a new Android release,
I look for behavior changes and new features
that I can potentially utilize to differentiate my app.
And behavior change really is a big deal
because it means that this app that worked fine
on earlier releases of Android may not
work exactly the way that you expect
them to on this new release.
So for that reason, we really try
to limit these kinds of changes to things that impact system
health and focus on battery life and system performance, things
like user privacy and the security
of the OS and your app.
Now, some of these changes apply to all apps, and some of them
only apply once your target SDK version actually targets
Android 13's API level 33.
So the first line of defense is to test your app thoroughly
on the new release, and this just means Android 13.
And it's available in many places, such as the Android
Emulator, the supported Pixel devices, partner devices,
and things like the Firebase Test lab.
And the Behavior Changes page on developer.android.com
is a guide for what to focus on.
And I'll be covering some of the more notable changes
in this talk, beginning with changes
that impact all apps, regardless of their target SDK version.
And the over goal of these changes
is to give the user more awareness and control
of what apps are doing in the background.
Now, users told us that they really, really
wanted foreground service notifications to be
dismissable, so we added that.
To then provide more clarity around what apps
are doing in the background, we created the Foreground Services
Task Manager.
And if your app is using a foreground service,
it gets included in this new interface that allows the user
to end the foreground service, which also closes your app.
You can use ADB for testing to stop your app exactly the way
the FGS Task Manager is using this stop-app command.
And in many ways, this is really similar
to the force-stop command, which you
can do from the App Info page or from the force-stop ADB shell
interface.
Unlike force-stop though, it doesn't actually
remove the app from history, and it
doesn't cancel scheduled jobs and alarms,
so this should actually be easier
and have less of a long-term impact on your app.
Now, when your app is stopped in the FGS Task Manager,
you won't get any callbacks in the system,
but you can check what happens the next time your app starts
using the application exitInfo API.
And this will tell you if the user stopped your app
and allows you to check for things
like crashes and ANRs, on-handled exceptions,
and low memory.
And there are two takeaways from this for me.
First, as always, make sure your app
can handle being stopped at any state, minimizing data loss.
Second, this is a really good time to do some analysis
and see if you really need to rely on foreground services
because foreground services really
reduce the flexibility for Android
to be able to schedule things.
And using jobs is just better for the system health.
And speaking of background activity, on Android 13,
your app requires a much shorter period
of inactivity to be replaced in the restricted app
standby bucket.
We added these in Android 12.
And when you're in restricted mode,
you can run jobs once per day in a 10-minute batched session,
which must be run with at least one other job.
You can run fewer expedited jobs,
and you can invoke one alarm per day.
So if your apt detects that it's in restricted mode,
you can help make sure your app schedules
any necessary operations appropriately.
And it's at least worth logging what state
your app is in when you're running jobs and alarms so you
can help track down any unanticipated behavior.
Now, you can use ADB to test your app standby bucket
if you want to run some long-term tests.
But note that your app can't actually
be running because if you try to actually execute this
while your app is running, the app will actually say,
hey, I'm being interacted with, and it will automatically
kick itself out of this restricted bucket.
Now, one of the ways to get users to interact with your app
and keep it out of those restricted buckets
is to get users to send them relevant actionable
notifications that they interact with.
But Android 13 now requires you to hold a permission in order
to do that.
And Android asks for this permission on your behalf
if you haven't yet targeted SDK 33.
And it does this as soon as your app has an active activity
and has created the notification channel.
This is different than every other time we have introduced
a runtime permission.
Now, if the user disallows this permission,
they won't be prompted again unless they uninstall
and reinstall your app or you upgrade your app
to target SDK 33.
Now, if your app does target SDK 33 or higher,
you get to manually ask the user for the notifications
permission, and so you have complete control
over when the permission dialog is displayed.
You can call areNotificationsEnabled,
which is an AndroidX function, to confirm
whether notifications are actually enabled for your app.
And notifications related to media sessions that
are exempt from this behavior change,
but in general, the foreground service notifications are not.
You can use ADB to revoke permission flags
and permissions and clear permission flags for testing.
And be sure to catch Terence and Nate's talk coming up
for best practices on requesting permissions,
including the new notification permission.
So we also have behavior changes that
are related to privacy and security, as I stated before,
and we've locked down intent filters
to behave more like I always thought they did.
So on Android 13, when your app sends an explicit intent
to an exported component of another app that
targets SDK 33 or higher, the intent
is delivered only if it actually matches the intent folder
element in the receiving app.
And so if your app has been relying
on this legacy behavior, you'll have to fix things.
If your app has a centralized handler for exported
as well as non-exported intents, adding a little bit of code
to your receiver to filter out disallowed
actions can prevent an external app from unexpectedly
triggering internal code.
And this is something you should do as soon as possible,
even if you aren't ready to target SDK 33.
We've removed the compatibility trampoline
for the speech service from the Google search app in Android 13
to use the device's default provider.
Basically, this means don't specify a component name
in the recognizer intent.
Android 13 now has a handy pop-up
that provides a visual confirmation of clipboard
contents.
So we've added a way to prevent sensitive data,
such as passwords or credit card information,
from getting shown if copied to the clipboard.
And this is also something worth doing as soon as possible,
regardless of what SDK version you target.
Android 13's SDA does give you a string constant.
You can just use this one.
Finally, if you're relying on shared user IDs, which
is a really cool feature, but it has
problems with package managers, so please
migrate to supported communications mechanisms.
And since removing the shared user ID from your manifest
also prevents your app from ever getting updated,
we've added this way to migrate, so it's only not
used on new installs.
And that's really most of what you
need to know about behavior changes
for apps that are not targeting SDK 33.
But if notifications are actually important to your app
and what it does, you probably want
to target SDK 33 as soon as possible.
Then you can request permission in context, in justification.
And so you also have to do this by November of 2023
in order to continue making app updates on Google Play,
so you might as well just get started now.
So what behavior changes also happen when you target SDK 33?
And this is typically where we put more substantial changes
since targeting the SDK version implies
that your app has actually been tested against that version.
So let's start with privacy and security-related changes.
And here's actually a nice one.
So on earlier versions of Android,
the user needs to grant your app access
to fine location for some common Wi-Fi use cases,
but on Android 13, we introduced the nearby Wi-Fi devices
runtime permission in the nearby devices group.
So if you assert in your manifest
that you are not using your Wi-Fi access for location
and your app doesn't use methods from the Wi-Fi manager
class such as start, scan, and get scan results,
you can just use the nearby Wi-Fi devices permission.
However, this means that you'll actually
need to request the nearby Wi-Fi devices permission once you
target SDK 33.
Otherwise, accessing many Wi-Fi APIs
will cause an exception to be thrown.
Next, if your app needs to directly access
media files created by other apps, once you target SDG 33,
you need to request one or more of the granular media
permissions instead of the read external storage permission.
And it's even better to avoid these.
In everything about storage on Android,
your seed is covering key storage concepts
along with recent APIs that go even further
to preserve user privacy.
Targeting SDK 33 also means that you
have to request the new body-sensored background
permission and existing to the body sensors one
to actually get access to these body sensors in the background,
but it's also a hard restricted permission
that the package installer has to allow list.
So you should probably just use Health Connect
if you need to consume health and fitness data.
So Garen has a whole session on this.
With each new Android release, we
are trying to eliminate the calling of non-SDK interfaces,
and when it makes sense, we're trying
to replace these hidden APIs with public alternatives.
As you can see, there are only four in Android 13,
so I can put them all on a slide.
We have system health behavior changes
that only occur when targeting SDK 33 as well.
So once you target SDK 33, if your app gets in the restricted
state, the system doesn't deliver the boot completed
broadcast or the locked boot completed broadcast
until your app has been started for other reasons.
And to make it easier for you to test behavior changes,
we have this thing called the compatibility framework,
and it allows you to toggle on and off specific behavior
changes for your app without even changing your app,
so targetSdkVersion using either settings or ADB.
So you can test this particular one, for example,
by setting the deferred boot completed broadcast change
ID option.
And note that your app will never
get into the restricted state if the user adds your app
widget, so definitely, make sure to see
what Marcel has to say about modernizing your app widgets.
The rest of the behavior changes in Android 13
are more about improving the user experience.
So when targeting SDK 33, media controls are now
derived semantically from the playback state that's
linked to your media session, if available,
rather than displaying up to five controls from media
style in the order they were added.
And this not only provides for richer media controls,
it also aligns how they're rendered
across phones, tablets, Android auto, and Android TV.
For more on how to create a great media experience that
works well across various device hardware and platform versions,
check out Nevin's talk.
When targeting SDK 33, the setForceDark method in webview
is annoyed--
ignored, excuse me.
Webview now always [INAUDIBLE] the media query,
prefers color scheme according to the apps in light theme,
theme attribute.
And you can still customize your color theme behavior
using the set algorithmic darkening and loud method
in AndroidX.
Finally, apps that target SDK 33 or higher
that use advertising IDs need to request the ad
ID permission in the manifest.
So if you're using an advertising SDK that
targets SDK 33, it'll hopefully, do
this automatically in your library's manifest.
And this brings up one of the key things
you should look for when targeting a new Android SDK
release, which is the target SDK version of any SDKs
or libraries you might be using.
And this is particularly important
if you're using pre-compiled libraries
that target earlier SDKs because this can cause failures.
They haven't been modified to account for any recent behavior
changes.
And without source code, Android Studio
isn't going to warn you of any potential problems.
Now, you can use the Google Play SDK
Index to see what the target SDK level is
for many commercial SDKs.
So now, after all that, you're targeting Android 13
successfully.
Not much there really, but what's next?
Consider getting rid of your storage permissions
entirely and switching to the new Photo Picker API.
And this allows the user just to share specific photos
and videos with your app.
And it's a rich photo experience.
It's supported back to Android 11
using an SDK extension, which is the technology that
uses Google system updates with modular system components
to add functionality to an OS release.
And this helps us also to ensure a consistent experience
across devices.
Now, if the Photo Picker isn't available,
it falls back to using ACTION_OPEN_DOCUMENT.
And this works back to SDK 19, and it
has a less rich experience, but it's still pretty nice,
as you can see.
So using Photo Picker involves, first,
registering for an activity result callback,
and this selects whether you want
to allow single or multiple pieces of media.
And then you launch the Photo Picker
with the type of media you want the user to select--
images or videos or both.
And then you can call isPhotoPickerAvailable to check
for the presence of the full Photo Picker experience
if you want to provide something alternate.
Internally, isPhotoPickerAvailable
calls getExtensionVersion, and this is actually
how you check for the presence of an SDK extension at runtime.
So this is the future.
And if you're no longer using a runtime permission
like read external storage on Android 13,
your app can revoke it using the revokeSelfPermissionOnKill.
And this is pretty cool.
It's just a no op if your app doesn't already
hold the permission.
And if it does, the system will kill your process
opportunistically.
And the next time your app is launched,
the permission will no longer be held.
Speaking of privacy, Erin is covering the latest updates
to Privacy Sandbox, a project that
looks to enable effective, personalized advertising
while improving user privacy.
And this includes an overview of the project
and how ad tech providers, advertisers, publishers,
and app developers can utilize it.
Android 13 includes new graphics capabilities,
including programmable shader effects
and front-buffered rendering for low latency stylus support.
And Samir and Chet dive into this deeply into their Android
graphics talk.
Android 13 includes new communication capabilities,
such as MIDI 2.0, BLE Audio, ultra wideband,
along with new media capabilities such as HDR
video recording, anticipatory audio routing,
and spatial audio.
And Luke covers what new capabilities BLE Audio
brings to the platform, as well as how to make use of it
in your VoIP applications with the telecom API.
Carlos gives an introduction to ultra wideband, a radio
technology that can provide secure and accurate
proximity data around nearby devices,
enabling digital car keys, new home control
possibilities, and more.
Ray covers how you can capture, playback, and share
HDR video, showing you how to test
for its availability in capture and playback
as well as how to transcode your video to SDR as needed
for sharing.
Android 13 also includes a bunch of new text features,
including Unicode updates and support for color vector
fonts in the COLR V1 format.
In addition to improved tech support
for internationalization, Android 13
now supports per-app language preferences.
Whether your app already has support for per-app languages
with an in-app language picker or whether you
want to add support for the feature,
the AppCompat APIs and AndroidX make
it easy to support Android 13, while being backwards
compatible back to Android 4.0.
For more on making your app work better
for more users, including more on per-app language
preferences, check out Ash's talk
on building for a multilingual world.
Speaking of making your app work for more users, Caren's talk
on how we built accessibility support for Jetpack Compose
covers the three most common accessibility services,
how Android integrates with them,
and how this informed the design of accessibility
in Compose, along with tooling and best practices.
Support for the new Tile Placement API
helps users customize their Android experience,
allowing apps to provide custom quick settings tiles
to prompt users to add the tile in one step
without leaving the app.
Android 13 also includes all of the enhancements for tablets
and foldables that are on Android 12L,
and this just gives users better support for their favorite form
factors.
Rebecca covers how you can go edge-to-edge with your app
on all form factors.
Take advantage of dynamic colors and Android 13's themed app
icons, and get your app ready for the future with support
for predictive back gestures.
So in conclusion, there are two things
that I would like to leave you with.
First, many of you will be able to migrate and target
SDK 33 with minimal changes.
So start testing your apps if you haven't already
because there is a lot of benefit
to targeting Android 13 and a bunch of cool stuff
to take advantage of.
And third, we've got so many in-depth talks coming
up shortly here at the Android Dev Summit Platform Day,
including how to make sure your app
is ready for 64-bit devices like Pixel 7,
the latest in hardware accelerated machine learning,
how to leverage attestation to improve
the security of your app ecosystem, how to leverage
the latest Google Play commerce features,
and the #AskAndroid session, where the Android platform
experts take your questions.
And sometimes, those scary things
can be cute and fuzzy when you examine them a bit closer.
Sometimes, at least.
So thank you.
[APPLAUSE]
[MUSIC PLAYING]