[MUSIC PLAYING]
CHET HAASE: Hello, and welcome to What's New in Android.
Or as I, the only person, like to refer to it as the Android
Keynote.
I'm Chet Haase from the Android UI Toolkit team.
ROMAINE GUY: And I'm Romaine Guy for the Graphics team.
DAN SANDLER: And I'm Dan Sandler from the System UI team.
And we don't have a lot of time, so let's get to it.
Are you ready for What's New in Android?
Here's where we left off last time, API 25.
So we're just going to that git-sha
there, pop it in to git-diff, and then off we go.
You're going to want write this down.
OK--
CHET HAASE: Next.
DAN SANDLER: Yep, that was a good one, OK.
CHET HAASE: I love those.
DAN SANDLER: Oh, man, remember we almost made that an enum?
It was hilarious.
[LAUGHTER]
You got that?
You think this is what people came for?
I don't know why we didn't think of this before.
So we've been doing this talk-- we've been telling you
what's new for years.
And you can see that--
I've forgot my blazer.
Actually, no, I had a lovely red blazer,
but somebody borrowed it for the keynote.
[LAUGHTER]
You've got your--
ROMAINE GUY: It looks like you're [INAUDIBLE] me.
DAN SANDLER: [LAUGHS] But this year it
was a little different, right?
You had developer previews well in advance,
so you've seen a lot of these APIs before.
You had the Google keynote where we showed off
a lot of really exciting stuff.
We had a developer keynote where you
learn about even more developer stuff.
So what are we doing here?
What is the point of What's New in Android?
CHET HAASE: Existential crisis.
DAN SANDLER: [LAUGHS] So--
did you test this clicker?
CHET HAASE: I did,
DAN SANDLER: OK.
CHET HAASE: I did.
DAN SANDLER: Think of this talk like a wine
tasting or a whiskey flight or one of those soda machines
that you can push all the buttons on.
This is an artisanal hand-picked selection of things
you may have overlooked in the new release of Android,
things you're going to need to do no matter
what to be part of Android O, and honestly just
things we'd like to talk about when we're on stage.
So with that, this is really what's new in Android.
Specifically, what you might have
missed in the developer preview or the I/O
keynote or the other keynote, and why you should care.
One last thing that I want to make sure we get to today
is this.
Everybody's always excited about this.
But we're going to hold that for the end.
AUDIENCE: Awww.
DAN SANDLER: It's going to be good.
All right, let's get started.
Romaine, talk about UI and graphics.
ROMAINE GUY: Yes, let's start.
So the first feature we want to talk about
is one that you saw this morning in one of the keynotes.
Chet, this clicker does not work.
You didn't test it.
CHET HAASE: Ah.
You know--
DAN SANDLER: Wasting time.
CHET HAASE: --you know, I'm going to stand back here
and I'm going to do the slides for you.
ROMAINE GUY: All right.
Go to the next slide, please.
DAN SANDLER: This is why they didn't
want to give us a clicker.
ROMAINE GUY: All right, so a feature--
[LAUGHTER]
CHET HAASE: That works for me.
ROMAINE GUY: Just go back there.
[LAUGHTER]
I don't want to see you.
So the first feature that you saw this morning
in one of the keynotes, picture in picture is not just for TV
anymore.
It's also for your phone.
So here we have an example with third party application.
Netflix running on your phone, picture in picture.
Give me that clicker.
DAN SANDLER: Let's move back.
There we go.
ROMAINE GUY: And it's really easy
to implement in your application.
You just have to modify your manifest--
and stop playing the animation, please.
You just have to say support picture in picture, true.
You don't need in O the resizeable activity
true attribute anymore, and you should also
test configuration changes.
And in your code when you want to enter
the picture in picture mode, you just have one [INAUDIBLE]
to call.
You get your activity, and you call enterPictureInPicture.
Super simple, and it's going to make your user super happy.
Then a feature that's very dear to my heart.
It's color management.
So we're adding support for wide-gamut displacing O.
It's not going to be on all devices.
Only devices that support the feature
will enable it for your application.
We're adding support for 16 bit PNG files,
so you can have wider colors, more saturated colors.
We support ICC profiles, so color profiles
embedded in bitmaps in JPEGs, PNGs, and the WebPs.
It will ensure accurate rendition of colors
across multiple screens.
We also have a bunch of new APIs,
but we're going to talk about that
more at the end of the week in a different talk.
So because a picture is worth a thousand words,
this is color management and how it works.
I hope it's clear.
[LAUGHTER]
But really the color management is about something
you've probably experienced with your own application.
Your colors look different across devices.
So we have solutions for you in Android O.
So if you want to know more, there's
going to be a talk that I'm going to give
on Friday at 11:30 on stage 2.
It's called Understanding Color.
Next, we are also adding support for multiple displays.
If your application is already--
the clicker is horrible.
If your application supports multiple windows already,
the multi-window mode, it already
supports multiple display in O. When the phone is connected
or a network device is connected to multiple displays
and you have an application that's compatible,
the user can choose to send your application
on a different display.
When this happens, you're going to get a resizing configuration
change.
You can also control on what display your activity shows up.
You can use the Activity Options for that.
And you should really test your app
if you want to support this feature.
To help you with testing, we have two new developer tools.
You can run adb shell dumpsys display.
It will list all the current available displays
on the device.
And if you call adb shell start with your activity intent,
you can specify the display on which
you want to start the activity.
So a very easy way for you to test this.
There's a lot more to those APIs,
so we encourage you to go to the office hours
on Friday and Thursday, the office hours for Windows
and activities.
Next, media.
[LAUGHTER]
So we have a lot of very useful classes in our media package.
We have the media player, the media recorder, the extractor,
and the codec.
And we added a new getMetrics API
on every one of those classes.
It helps to query information about the media
that you're dealing with.
So you can query the resolution, the codec, the bitrate,
the duration, this kind of data.
It's super easy to use.
Just call getMetrics on one of those objects.
You get the PersistableBundle, and you
can look up the documentation on developer.android.com
to know what kind of queries are available.
Playback is also much improved.
You now have control over the buffering in your application.
So you can specify a low and a high watermark.
So the playback of the video will not
start until you reach the low watermark,
and the system will do its best to keep
cache data between this low and high watermark.
And you can specify the watermarks
in duration or amount of data, in size.
We also improved seeking.
So when you seek into a video, you
can now choose the behavior.
Do you want to seek to the closest frame,
to the next keyframe, to the previous keyframe,
or to the closest sync frame.
And, finally, we made DRM playback
with Widevine a lot easier to use
in all of your applications.
For recording, until now, the media mixer
only let you add one video track and/or one audio track.
Now you can have as many audio and video tracks as you want.
You can also create custom tracks.
The MIME type has to start with "application/"
and it's basically a side band where you can encode any kind
of data you want.
So a canonical example is to encode JavaScript data
if you want to be able to replay a 360 video
or something like that.
WebView comes with really useful new APIs.
We've added the ability to save browsing,
that you know and love from Chrome.
That detects malwares and unsecure web pages.
So if you add this tag in your manifest, this meta-data tag,
it's going to use the same backend and the same API
that Chrome itself uses to secure the browsing
experience for your users.
The WebView uses now multiple processes.
And in particular, there's a render process.
So we also have new APIs to deal with these multi-processes.
So if the render process crashes,
you can use the Termination Handle API to detect the crash
and decide what to do in your application.
You can crash your application if you want,
you can try to restart the WebView,
or you can just log something and show a message to the user.
It's much more graceful than before.
You can also use the Renderer Importance API
to better deal with the low memory situations.
So when the system is low on memory,
it's going to try to reclaim RAM from somewhere.
And you can tell the system whether your WebView
is very important or not that important to your application.
So if the WebView is critical to your application,
you should definitely take a look at this API.
CHET HAASE: So you know it's the right button, right?
ROMAINE GUY: Yes, I know that.
[LAUGHTER]
So there were a couple of long requested features
for animators, specifically for AnimatorSets.
They were deceptively tricky to implement, so it took a while.
But now in Android O, we have the capability in AnimatorSets
of having seeking.
So now if you have an Animator that's
a collection of child Animators, you
can seek within those child Animators
in the overall AnimatorSet.
So, yeah.
We also have the ability, uh--
to reverse
[LAUGHTER]
ROMAINE GUY: Hey, Chet, didn't you
try to implement those APIs a while ago?
CHET HAASE: Maybe.
ROMAINE GUY: Uh-huh.
And who implemented the APIs in the end?
CHET HAASE: Not me.
ROMAINE GUY: Yeah
CHET HAASE: Yeah.
ROMAINE GUY: Exactly.
CHET HAASE: So new capability, again, in AnimatorSet
to reverse.
So you no longer have to set up a separate AnimatorSet with all
that functionality and get a listener and all that.
We do all that tedious work for you, so yeah.
Autofill, because it's really tedious
to get all that information correct over and over.
We saw this in the keynote earlier.
It's the ability to--
you've got a form to fill in.
There is a provider that can give you that information.
So when you get those text fields,
we can automatically enter that information for you.
And there are a couple of different aspects to this.
One is that you can certainly implement your own service
and provide that capability, or depend on service
that we are providing instead.
Or more typically, you will implement a client of that.
The standard views just work.
If you're using TextView, if you're using EditText,
we know how to receive this information
to interact with a service already.
So you don't need to do anything for standard views.
If you're using custom views, or if you
want to provide more information about standard views,
we have APIs for providing hints to us about what the value
types are, as well as APIs to tell
us more about your custom views and how
you want to interact with that.
Also if you have a custom view hierarchy--
let's say you have a surface view where you have views
inside of there but all we know is that there's a SurfaceView,
then there are APIs for you to tell us
about the virtual hierarchy that you want us to interact with.
There is going to be more about this in a session on Friday
morning, so go to that if you want
to learn more about autofill.
And now let's talk a little bit about text.
There's been a bunch of stuff going on in the text arena
this time.
I think we can rewrite this.
There we go.
[LAUGHTER]
I only use that font because it hurts Dan.
It just physically hurts him.
It's awesome.
ROMAINE GUY: I think you broke him.
CHET HAASE: All right, so first of all,
you can use XML to declare font information using
sort of a neat hack with data binding,
but it's kind of tricky to do.
And why shouldn't we actually provide
that capability for you?
So now we do.
So you can now actually put a font file directly
in this new resource font directory.
[APPLAUSE]
Yay, indeed.
So put that in the directory, or you can tell us
about the font family.
So you can provide several fonts with information
about the styles of each, and then you
can just use those directly as you could any other resource.
And from code, you just say, give me that resource,
and away you go.
Downloadable fonts.
Now we have the capability for you
to declare a font that you want to use that we will then
download and cache on the system for you if it is not there yet,
or if it is on the system then we'll use it from the cache.
You can do this from code or from XML
and use it as a resource, just like you did in XML fonts
on the previous exciting slide.
And we also have a font provider that we
are providing in a not yet released version of Google Play
Services.
There is a beta version of that available at the conference
this week.
I don't know the details on that,
but there's a session where you can learn the details,
or you should be able to go to the Play Services website
to learn more about that.
And this gives you access to all of Google fonts.
So if you just want to use one of the standard ones,
such as that beautiful font I use to kickoff this section,
maybe that's in there, then you can ask for that
directly from the service.
Also there's the ability to have Auto-Sizing TextView.
So, typically, if you resize a TextView--
[APPLAUSE]
DAN SANDLER: You never know what's
going to be the hit, right?
Text.
CHET HAASE: Text is cool, especially
when it's in the right font.
So what you get now is the behavior on the left
there where we're just resizing the view itself.
There's no change to the font.
But on the right, if you opt into the Auto-Sizing TextView
behavior, then we're going to resize the font for you.
And you can specify the behavior or the step increments
that you want to use or the specific size
that you want to snap to as it resizes.
So there's APIs for that.
There's APIs in both XML as well as Java programming language
codes, so knock yourself out.
And for all of these text features,
XML fonts, downloadable fonts, and Auto-Sizing TextView.
They're talking about all of these in the What's
New in Support Library session tomorrow morning.
And you're wondering, why are they talking about it
in a Support Library session?
Aren't these O platform APIs?
Yes, they are.
And they are also in Support Library.
[APPLAUSE]
So you can use all of these capabilities going back
on to earlier releases.
AccessibilityService Utilities.
If you're writing in AccessibilityService,
great thing to do.
We have new capabilities that you can take advantage of.
Language detection, the ability to put
a button in the navigation bar along with the other buttons
there to make it easier to access your stuff.
Separate volume control for accessibility volume,
so you're not conflating that volume
with other volumes on the devices,
and also the ability to define custom fingerprint gestures.
If you want to learn anything more about these,
there's a session this afternoon on accessibility
that you should check out.
And finally, one of my favorite really tiny changes--
I'm going to say tiny because it's
one line of code for the API, but the actual cls
that went in to fix all the code that
was dependent upon the former implementation was huge.
So I don't want to detract from the work from it.
But API-wise, really tiny, kind of hidden,
kind of looks like the same thing from the outside.
The way findViewById used to be declared with something
like this, public view, findViewById,
and then you call that, you pass in your resource ID,
and get back a view, and then you immediately
cast it into what you want.
So TextView, you have to tell it to TextView
on both the left and the right, and there's parentheses,
and it's big bother.
People use helper libraries just to get around the fact
that this looks so horrible.
So now--
[APPLAUSE]
--we have this.
I call this feature Castaway.
I think I am the only one that does so.
DAN SANDLER: All right, blew past my first slide.
That's fine.
I want to talk a little bit about some of the System UI
stuff you're going to look at.
If you have an app, you're going to need
to know about adaptive icons.
I think this got like barely a mention in one of Steph's
slides earlier today.
Essentially, we are trying to save you time and money.
There are so many launchers out there, and each one of them
has a different recommendation for the shape of your icon.
So adaptive icons is a new piece of technology
that we have brought to you in O that allows you to say,
here's my background, here's my foreground, cut out
to whatever shape you like.
So even if the launcher has a circle
or it's got round rectangle or it's got something awful,
you have an icon that matches exactly the local flavor.
There's going to be a ton more information
about adaptive icons at a talk on Thursday,
and definitely go to that one.
All right, let's talk about shortcuts and widgets,
because launcher is also part of System UI.
Previously, to get shortcuts and widgets on the user's screen,
there's a broadcast for shortcuts that kind of works,
and for widgets you just have to beg the user, please, please,
see if you can find our widget inside the launcher.
In O, you can now actually request one of these things
to be pinned to the user's workspace
using Shortcut Manager for shortcuts,
using App Widget Manager for widgets.
And the user then gets the opportunity
to say, no, I don't want that on my desktop, or yes, I do,
and, in fact, I will go ahead and place it
exactly where I want it.
Or they can just say, sure, find a spot for it, which
was the previous behavior.
So now you don't have to walk the user through a long flow.
You just send them right into this dialog.
It's super convenient.
Look at all the new users you're going to have on your widgets.
[APPLAUSE]
I could just say I'm pausing for applause when I'm really
fussing with the clicker here.
This also we'll talk about on Thursday at 4:30.
All right, notifications, you knew it was coming.
They're super useful.
They're great for engagement.
Users love them.
They may be a little out of control.
There's a lot that is being used in the notification stream
right now, and it's very hard for you
to get your message to the users that want it.
And it's very hard for a user to manage the inflow
of demands on their attention.
If it's out of control now, the user
should always be in control.
That's been a principle of ours since the beginning.
We added the ability to block notifications
from a package in Jelly Bean.
And Nougat we refined a little bit and added quietening.
But all through this, the number one request
we get from users is, OK, but can I just
block some of an app's notifications?
On the other hand, the number one request
we get from developers is could the user just
block some of my notifications?
It's the same thing.
Everybody's been asking for the same thing.
And this is where notification channels come from.
It's a new API in O. A channel is a named
category of notifications from one app
that all share the same behavior.
Vibration, sound, light, whether they pop up on screen,
so that the user has explicit and fine grained control.
[APPLAUSE]
So it's an app, you'll get to set up all your own channels,
defining the default behavior for O. A private message should
pop up.
A tag maybe doesn't pop up or it's got a lower priority,
and then it users when they long press a notification or use
the new slide gesture to look at it,
they can see what channel it's on
and make changes right there in line.
Once you target O, if you take nothing else away from my two
minutes here, take away this.
You have to use channels for every notification,
or they will be dropped.
So until you target O, you can start slowly
evolving your notification system over to channels.
Once you target O, they have to all be channelized,
because we're trying to get to a consistent experience
where the user knows what they're going to get.
And we're going to talk about that
and a lot of other great stuff, including
design considerations, all the code
that I didn't put up there, whatever that little blinky
thing is over there, on this talk at 4:30 tomorrow.
There's a lot of other great stuff coming to System UI.
We have listed some of it here.
It ran off the end again.
I like doing that with slides.
And I encourage you very much to check out the developer
previews or install the beta and play with all of it.
We're really proud of it.
ROMAINE GUY: All right, new APIs for US developers.
We expanded on the Strict Mode API
that I'm sure you all using in your debugging.
So now on the ThreadPolicy, you can
get warned when using unbuffered I/O. So if you use
an input or an output stream without wrapping it into one
of the buffered streams, you'll get a flash
or whatever it is, the trigger warning you've set.
On the VmPolicy, if you don't tag your sockets
you can also get warned.
Tagging sockets is really useful to do traffic
debugging using Android Studio.
And finally, if you open another intent--
if you send an intent to outside of your application
and you need to grant permission,
you can also be warned.
So it's fairly easy to use.
It looks like the previous APIs we had.
Media File Access.
So we introduced the document providers a while ago,
a couple releases ago, and they're extremely useful,
except when you have large documents.
If you have a large document, you
needed to download the entire data
before you could pass it to the user of the document provider.
So now you can create seekable file descriptors.
It's extremely useful for audio, video,
or any large type of content.
It's also extremely easy to use.
So you get to StorageManager, you open the proxy file
descriptor, you give it a callback,
and then we're going to invoke your callback
to request the size of the documents,
to request some amount of data in the byte array,
and then we're going to tell you when to close it.
Cached data.
So this is new APIs that the system gives
you to be a better citizen.
So each app has a certain amount of data it
can use in the cache partition.
And when the system runs out of space, out of storage space,
it's going to start deleting some of your cache data.
So if you stay below the quota that you're given,
you can avoid your data being deleted.
For this, you can use the StorageManager.
You can query the number of bytes
that are allocated to your app.
You should query that from time to time,
because the quota can change depending
on how much of the quote you use,
or how often the user uses the application.
Then when you want to allocate data,
you can just use allocateBytes.
You could do it yourself.
You could just create a file, you could just
create an output stream.
But it's much better to do it this way,
because when you go through allocateBytes, if needed,
the system will delete another app's cached data
to make space for your data.
So that means that getCacheQuotaBytes
might be bigger than the free space that's
left on the device.
You can also use something called
setCacheBehaviorTombstone.
So this is very useful for your app
to be able to tell the difference between a file that
was never cached, and a file that was cached but deleted.
So when you set that behavior and the system
deletes some of your files in your cache,
it will truncate the file.
So the file will still be there, but the size will be set to 0.
That tells you that the cache was deleted by the system.
And, finally, the usable space and the allocatable space
are different.
DAN SANDLER: There's a lot going on in Android security
in this release.
And we only have little bit of time to talk about it.
I wanted to highlight some of the privacy agreements
that are new in Android O.
If you've been using Android ID, you
need to know now that it is going
to be different for every app, for every user on the device.
So it can't be used to track users between apps
on the same device anymore.
Similarly, if you've been reflecting
into system properties to get net.hostname, it is empty now.
And so if you're saying, well, I really
need advertising IDs to be able to send users
the correct contextual advertisements, that
is what the Advertising ID API in Google Play Services is for.
So go check it out in Google Play,
but you cannot use Android ID.
You can't trust it anymore in the same way
you might have done.
I had a slide here about WebView,
but then Romaine took it.
One other thing I wanted to mention
about safe browsing in WebView is because WebView is now
pushed to the Play Store every six months,
you will be able to opt into safe browsing features
as far back as Lollipop, which is fantastic.
We also saw the unveiling during the keynote, something
we're calling Google Play Protect, which is actually
a lot of technologies that we've had in place before,
but really haven't given the visibility
that they truly deserve.
Because we are watching out for people all the time.
So any device with Google Play has Protect enabled.
Every app that gets uploaded to Play
is prescreened and continuously rescreened
for each new version that's uploaded.
And every time you install an app
where you have Play Protect set up,
that app is going to be screened as well,
even if you got it from another store or from ADB install.
And we're really excited about this.
There is so much more to talk about--
so much more to talk about in Android security.
They gave me a whole slide deck of stuff,
so I said, why don't you have your own talk?
I actually didn't say that, they had their own talk anyway.
On Thursday at 2:30, you're going
to go and find out what's new in Android security
from soup to nuts.
Everything from Kernel hardening all the way
to more stuff about WebView.
ROMAINE GUY: Language and runtime,
I think you already know what I'm going to say.
So this morning, we announced official support for Kotlin.
[APPLAUSE]
You saw Steph on stage, and I see her sitting right there
in the hallway.
So if you see her at I/O, go say thanks.
So Steph and the whole team behind her
did amazing work over the past, however
much time, to bring you this.
So go thank her.
She'll pass your thanks along to the whole team.
So it's available today in Android 3.0.
There's a lot of documentation already online.
I could spend hours talking about Kotlin
and why it's good for you, why it's good for us.
Actually, should I hijack the talk?
CHET HAASE: He could.
Actually, he really good.
He does, in fact.
ROMAINE GUY: But unfortunately we
don't have that much time in this session.
So, instead, I invite you to come on Friday at 10:30
here on this stage.
There's going to be a talk called Introduction to Kotlin
from Andrey Breslav, the lead language designer at JetBrains;
and Hadi, VP of Developer Advocacy at JetBrains.
And then in the afternoon on stage 4,
we'll have Life is Great and Everything Will Be OK,
Kotlin is Here by Christina Lee from Pinterest
and Jack Wharton from Square.
[APPLAUSE]
And this is important to us, because the reason
why we brought you Kotlin is because you the community
are using Kotlin.
We listened, we heard you, we're bringing you what you wanted.
So we wanted to have you, the community, onstage to talk
about it better than we can.
Also, if you have questions, you can come to the developer
sandbox at the Android [INAUDIBLE] Platform
booth today from 3:00 to 4:30, on Thursday from 2:00 to 4:00,
and on Friday from noon to 2:00 p.m.
Andrey, the language designer, will be there
to answer all your questions.
So please come if you want to know anything about Kotlin.
Just go there and go ask your questions.
Now, like Steph mentioned, we're also doubling down on our other
languages, so the Java programming language,
and we also have C and C++.
So for the Java programming language,
we're adding new packages in Android O.
We have java.time that finally makes manipulating
time and dates easy.
And it makes sense.
It makes a lot more sense than the older APIs
CHET HAASE: It's about time.
ROMAINE GUY: Yeah, it's about time.
We're also bringing you java.nio.file.
It improves on the good old java.io.file API.
It lets you access the attributes of the file.
It lets you easily manipulate paths and read files.
We'll look at an example.
And, finally, java.lang.invoke, it's
a slight variation on reflection.
This is a gross approximation, but it's really cool
because it lets you transform and wrap method handles
in your application.
So here's an example of the new files API.
So you can use the path class to get a path.
And then you can just call files.lines.
It will read the entire content of the file.
You're going to get a stream.
So in this example, I'm using lambdas and stream APIs
to remove all the empty lines, all the lines that
start with a pound sign, and then I collect everything back
into a single stream at the end.
So it's a lot easier than it was before.
CHET HAASE: All right, some changes in runtime.
We heard about some of these this morning,
and there's more about it this week.
New concurrent-copying collector,
making everything basically faster and better.
Concurrent-copying means no pause time,
except when there is a full GC.
So it can do all the stuff that it
needs to do in the background while you're doing other stuff.
In particular, one of the really cool things that it can do
is actually compact the heap in the foreground.
So previously, I believe in the previous release,
it had the ability to compact the heap, which is really good.
It can defragment it, can make the heap smaller,
it can make allocations and collections faster,
but it could only do this when activities
were in the background.
So it'd go into an idle state, and then do it
when it was in that idle state.
But when it was in the foreground,
there was nothing that it could do about the expanding
and fragmenting heap.
Now it can collect in the foreground,
defrag in the foreground, and everything gets faster.
There's also a new faster mechanism for allocations.
So we can just do bump pointer allocations,
which is way, way faster.
Collections are faster, and all of this
essentially results in less jank for you.
So faster to allocate stuff, faster to collect stuff,
means that just dealing with garbage and memory in general
is much faster using ART in the O release.
Lots of various optimizations, loop unrolling, inlining.
One of the things to note is that Dalvik
was created with memory-type constraints, right?
Everything was about saving memory
with Dalvik, which means that it can only
do so much optimization.
It sort of reached the end of its life
as far as what they could do to optimize things.
When ART came online, they basically put in a platform
upon which we could build future optimization.
So we're starting to reap those benefits now
where with every release, including
O and future releases, we're going
to be able to do more and more.
And there's a bunch of them in this release.
And you should check out a session later in the week
for more information on that.
Also there is DEX locality.
This in particular improves launch time for activities,
because we can collect all the memory in the same space.
So it's easier and faster to access
as your application is starting up.
So there's a session on Friday morning, Performance and Memory
Improvements.
So check that out for more particulars there.
So beyond the platform, we have Support Library.
We have other mechanisms for delivering things that aren't
just about the O release.
We wanted to call out some of those.
There's the v26 beta release that comes out
with developer preview 2.
The stuff that we already talked about in text, fonts and XML,
downloadable fonts, as well as Auto-Sizing TextView.
Those are all in there.
You can check those out.
In addition, there's something that we call EmojiCompat.
So one of the big issues that we have with emojis
is that if your friends are sending you
emojis that are from some future standard than whatever
we shipped on the release that you're running,
it's not possible for you to see those emojis.
And you're going to see tofus instead,
which given some of the emojis I've
seen may be more attractive, but not very meaningful.
So wouldn't it be nice if you could actually get
updated emojis on your device?
So now we have two mechanisms that apps
can use to get updated emojis.
One is that apps can actually bundle with updated emojis.
So they can update the apps to the Play Store
and then to their users so that the users
get more timely updates of these emojis.
The other, and probably better long term solution,
is to actually use a service that we
can provide for downloadable fonts
that we talked about earlier, where they can automatically
get updated fonts through downloadable fonts, right?
So the app can build in the capability
to use the downloadable fonts capability to have
updated emojis as we provide them into the service.
So, again, go to the What's New in Support Library talk
tomorrow morning to learn more about all of those.
We also had more stuff going on an animation
besides the small stuff in AnimatorSet
I talked about earlier.
We have the ability to now have physics-based animation stuff.
So if we want to see that in animation form,
the ability to have essentially animations
driven through velocity.
All of the animation capabilities
that we have in the platform to date
have been driven around the idea of a duration.
You tell it how long you want it to run for.
But many animations, you really want
to drive it by the velocity.
In particular, animations that are
driven by user interactions.
You're dragging something on the screen and you let go,
wouldn't it be nice if it took off from your finger
at the same velocity that you were dragging
it went when you let go?
So flings, scrolls, all that stuff,
it really requires a velocity based animation system instead.
You can do that with the animators,
but it's really tedious.
It requires math.
Math is hard.
And so we've baked in that capability
to this new Physics Animation System that
is more natural, more interactive, and more
interruptable Because it was really
intended to work with that user interactivity model.
Here's a small demo of this.
So as we're dragging the top thing around,
the other two circles are essentially
hinged to the top one through springs that you defined.
And so they follow it in space.
They're not lockstep following it,
but they're basically on springs that are attached.
And they immediately benefit from that interactivity
and that physics-based notion of these springs.
So there's a talk on this on Friday afternoon, all
about the new physics-based animation stuff.
Please come to that if you want to know more about that.
Architecture components.
This was mentioned in the keynotes.
We thought that maybe sometimes Android development
is a little bit harder than it needs to be.
So we took a step back and said, OK, what
are some of the major problems that we should
take another run at to try to simplify
this for app developers?
And a couple of those that we've taken specific
runs at right now or around lifecycle.
It is apparently kind of hard to deal with the fact
that your activities can die at any time
when you rotate the screen or it goes in the background
or whatever.
And finding out exactly what state you're in
can be a bit tedious.
It is an ongoing issue that all app developers
need to deal with.
So we've taken another approach to that
to make that much easier.
And in addition to that, we've also
taken a look at persistence.
So you can issue raw SQL now, and that's about all
you got on the system.
So we have a new way of doing that builds on that capability
and makes it easier and more powerful.
We're going to talk about all of those this week.
We're going to have an introduction to architecture
components, I would encourage you to go to, this afternoon.
That's actually immediately after this session.
And then tomorrow morning, we're going
to have one on the lifecycle problem
and how we've solved that.
And we're also going to have one on persistence and offline.
And all of these are bits that you can actually
try out in an earlier release form already.
So check those out.
Hopefully it will make your developer lives easier.
There are some behavior changes, some of which
you're going to care about more than others.
There have been some changes to the behavior
of background applications, in particular, location.
If you are running as a background application,
you're only going to get course grained location information.
All of these things are being done not to make it harder,
but to make the devices better, right?
If all applications have all capabilities at all times,
and they can do whatever they need to or want to at any time,
then essentially you're going to run the battery down
because everybody's doing too much work all the time.
So we're trying to be judicious about which applications
actually need the services at which times
so that we can make the experience for the user much
better.
The experience for your users much better as well.
So one of those is in location, course grained information
when you're in the background.
Another one is wake locks.
We noticed that it was common for an application
to go into a background state and then into a cache state,
and it would have a wake lock at the time.
And it would just keep that wake lock,
and it would hold it for a very long time.
And that really runs the battery down.
So now, sometime after you go into a cache state,
the wake lock is automatically released
so that it doesn't put the device
into that unseemly state.
And also there are limits to execution
when you're running in the background.
There have also been changes to alert windows.
In particular, there's this new type
of window called Type Application Overlay.
If you are targeting the O SDK, then this is the window type
that you must use if you want to have an alert window
capability.
If you're on earlier releases, obviously that didn't exist.
You're not going to use this.
Just know that whatever window type you are using
is going to be layered under one of these type application
overlay windows, because we have a more clearly defined
layering policy now with that.
There is more information about this afternoon
at 5 o'clock, Background Check and Other Insights.
So please come to that if you want to know
all the details about that.
And then, finally, we promised to get back to this, didn't we?
DAN SANDLER: We did.
This is one more thing, right?
CHET HAASE: All right.
So we were going to talk about this, and I think--
I mean, we have to have a drumroll, don't we?
How about like a thigh roll?
Can we have a thigh roll?
[APPLAUSE]
CHET HAASE: All right.
DAN SANDLER: That sounds nice.
CHET HAASE: Unfortunately, I'm looking at the timer on stage,
and I'm going to say that O stands for--
AUDIENCE: Awww.
CHET HAASE: -- oh, no.
We're out of time.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]