[pjmlp]

Besides finally saying something about Java support, I found other items interesting.

ART will recompile applications based on profiling data.

Introduction of support to hardware keystores, with the mention that one use case is to prevent jailbreaking.

Prevent the NDK users that ignored the documentation and linked to non official platform libraries to keep doing that.

[blinkingled]

> ART will recompile applications based on profiling data.

They went back to having a JIT in addition to AOT - which means there is no AOT when the app is installed. When the device is idle/charging then AOT will selectively precompile the used portions of the app and optimize it further using the profiling data. So faster app installs (boon for FDE devices with slow NAND write speeds) and no optimizing apps step after system update.

[BinaryIdiot]

> no optimizing apps step after system update.

That is fantastic news. Every single time my Nexus 6P gets an update it feels like it takes at least 15 minutes to "optimize apps". Every. Single. Update.

[blinkingled]

The effect will be even more amazing for non-nexus/carrier devices with bloatware - my work phone (VZW M8) just got Marshmallow and it took couple hours to complete - most of the time was spent on twice optimizing 303 apps! (Only 30-35 out of those are things I installed.)

[curt15]

Well, those devices rarely get updates anyway.

[pjmlp]

I never understood why Google didn't use Microsoft's approach of compiling it on the store.

WP 8.x only use a dynamic linker on the device.

WP 10 are fully compiled and linked on the store. Although the dynamic linker option is still there as well.

[vetinari]

Because the user doesn't have to use the store.

In Android, it is possible to use third-party stores or sideload apps. Or you can develop your own app totally offline.

[pjmlp]

> In Android, it is possible to use third-party stores or sideload apps.

In Windows Phone it is also possible to sideload.

> Or you can develop your own app totally offline.

You can compile .NET to native code via release builds, before deploying it to the Windows Phone.

It is only when you upload the appx to the store that MSIL is still used.

But I agree that with Windows Phone and now with iOS going bitcode as well, there isn't the issue of third party stores.

Still, nothing would prevent such stores to offer a server compiler service.

[vetinari]

> In Windows Phone it is also possible to sideload.

Good to know. I was under impression (since WP7 was a current OS, I admit) that you have to upload to MS/have it signed/download.

> Still, nothing would prevent such stores to offer a server compiler service.

Nothing prevents that technically. However, it would mean a tighter coupling between platform owner and majority store owner, Google probably wants to avoid that. It could destroy the open-source nature of Android, since for now the Play Store is layered above open-source platform; this compiler would not fit there, it would have to go below, into the layer that is currently open source.

[mike_hearn]

Interesting how things go in circles. Dalvik was an interpreter+tracing JIT. Then ART went full AOT. Now ART is going back to a hotspot-style JIT, I guess.

The big question in my mind is how they will balance first-run performance against the desire for fast installs. People's impression of an app is determined by their first run. If it's slow, because nothing has been compiled yet, and if it doesn't get fast until that night when the phone is charging, then that's going to be a huge problem for a lot of developers. If you can ship a pre-calculated profile with the app and that's used to do AOT compilation of the hotspots at install time, that'd represent an excellent balance.

[andrewstuart2]

Out of curiousity, where'd you hear this? I love learning low-level details like that.

[blinkingled]

developer.android.com and the Android Developer blog are good sources apart from XDA, G+ for various Android low level devs - this particular one came from - http://developer.android.com/preview/api-overview.html

[pjmlp]

It is too early for that, but the first thing that came to my mind was the JIT PGO support introduced in .NET 4.5 and how IBM J9 does caching of compiled code.

Just what I can think of as similar, still need to dig deeper into what it actually means for Android.

[AnimalMuppet]

> Prevent the NDK users that ignored the documentation and linked to non official platform libraries to keep doing that.

I'm sorry, where in the article did you see that? I've looked twice and can't find it.

[pjmlp]

https://developer.android.com/preview/behavior-changes.html#...

"Android N includes namespace changes to prevent loading of non-public APIs. If you use the NDK, you should only be using public APIs from the Android platform. Using non-public APIs in the next official release of Android can cause your app to crash."

[AnimalMuppet]

Thanks!

[kodroid]

> Introduction of support to hardware keystores, with the mention that one use case is to prevent jailbreaking

This makes no sense, android already has hardware keystore support, jailbreaking is an ios term, and this is not mentioned anywhere in the lost...?!