[MUSIC PLAYING]
CHET HAASE: Hey, everybody.
Welcome back to "Now in Android."
This is episode number 17.
Let's get into it.
So Android 11 developer preview 3 just
came out recently with a lot of improvements for debugging
and developers, which is good.
Turns out, I don't know about you,
but I occasionally write a bug, and it's
kind of nice to be able to actually debug that thing.
Hard thing to do, especially in the real world on user devices,
so we've come out with some new facilities
to make some of this stuff a little bit easier
for you along with a bunch of other developer features.
For example, wouldn't it be nice if you can actually
figure out what was going on the real world
when your app crashes?
So there are a couple of features
specifically about that.
First is a new API for querying information
about why did my app crash.
So you can find out after the fact.
You can basically get this data structure back,
a list of the reasons why your app exited,
and then you can upload those and take a look at that data.
Again, this is real world data so much more useful
than what you're going to get in a test
environment with very different devices
than your users might have.
Also, for NDK developers, we offer
something called GWP ASAN.
So in Android 10, we had this thing
called HW ASAN, hardware ASAN, which was hardware accelerated.
It catches memory problems, but it's
a little bit high overhead.
It was really meant for build and test environments,
development time stuff.
GWP ASAN, on the other hand, is intended for the real world.
In fact, we use it for the platform libraries ourselves.
It's a sampling-based thing where occasional allocations
will go through the system and be sanity checked
against validity, and this enables
us to, with very low overheads, both at runtime as well
as memory, catch problems that can
occur on real world, real user devices.
And when one of these problems occurs, it will be logged,
and it'll show up in your place to our dashboard.
So if you want to enable this, check out
information about GWP ASAN.
Wireless debugging-- so I think in these times of uncertainty,
we all want to grab onto the things that we can count on.
One of those things certainly is that there are never
enough USB ports.
Am I right?
So what we've done is enabled wireless debugging.
People have wanted this, I've wanted this for years
and years, and now it's here.
It's not yet in the tool, but it is in the command line.
So there is a way to access this through the command line
so that you can now actually talk to your device
without trying to figure out what dongle do I have somewhere
that I can plug in an external USB cable into my machine.
So check that out, and also check out 80 PADB,
incremental APK installation.
Far too many "a" acronyms in the Android universe,
don't you think.
So we have added a new tool, especially for large binaries,
to make it faster for you to install on a device.
Let's say you're building a game and you've
got a couple of gigabytes worth of data and code
and everything, and it takes a while
to install that every time you rebuild this onto your device.
Now, using this new process, you can install up to 10 times
faster.
So you need to sign your app differently,
and you need to use this updated ADP command line
tool that we have.
Also note that this only works on Pixel 4 and 4
XL for now because it required a low level file system change,
but the intention is that it will be on all devices that
actually ship with Android 11.
Data access auditing is a way for you
to find out what is going on in my app
with accessing data that requires user permissions.
Let's say you're working on a huge app.
You have tons of developers, or maybe you're
pulling in a bunch of external libraries
and you know that they are accessing--
that somewhere in your application,
you're accessing data that maybe you didn't intend.
And maybe you don't want to actually require
those permissions from the user.
Now can find out what's going on.
You can have these listeners and be called back
when these accesses happen.
You can find out what's happening
from that library in the portion of your code,
and you can do the right thing about it.
Jeremy Walker on our team has written a Kotlin sample.
And this teaches you how to use the API,
and it uses a nice example with a separate module
that is actually doing the access from there.
Apart from the main codes, you can see how this actually
works in the real world.
So check out the recent DP3 blog on the Android developers
blog for information about these and other features.
And certainly check out the developer preview site
for Android 11 for all of the information about all
of the features in Android 11.
And most importantly, test your app.
The whole reason we do previews and this really long cycle
of preview after preview after preview
is so that you have enough time to test your app
to, a, fix any problems you find in your app and, b, tell us
about any problems that you find in the platform
so that we have time to fix them before we
ship the final release.
A bunch of articles shipped in the last couple weeks,
including a CameraX preview article by Hussein Hakeem.
He wrote this article to show you how to use a simple preview
view in CameraX.
So instead of you managing surfaces, either surface
view or texture view directly and then dealing
with things like configuration and rotation
inside of this preview, just let CameraX handle it for you.
It gives you a view.
It's a custom view.
It manages the surface inside of there,
and you can do things like enable top
to focus or pinch zooming capability all without worrying
about the details of how this actually works under the hood.
Manuel Vivo wrote an article about Dagger in Android Studio.
There's a new feature in Android Studio 4.1 Canary
Builds that allows you to find out
more information about what's going on
at the dagger injection level.
So let's say you're in a function that is injected
from somewhere else.
You can click through and find out
where that injection is coming from,
or let's say you're in code that actually injects code
elsewhere.
Again, you can click through using this new tool facility
to find out the flow of all these injections
all over your code.
Murat Yener posted an article in the Kotlin Vocabulary Series
that shows you how to use the object--
object-- object keyword in Kotlin.
In the Java programming language,
we use statics and implement the common singleton pattern.
I only want one of these.
Then you use static.
And then there's a bunch of boilerplate code
to actually make that pattern work correctly.
There is no static in Kotlin.
Instead, we use object, and that both
declares as well as instantiates one of these objects.
And we use it for singleton pattern
but with a lot less boilerplate code.
And we also use it for anonymous inner classes.
And like the rest of the Kotlin vocabulary series,
Murat shows you how things work under the hood
by showing you the decompiled byte code
to see what's actually going on at the code level.
There is another article from Abraham,
who's on the engineering team for the low level graphic stuff
that we do on the platform, and he wrote an article
about dynamic refresh rate.
This is a capability that's coming out
in some modern devices, but we didn't have the platform
capability to support it yet, where
typically, for years and years and years, probably back
to the Middle Ages, phones, devices would only
support generally 60 Hertz, 60 frames a second,
which gives you about 16 milliseconds
to compute all the stuff that you need to compute
to actually render a frame and then frame, frame, frame,
frame.
Well, if you are writing an app like a game or another app that
has its own custom render--
not a typical UI app on Android but one of these custom
apps-- you've got your own renderer.
And let's say it's doing so much stuff
that you realize on a particular device,
you can't hit 60 frames a second.
You need to drop down.
Well, you can't just drop down to, like, 59,
and you don't want to drop down briefly
and drop back up, creating this discontinuous experience.
Instead you need to drop down to something
you can support continuously.
Well, the way refresh weights work
is that means you're dropping to 30 frames a second.
If you can't handle 60, you're going to be at 30.
With variable refresh rates, not only
can they go up to 90 and even 120 Hertz in some cases,
but they also support more rates that you can drop back off
of if you need to.
So check that out for information
about how to use that stuff, but more importantly for me,
check it out to learn more about how Android works.
Good description of what's going on
under the hood of the low level of the rendering
side of Android, which I always find interesting.
AndroidX had a bunch of releases, as they always do.
They come out every two weeks, and there's always
tons of releases.
This time most of the releases are incremental releases,
either in the beta or the alpha or the RC stages.
I wanted to call out a couple of the alpha releases
in particular.
For example, there's Navigation 2.3.0--
just came out with the alpha 06, a classic versioning.
And this offers a new Kotlin DSL for greeting navigation graphs
dynamically.
So typically you use the tool-- you use the nav graph
editor in Android Studio, which overlays the XML code.
You can sort of interchangeably use either one of those.
The Kotlin DSL allows you to programmatically
and dynamically create these navigation paths.
This is really useful, especially
for dynamic feature navigation.
So let's say you are using dynamic feature modules
and you want your app to navigate
to a module or a destination that actually hasn't even
been downloaded and installed yet,
then you can create that graph dynamically using this DSL.
Ben Weiss on the team created a new sample
to show how to do all this stuff,
and also there's a new guide to how to use the navigation DSL.
Also Fragment 1.3.0 alpha 04.
This is a new version that has the new Fragment Result API.
This is important because it takes
the place of a method that's now deprecated
called setTargetFragment.
But even better, there's a new guide
about how to pass data between fragments.
So check out all of that stuff for more information about how
to do this stuff best.
And then finally, there was another podcast
for Android Developers Backstage that
posted on one of my favorite topics, IME animations.
So I talked about this in a couple of these
now in Androids already, and now we
talked about it on the podcast.
We got together with Yoram Yagi, Adrian Roos, and Taran Singh
from the engineering team that does all the window
manager stuff, and they talked about how this stuff works
under the hood and how to use it to both listen to keyboard
animations and synchronize your content with those animations
or even to drive the keyboard animations directly.
And then one thing that came up on Twitter right
before I started recording this is the Android 11 Beta Launch
Show.
This is going to happen on June 3.
And go to g.co/Android11 to learn how you can tune
in to see what's going on there.
And finally, as always, all of the links for everything
that I talked about are on the article for Now in Android 17,
so check out the article for those.
And if you liked the video, go ahead
and like and share and subscribe to the Android Developers
Channel on YouTube.
Thanks.
[MUSIC PLAYING]