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.
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.
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.
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.
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.
Just what I can think of as similar, still need to dig deeper into what it actually means for Android.
I'm sorry, where in the article did you see that? I've looked twice and can't find it.
"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."
This makes no sense, android already has hardware keystore support, jailbreaking is an ios term, and this is not mentioned anywhere in the lost...?!
It would be absolutely amazing if Google came out with a mechanism for building native apps in, say, Rust.
To an extent, that partially exists in the form of Android NDK, but that's not really a full solution. If and when Google makes it possible to easily create your entire app natively (with a clean C API), then you ought to see a surge of libraries/toolkits/frameworks coming out that will enable you to write Android apps in most common languages (Rust likely included).
The last years the NDK support has always been seen as something to help bring "legacy" code from other platforms, be consumed from Java to help speed up some algorithms, games.
In fact, apparently they are now closing down the door to rogue developers that used to link to unofficial platform libraries.
If you look at the Tango SDK, apparently they have a C API to some platform APIs, however when one digs into them, they are wrappers to functionality implemented in Java.
While the NDK is hard to use, it is enough to enable alternate modes of Android development. For instance with Unity you can develop and Android app using C# and the Unity graphical editor. That's a very powerful option for certain classes of apps.
It's java the language we are talking about. Basically kotlin or dart targeting the jvm.
>Improved Java 8 language support - We’re excited to bring Java 8 language features to Android. With Android's Jack compiler, you can now use many popular Java 8 language features, including lambdas and more, on Android versions as far back as Gingerbread. The new features help reduce boilerplate code. For example, lambdas can replace anonymous inner classes when providing event listeners. Some Java 8 language features --like default and static methods, streams, and functional interfaces -- are also now available on N and above. With Jack, we’re looking forward to tracking the Java language more closely while maintaining backward compatibility.
[0] http://www.androidpolice.com/2016/03/09/android-n-feature-sp...
Too many top apps were dependent on constantly waking up and doing network or other expensive jobs. So for M Google says 'these things won't happen when the user leaves the phone on a desk for 30m+' which spurs people to prepare for this new world even if they won't encounter it much. Now with N Google is saying 'this will happen when the screen is off for a few minutes' and now any decent app needs to prepare for this, but the best apps already got into this new world for M.
That's really the thing doze is great at. If you forget to charge your phone, you wake up with still decent amount of battery left. Or for tablets sitting around on tables/desks.
I do however, sit/stand at my desk for 8-9 hours a day and maybe pull the phone out less than once an hour. I would like the phone to be in Doze mode when it's in my pocket, rather than forcing me to have to put it on my desk. As I said, I don't like leaving it unattended, even if it's simply to step away for a few minutes to the watercooler.
Jelly Bean still has 30% market share, but are owners of 4 year old phones a significant portion of app revenue? I'd wager the people spending money have at least KitKat.
Lollipop, at a year and half old, has another 30%
Digital Signage platforms especially (the part of the Android market I actually care about) seem to be largely stuck on 4.1.
Definitely super excited for Android itself to have this feature.
I'm just a hobby developer, but the last four-ish months have been really exciting. There's a been ton released and polished in the developer console alone.
