DAN ALBERT: So mostly just a quick update
on what the NDK has gone through in the last year
and a little bit forward looking stuff, as well as
a tiny bit of advice on the 64-bit transition that's
coming up.
That's me, Dan Albert.
That's where we have our bug tracker and some wiki
and some announcements and stuff.
So in the last year, we've done r15 and r16.
r15 is when we switched over to the new form of the headers,
which has the one single blob of headers that
are correct for every API level, instead
of having a bunch of bug fixes only in the newest one,
and the old ones are just horribly out of date
and broken.
r16, that became a requirement, and we fixed up libc++
and libandroid support.
If you were here last year, or have me talk before,
you'll know that libc++ was really in a beta state
in the NDK, because of this libandroid support that we used
to back port APIs to back then, as early as gingerbread.
We've cleaned all that up, so this is now actually
the STL we recommend.
In r17, it's actually the default.
We removed support for ARM5 and the MIPS flavors, which
is probably a welcome change for all of you,
because that's less stuff that you have to test.
r17 is in beta right now.
In theory, stable's going out tomorrow,
but I haven't spoken to QA yet today, so we'll see.
Defaults to libc++, it adds the O-MR1 APIs.
It adds the P APIs.
More of those landing tomorrow.
Asan no longer requires root, which is fantastic.
You now just have to ship the shared library in your app,
and you use this wrap.sh, which is an O feature,
to make sure it gets loaded in your APK.
LTO now works on Windows.
I know that was a huge thing for game developers, so hooray.
And apparently, we removed those ABIs again.
I think that was r17, and they were deprecated in r16.
r18, we've been working on for a while.
It includes clang-tidy support, and it also
removes all the old crap that we've
been working on deprecating for the last few years--
so GCC, the other STLs.
Starting with r18, it is clang, and it is libc++,
and that is it.
Far fewer combinations to test, so everything
should be much higher quality.
And it should be less complications of getting
all your middleware to match.
r19, this is going to be a big change for anyone
in the room that maintains their own build system,
but it should be the change that you get
to delete a ton of your code.
All of the tool chains are just going
to be standalone tool chains.
Android will start working like a normal cross-compiler,
where you're just call clang, you say,
I'm targeting error 6426, and it just does the right thing.
You no longer have to know all the crazy flags and the paths
to everything.
Yeah, clang transition is complete.
We are done with this inside Google.
All of userspace was clang in Marsh-- well, most--
in Marshmallow, all of it in Nougat,
most-- some of the kernels in Oreo.
It's now-- it was the default compiler starting
in NDK r13, which is a year and a half ago.
It is the only one in the next release.
It's probably less exciting for this room, but new APIs
and stuff for libc.
The clang fortified source is a security measure
that maybe people in this room care about.
It'll do things like check buffer overruns
at both compile time and some mitigation at runtime.
Again, P, more APIs.
CPU profiling, we ship simpleperf in the NDK.
It has, for ages, had a command-line interface,
but in Studio 3.1, it's got a UI, which looks like that.
The command-line tool itself can spit out
these flame graphs, which are really cool, helpful
for drilling down into what exactly is going wrong.
Updates on command-line tools to O/P. Got
a whole bunch of new things in toybox, adb
has been sped up on USB3.
And like I said, advice on the 64-bit transition.
We're not trying to create fire drills here.
It's really for the users.
They only have to run one zygote if you
have a 64-bit-only device.
If there are any reasons why you can't hit the 2019
deadline on that, let us know.
We do want to know about that, and we'll work with you
to try to sort that out.
The 64-bit transition does come with some performance
improvements.
If Tim is still in the room, he can maybe
hint at what they are, because I don't know numbers.
TIM: 5% to 10%.
DAN ALBERT: 5% to 10%.
OK, that was my guess.
And that will vary based on your application, obviously.
Having the higher minimum minSdkVersion.
Since 64-bit only came in L, you can't target anything lower
than L, which means you have newer APIs available.
You don't need libandroid support.
And we are working with all the engine companies
to make sure that their engines are 64-bit ready
by the time this happens.
You know who you are.
And for the actual how to port your code to 64-bit,
we found these three really helpful
when we were porting the platform.
It'll catch the cases where, oops, you
were using an int instead of a pointer,
or, oops, you're using a pointer instead of an int.
Implicit function declaration is a fun one,
because C, in all of its wisdom, decided
that a function that was not defined
had the return type of int, which is very frustrating when
it actually returns a pointer.
Because it will just truncate it, and your code will explode.