[MUSIC PLAYING]
DAN GALPIN: Hi.
I'm Dan.
ASH NOHE: And I'm Ash.
DAN GALPIN: And we're going to talk about the future.
We don't know exactly what it'll bring,
but we can do our best to be ready for it.
ASH NOHE: Seamless interoperability
means that apps work great together and across devices,
leveraging Android's multitasking capabilities
and resource management.
DAN GALPIN: Privacy and security have always
been a core part of Android's mission, built
on the foundation of app sandboxing, open source
code, and open app development.
And we're continuing to advance the state of the art.
ASH NOHE: Personalization is at the heart of everything
we do, allowing the Android experience to best adapt
to the needs and wants of your users.
DAN GALPIN: Finally, device hardware keeps evolving,
and users expect apps to take advantage of it.
With all of that in mind, we're going
to be walking through how to future-proof your Android
development, given what we know from past Android
releases and Android 14.
ASH NOHE: Making apps work well together
involves how they share resources,
how you can move data between them, and much more.
DAN GALPIN: So let's talk about the future of running stuff
in the background.
We have this super simple flow chart.
That can help visualize when you can and should
use different methods of running work in the background.
It's not inclusive of every use case.
First, check to see if there's a purpose-built API for your use
case and use those when possible.
More on this later.
Then if the user initiates the work in the app's UI
is likely to care about what's happening,
can control whether the work continues, and the work matches
one of Android's service types, you just
might want to use a foreground service.
Examples include navigation, media playback,
audio recording, or workout tracking.
Otherwise, most of the time, use WorkManager.
Here are the foreground service types known to Android 14.
Service permissions and some of the types are new.
Apps that target Android 14 need to declare foreground service
permissions based on the foreground
service types they use in addition to the core foreground
service permission from API 28.
Android enforces foreground service types
with runtime requirements such as holding a location runtime
permission for foreground services of type location.
Here's a manifest snippet for a health and/or location service.
We declare normal, non-runtime permissions for both types,
and then we set the type to be health plus location.
The service can be started as any combination of these types,
and must satisfy any runtime requirements for all types
it started as.
Short service is a new type of foreground service from Android
14 that only requires the core foreground service permissions.
It's for those times when you have
to do something relatively short lived
and critical that doesn't match the foreground service
criteria, giving your app a much better chance of completing
critical tasks before its task is killed,
or placed into a cached state.
A cached state occurs after your app no longer
has an active Android component, such as an activity, job,
or service.
Also in Android 14, once your app
is moved into a cached state, within seconds,
it won't get CPU time.
And any broadcast that it has dynamically registered for
may be queued and/or merged when delivered.
And this is how things already work on some devices out there,
but now it's standard platform behavior.
There are many cases where you might have needed a foreground
service in the past to keep your app active,
where we now have purpose-built APIs such as the Companion
Device Manager, picture in picture,
chat bubbles, digital car keys, and the ability
to start Bluetooth scanning with appending intent,
and we're doing more.
For example, Android 14 adds support for user-initiated data
transfer jobs that can be scheduled with constraints.
They require a notification when active.
When internet access goes away, our job stops,
and we've chosen to hide the notification.
When internet access is restored,
our data transfer job continues.
In another new example of purpose-built APIs,
we're releasing a new Jetpack library
that supports call-related background work,
simplifies the telecom stack API service,
and brings backwards compatibility
for newly-released features.
It includes support for seamless audio switching and routing,
and call transfer for VoIP apps, leveraging
the cross-device SDK.
More on that later.
Also, if you absolutely need to do something at a precise time,
exact alarms are how to do it, but they're probably
not the solution you're looking for to get your app
to do stuff in the background.
They're expensive in terms of battery life,
and therefore have restricted use cases, even more so
in Android 14.
And periodic work has many advantages in terms of control.
Making apps work well together means a lot of things.
It's how they share resources, how you can move data
between them, and much more.
ASH NOHE: To summarize, look for purpose-built APIs
and use WorkManager for most other use cases.
DAN GALPIN: There can be magical moments when your devices all
work together.
The cross-device SDK exits preview this summer,
so you can launch cross-device features.
You can use the SDK to build personal experiences,
like the way the Jetpack telephony API uses
the cross-device SDK to transfer a VoIP call from your phone
to a tablet or a communal one, like placing a group food order
or sharing a Maps location with your cycling buddies.
It abstracts wireless technologies such as Bluetooth,
Wi-Fi, and ultra-wideband to create sessions that span
devices.
We're building a network simulator
to help test your cross-device creation that
includes features such as changes in device
position and packet loss.
ASH NOHE: I'm back to talk about migrating to Predictive Back.
Android 10 introduced gesture navigation,
enabling users to swipe to navigate their phone
instead of using buttons.
Predictive Back improved gesture navigation in Android 13,
giving a preview of where users are going as they swipe back.
Android 14 adds in-app predictive animations.
Here you see Reddit prototyping our Alpha APIs.
DAN GALPIN: Well, that's cool looking, but why would
someone want to integrate Predictive Back?
ASH NOHE: The Back-to-Home animation not only
feels more premium, it can significantly
reduce users accidentally leaving apps.
The cross-activity animation that you see here with Spotify
helps users navigate between two activities in your app,
and your app will come to life with predictive animations
in five new Material Android components.
See the What's New in Material Design talk to learn more.
There are two common migration paths.
If your app does not intercept back events,
all you need to do to get out-of-the-box,
predictive animations in your app is to upgrade your Android
X activity dependency to the latest stable version and opt
into the animations in the Android manifest.
If your app does intercept back events,
you'll also want to stop using KEYCODE_BACK, or onBackPressed.
Instead, use BackHandler with Compose
or onBackPressedCallback with its dispatcher for views.
Here are four tips for implementing BackHandler
or onBackPressedCallback.
First, determine the UI state that enables or disables
each callback.
In this Compose example, we observe the state of our text
field in onValueChange.
And when the text is not empty, we
enable BackHandler to handle the back event.
Second, use the new predictive back callbacks for UI logic
that changes UI state, such as showing a dialog
or running an animation.
For example, if you've been using the no longer supported
onBackPress method to log back events,
moving this logic to the new callbacks
disables the predictive animations
and makes your code responsible for navigation.
Instead, don't create callbacks for logic like this.
Consider logging within the activity or fragment
lifecycle instead.
Third, create single responsibility callbacks.
This means one callback per animation or functionality.
This is possible because you can create multiple callbacks.
The callbacks are added to a stack.
The last added enabled callback will
handle the next back gesture, with one callback
per back gesture.
DAN GALPIN: Your call stack looks delicious.
ASH NOHE: Unlike callbacks, the analogy
has multiple responsibilities.
Last, on Android 14, you can run animations
within callbacks for your app's key moments.
A key moment Reddit is prototyping
is collapsing the post as we swipe back to the feed.
Google Chrome is also prototyping
previewing the previous web page as we swipe back.
This is possible because of onBackPressedCallback's
new methods, including handleOnBackProgressed.
The BackEvent determines the edge the user is swiping from
and the progress of the back gesture as the user
swipes back.
DAN GALPIN: But what if our app has
lots of places that need to be modified to include
Predictive Back?
ASH NOHE: In Android 14, you can opt in individual activities
to focus on migrating the journeys that are most
important to your app first.
That wraps up Predictive Back.
See our I/O video from last year and our two developer guides
to learn more.
And now back to Dan and the future of privacy and security.
DAN GALPIN: The future of privacy
is all about designing for safety.
And we have a Privacy Codelab to help
your existing app integrate privacy best practices.
In the spirit of designing for safety,
here are just some of the privacy-related features we've
added to Android recently.
And Android 14 continues this trend
with features such as safety labels and permissions,
as well as empowering users to grant apps
access to selected media when they request media permissions.
Google Play requires new apps and app updates
to target recent SDK versions to maximize privacy and security.
It's why, starting with Android 14,
apps with a target SDK version lower than 23
can't be installed.
Also, make sure SDKs you use target recent SDK versions
and use data auditing APIs to give you transparency
into private data your SDKs might be accessing.
What's New in Android Privacy and Security
covers the Android 14 privacy and security changes in detail,
as well as common issues apps have.
If you use or build Ad Services, the Privacy Sandbox talk
has everything you need to work with privacy-preserving ads
technology.
And if you generate and/or use health data,
learn how Health Connect allows for apps and services
to share health data with privacy and data controls.
Allowing a user to seamlessly transition
to a new device in a secure privacy-preserving way
is important in retaining users.
And Android 12 changed backups for the better,
allowing for separate configuration
for cloud backups versus device-to-device backups,
while still supporting the legacy key value pair ones.
ASH NOHE: Does testing this require wiping devices?
DAN GALPIN: Well, that's one way of testing it.
But using some simple shell scripts,
you can test all three backup types
without having to reset devices.
These scripts call into the backup manager from ADB
to initialize and create a backup of the requested type,
uninstall and reinstall the app, and then clean up
and return things back to normal.
The Android developer site has much more,
including how to troubleshoot exceeded quotas and timeouts
in the testing backup topic.
Restoring user credentials is key
when a user transitions to a new device
and the new Jetpack Credential Manager API
supports passwordless authentication with passkeys,
the future of sign-in, as well as
legacy methods of authentication to simplify
restoring account information and authenticating new users.
The talk on passkey support covers it all.
ASH NOHE: Android has always allowed users
to customize their experience, and your apps can help.
Start by getting your app onto the most important phone
real estate.
Refresh your widget to increase the chance users
will add it to their home screens.
Jetpack Glance, now in beta, simplifies the development
of widgets using Compose's declarative syntax
to abstract the complexities of working directly
with remote views.
Take this weather widget, for example.
With Glance, we can partition the UI
into discrete composables.
And this talk has more guidance on building great widgets.
DAN GALPIN: Ooh, pretty.
How can I get my app icon to do that?
ASH NOHE: You can create a themed app icon.
In your existing adaptive icon XML,
you'll see background and foreground layers.
To add support for themed app icons,
add a third monochrome layer that points to a drawable.
If your app icon is already simple,
your monochrome and foreground drawables can be the same.
The new Android Studio tooling in Flamingo and above previews
what your themed app icon will look like and you're done.
Our team has also added new icon design-focused resources,
a Figma template and codelab.
Android 14 improves per app preferences.
Android 13 offered a central place for multilingual users
to set preferred app languages in device settings.
To support this feature, you previously
created and maintained a file that listed out
every locale your app supports.
Now we can generate this file for you.
All you need to do is use Android Studio
Giraffe or above, upgrade your Android Gradle plugin,
tell us what your app's default locale is in,
opt in, and remove the file you may have manually created.
The user sees a list of languages
your app supports within their device settings,
but now with less work.
DAN GALPIN: That's a lot of languages.
Can we customize it?
ASH NOHE: Yep.
You can customize a set of languages users see.
Say you would like to A/B test supporting Bengali
before rolling Bengali out to most users.
In this case, one group of users will receive Bengali
as a selectable language and another group will not.
Using a backend like Firebase Remote Config
lets us change aspects of our app's server side
like the list of languages.
We then use LocaleManager to override the LocaleConfig
with the language tags we receive from the server.
Also, for user customization of regional preferences
such as temperature, or days of the week,
see the new backward compatible LocalePreferences library.
The new Grammatical Inflection API in Android 14
helps create a personalized UI for all users.
3 billion people speak a gendered language
in which words inflect, or change
according to the gender of the person being referred to.
The default inflection is often masculine,
but this may feel less relatable to some users.
According to experts, a gender-inflected UI
respects all genders and may improve
users comprehension, engagement, and preference to your app.
A gender-inflected UI is useful in much of the world
and is particularly important for users living in the darker
colored regions on this map.
In Android 14, use the Grammatical Inflection API
to create new gender-qualified string
resources such as feminine, masculine, and neuter
alternatives.
Then use the Grammatical Inflection Manager
to set the application to the correct grammatical gender
for your user.
DAN GALPIN: Finally, make sure your app experience can
be personalized to meet users' accessibility needs.
Android 14 adds non-linear font scaling,
which scales up larger text more slowly than hard
to read small text in response to user preferences, which
means you should avoid static SP calculations
and make sure to use the TypedValue methods to convert
between SP and PX.
And the What's New in Android accessibility talk
has more of what we're doing in all of these areas.
App Actions enable voice commands
from Google Assistant to deep link
into the most interesting and useful points in your app
and makes your app that much more accessible in the process.
And while you're thinking about deep linking,
Android app links allow your mobile website
to immediately open the richer, more engaging content
in your Android app.
The deep linking talk covers the basics
of creating, testing, and troubleshooting Android app
links.
There's lots that we just don't know
about the future of hardware.
ASH NOHE: But one thing that history
has shown us is that many features that were once premium
only became mainstream.
DAN GALPIN: Premium devices have HDR displays
that can display more colors with more contrast.
And they typically have camera hardware
that can capture video and images in formats
that utilize these displays.
HDR images are new to Android 14 and use a separate gain
map to preserve the enhanced colors from the camera
hardware.
You can opt your activity into displaying HDR images
by specifying a manifest entry for your activity,
or by dynamically setting the color mode for your activity
window.
The Android HDR format extends JPEG in a backwards compatible
way so the work of decoding and displaying these images
is largely done for you.
Image processing pipelines will have
to take this format into account, however.
Check out the talk on building premium camera experiences,
which covers capturing HDR video,
optimizing for stream use cases, such as video calling,
video recording, or still image capture.
And the rest of the premium media story
is covered in the High-Quality Media Experiences
talk, which covers how to use the Transformer
API to transcode video along with spatial audio, Media3,
and video streaming and editing.
More and more premium devices are devices that transform.
And hardware manufacturers are coming up with new ways
to give users devices with larger displays that
are pocketable.
With larger screens, users are expecting devices
to be productivity machines compatible with different input
sources like stylus, touchpad, mouse, and keyboard.
And Android 14 adds automatic layout configuration
for keyboards, improved touchpad gesture
detection, advanced stylus motion prediction, and more.
So expect more users to have these input devices.
And if you want to support drawing, particularly
with a stylus, the low-latency Jetpack library
is the way to go, supporting front buffered rendering
when hardware supports it.
This talk covers input as well as
user interface and multitasking for large screens.
In the near future, Android is moving
towards having 64-bit-only devices.
Hybrid devices that support 32-bit and 64-bit code
are going away soon.
And in the future, expect to only see 64-bit devices.
For more information on how to test your app,
information on potential incompatibilities and more,
watch Keep Your App from Failing in a 64-bit-only World.
As hardware gets more capable, our devices
are going to get smarter with the use of on-device ML.
ML Kit provides turnkey features such as barcode scanning,
translation, and smart replies.
Face Mesh is in beta and document scanner
is coming soon.
The Acceleration Service runs an on-device benchmark
with your model and data sample, returning a hardware
configuration recommendation that you
can apply to your TensorFlow Lite interpreter.
It supports inference on CPUs and GPUs today,
and the future plan is to add more core types.
The on-device machine learning talk
has lots more detail on hardware acceleration, ML Kit, and more.
And that brings us to the end of our talk.
Building for the future means building responsibly,
considering system health, interoperability, privacy,
and security.
ASH NOHE: It means working for more personal, adaptable
Android.
DAN GALPIN: And it means taking advantage of the hardware
and software innovation in premium devices
today, which will likely be the hardware in mainstream devices
tomorrow.
ASH NOHE: There's one last thing.
DAN GALPIN: There's always one last thing.
ASH NOHE: Ultimately what we're advocating in this talk
falls under three of the key pillars in Google Play's
new Quality Framework.
To learn more about these pillars and the rest,
check out What Great Quality Looks Like on Google Play.
Thank you.
DAN GALPIN: Thank you.
And I'm curiously hungry for pancakes.
ASH NOHE: Nice callback.
[MUSIC PLAYING]