Hi, my name is Yigit Boyar and I'm a Technical Lead on Android.
Today, we'll talk about what is new in Jetpack.
Android Jetpack is a suite of libraries
to help developers write high-quality apps more easily.
These libraries help you follow best practices,
free you from writing boilerplate code and accommodate your application
across operating system versions,
so that you can focus on the code you care about.
Since its launch, Jetpack has seen a high amount of adoption
across many of the top Android applications.
47% of the top 1,000 apps use two or more Jetpack libraries
and that number doesn't even include
core libraries like AppCompat or Lifecycle.
We are excited about the growth we have seen
and the incredible feedback we've received from the community.
Thank you.
We have done a lot of work over the past year.
We have new libraries launching today
that will make it easier to write better apps
and we have also made major additions to existing libraries
to expand their scope.
There's a lot to cover so let's get started.
First up, Hilt.
Hilt is Jetpack's recommended dependency injection library.
Dependency injection is a technique widely used in programming
and well-suited to Android developments.
But dependencies are provided to a class
instead of the class straight in itself.
This helps reduce coupling in your code base.
By using dependency injection,
you get better code reusability due
to the coupling between components, and testing becomes easier
since your class dependencies are well-defined.
Moreover, in the latest Android Developer Benchmark Survey,
49% of the workers asked us to work on a dependency injection solution.
So we have teamed up with the Dagger Team to create Hilt.
Dagger's a dependency injection library developed by Google,
and is widely adopted in the top Android apps.
However, getting started with Dagger on Android,
has a steep learning curve.
Hence, we have created Hilt.
Hilt is an opinionated dependency injection library
specifically built for Android on top of Dagger.
While using Hilt, you annotate your fragments
with the
And now, you can use the
to inject your dependencies.
You can also use the
in other Android components like activities or services.
Finally, you need to annotate your
with the
so that Hilt can create the dependency graph for your application.
Thanks to the tight integration between Jetpack libraries and Hilt,
your remodels can also be injected automatically.
All you need to do is to annotate your ViewModel constructor
with the
we should ask Hilt to inject it.
Because Hilt is designed for Android,
it knows what the ViewModel is, its scope, etc.
So it does the right things by default.
If a dependency you want to provide needs more menu setup,
you can create a Dagger module with the installing annotation
and Hilt will discover it automatically.
With
provided by your module.
Hilt comes with predefined scopes for Android,
so you don't need to define your own for the common cases.
We have seen great results from integrating Hilt into our applications.
We have replaced Dagger with Hilt in the Google I/O application
and we were able to delete 75% of the dependency injection code.
I know it sounds too good to be true, but it is true, go check it out.
Hilt not only reduces the code unit right
but also reduces the mental load to get started.
It also scales very well with your application
as is already used by major Google Apps like YouTube.
To recap, Hilt is the new recommended Jetpack dependency injection library.
It's built on top of already proven Dagger,
it has integrations with ViewModels, Fragments and WorkManager,
it has well defined scopes for Android, and my favorite part,
it also has out of the box testing APIs
so you can replace your dependencies
per test with support for both integration
and robolectric tests.
Last but not least, it has Android Studio Integration
for a more delightful developer experience.
It's available as Alpha today
and we have even created a Cheat Sheet for you to quickly get started.
Check it out and let us know what you think.
Next, another new library, App Startup.
Performance is important for us,
that's why today we are also launching the Alpha
of our AndroidX startup library.
As you add more labels to your application
that wants to run some initialization code on App Startup,
it has a negative impact on your launch performance.
Most of these libraries use Content Providers
to initialize automatically,
including some Jetpack libraries like WorkManager and Lifecycle.
We have analyzed the cost of creating Content Providers
and each of them adds at least two milliseconds on a pixel
to a device running Android 10.
This is just the cost of Content Providers not the work library does.
The App Startup library provides a straightforward and performant way
to initialize components at application startup
by avoiding a separate Content Provider for each library.
Here is an example of an initializer component
that configures WorkManager.
It extends the initializer API specifying its type,
and when
it simply initializes WorkManager and returns the instance.
Alternatively, the initializer component can also define its dependencies
so that the startup library will initialize dependencies
before initializing our component.
Under the hood, the startup library uses a single content provider
shared between all these initializers reducing the application startup time.
So the App Startup library can be used by
to streamline startup.
It supports lazy initialization
to further improve Application Startup performance
by completely avoiding the Content Provider.
It automatically adds
This way you know the true cost of components being initialized
at application launch using tools like Systrace and Perfetto.
It's available as offered today,
try it out and see how your app launch performance improves.
Moving on to the Android Game SDK.
To make game development easier,
we have launched the Android Game SDK earlier this year.
It includes a set of libraries
that are designed to help you improve your game performance across devices.
It has been available on the Android website
and now is part of the Jetpack family,
and also available on Google's Maven repository.
The SDK currently contains two important modules.
The frame pacing API allows games to maintain a steady frame rate
and can lower a game's input latency.
The library detects the expected frame rate
and auto adjusts frame presentation times accordingly.
Android Performance Tuner
enables you to measure and optimize frame rate at scale.
By integrating it with your game,
you get near performance inside Android vitals
designed specifically for game developers.
It's available as Alpha on the Google Play Maven Repository.
As you can see, performance is important for us,
and we are not just focusing on game performance,
but we are also investing in tools for application developers.
Today we have a new Alpha release for the Benchmarking library.
It integrates with the CPU profiler so that you can profile your benchmarks,
and then weave the method,
or sample trace it right in Android studio.
We have also added support for memory allocation tracking
so that you can optimize the time spent for allocations
and reduce a lot on garbage collection.
Next, Paging 3.
Paging is a library that helps you load
and display small chunks of data incrementally.
Today, we are shipping Paging 3,
completely right off the library using Kotlin Coroutines
and adds highly requested features like separators.
Here is how it looks.
This is the heart of the Paging, where we connect at our back end.
We extend this
which is a single method that we need implemented.
Here we call our API to get the result and return the page.
If something goes wrong, we return an error result
to notify Paging that an expected error has happened.
Once you have the
provide with the configuration of our page size,
and get the flow out of it.
Finally, in the UI layer, we collect from this flow
and pass the values into our paging adapter.
The adapter will take care of displaying the data for us.
To recap, Paging is rewritten from the ground up
with Kotlin Coroutines & Flow.
It has built-in API so at headers, footers or separators.
You can even do other transformations like mapping items or filtering them.
It adds new APIs, to observe the Loading State
and has metas to Retry or Refresh.
Last but not least, Paging 3 is fully backwards compatible with Paging 2
to help you migrate easily.
It is available as Alpha now,
please check it out and let us know what you think.
We're really excited about our first Kotlin Coroutines library.
Let's move into a library that I wish existed
when I was working on apps, CameraX.
Creating real time filters 6, 7 years ago, was not fun at all.
CameraX is a Jetpack library that makes integrating camera
into your application very easy and reliable.
It reached Beta last February,
and we are focusing on reliability and better documentation
before reaching the stable version.
CameraX runs on 90% of Android devices, which means, there is a lot of variety
in terms of performance and feature set.
To make sure CameraX works well,
our Test Lab runs our automated test suite on both low end and high end devices
that cover over 400 million active devices in use.
This means you can spend more time on your application
rather than accounting for different devices in your codebase.
PreviewView is a widget that displays the camera preview in your application.
It now handles interactions with your application lifecycle
and via pages reliably.
It's also optimized so transparently your surface view
under the hood on devices
that will benefit from its performance enhancements.
This provides less buffering and better power efficiency.
We are also focused on providing more guidance
to make it easier to use CameraX.
We added the sample for YUV to RGB conversion
to do image analysis in a more familiar format
so that you can easily integrate it with libraries like in AppKit.
We have created although other samples as well,
including OpenGL and rotation handling.
So take a look at
Next, WorkManager.
WorkManager is the Jetpack library
that allows you to run deferrable background jobs
like sending your very important email
when the user is connected to the Internet.
Here are some highlights from the 2.3 and 2.4 releases.
WorkManager doesn't only rely on JobScheduler to execute your jobs,
it also has an in-process scheduler trying your workers
and we have greatly improved it this year.
It now supports delayed workers and periodic work requests.
The scheduler also no longer imposes scheduling limits,
which improves the throughput of your work requests.
WorkManager now supports long-running or important work
that should be kept alive by the operating system.
Here's an example of a worker that uses the Coroutines API
provided by WorkManager.
When the worker starts,
we can call the
with a notification to display to the user.
Finally, we do the actual work and return as usual.
WorkManager will take care of this using the service for us.
Because we are using a foreground service,
this worker can run longer than the usual 10 minute limit.
Keep in mind though, this API requires it to show a notification to the user
so use it sparingly.
Let's look at another improvement to WorkManager, Diagnostics.
Sometimes it's hard to know why a worker didn't run
when you expected it to run.
For those cases,
we have the new Diagnostics API that you can invoke with ADB
to peek into the internal state of WorkManager.
When invoked, WorkManager will dump its current state into
which we can simply view via an
As WorkManager is adopted by applications, we identify some common mistakes.
We have added lead roles to catch these
so the Studio can immediately inform you
if that happens in your codebase.
Here's an example where we made the worker class private by mistake.
If you do this, Studio will quickly warn you
that the worker needs to be public.
I mean, I know you don't write bugs,
but this is for the other people watching the video.
That was all with WorkManager, let's talk about Navigation.
The Navigation library allows you
to navigate between different screens of your application with ease
while also following Android UI principles.
In Navigation 2.3,
we have added support for dynamic feature modules,
which allows you to download pieces of your application
as the user needs it.
This can significantly reduce
the initial download size of your application.
Thanks to the integration with the Navigation component,
you can navigate to these modules as if they're part of your base APK.
All you need to do is to annotate your fragments with the module name.
Navigation library will take care of downloading it if necessary
before moving to that screen.
In addition, we have made lots of improvements
to the Deep Linking feature in Navigation.
You can now access query parameters, provide custom actions
and specify mime types.
I remember writing Deep Linking support manually
where you had to carry over information on multiple screens
to go to the right place.
That was no fun.
With Navigation, it is just one parameter in the graph
and always taken care of for me.
I love it.
And last but not least, my favorite new feature,
Let's take a look at it.
In Navigation 2.3, now each screen
in your application has a
which gives you access to the same state of that entry as well.
To ensure your results are kept over configuration changes
or process that
Navigation uses the
Your fragments can access the previous fragment
by using the previous
Once you obtain the
you can set the result values on the SavedState.
To observe the result, you can get the same value
from the SavedState of the
and observe the value without live data.
This way, observation is Lifecycle aware.
And because we are using SavedState,
it works even if your application's restarted between these two screens.
So that was the new Result API in Navigation.
It's actually part of a bigger old hull
of the APIs related to passing data between screens and applications.
We know there have been many changes recently
in terms of permissions on Android and we wanted to make it easier.
This new API which we call
makes asking for permissions super easy
as well as many other common tasks like taking a picture.
Let's take a look at an example of how you can ask for permissions
using the new Contracts API.
First, we register for an activity result
and specify that you want to use the
We also need to provide a callback
that will be called with the result of the permission request.
Later, when we want to ask for the permission,
all we need to do is to launch the function
that was returned from
with the parameters.
When it's result, it will call the callback we are provided.
If you want to obtain multiple permissions at once,
there is also a request multiple permissions contract
that you can use.
There are more contracts available like asking user take a picture,
query contents from a URI or Open Documents.
Check out the Activity Results Contracts API for more.
On to our most popular library, AppCompat.
AppCompat provides backports for a wide variety of UI elements
and platform features from the material theme Dark Mode.
Because some of the functionality from the framework
is duplicated into AppCompat,
it might be difficult to figure out which attribute you should use.
To help you make most of the library,
we have added a set of library-specific Lint Rules.
For example, here is a layout I've used the drawable start attribute
to set a drawable on the textview.
If you open this code in Studio, it will immediately show you a warning
and ask you to replace it with the more full-featured version
of the same attribute available in AppCompat.
We have also made substantial improvements to AppCompat's
implementation of the Dark Theme.
And to make sure you can still customize your theme,
we have added a configuration overrides API.
For instance, if you wanted to specify a custom locale for your activity,
you can override the
and create a new configuration which you can configure as you please.
Afterwards, you should create a new context
as a combination of the existing context plus the custom configuration.
Finally, you should delegate to the
so that the new context is used across activity.
Speaking of Dark Theme,
Jetpack's Webkit library has a new API in 1.2.0 release
to forced dark mode for its contents.
When enabled, the WebView will render size
and Dark Theme are supported or forcibly in more certain colors
if the website doesn't support Dark Mode.
Wow! We have covered a lot in this video.
These are just some of the highlights that we think you should know about.
But that's not even everything,
where there is more in our
You will find lists of documentation, samples and other features
that we weren't able to cover today.
We are excited to hear more from you and what you think on these new APIs.
Try them out and take advantage of the best of Jetpack.
Thank you.