>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.
While it's certainly a change for the better, personally I find the Streams API is still clunky and lacking. In compare to LINQ, or Kotlin (case in point: http://stackoverflow.com/a/34642255).
I find the fact that streams and functional interfaces are not backwards compatible almost a deal breaker. Using Java 8 streams makes so many things easier that once you start using it, there's no going back. Now you're not going to be able to use it in production till 2019.
When you say "not backwards compatible" do you mean that the streams and functional interfaces aren't compatible with Java in Android N or do you mean that they're not being to be ported to previous versions of Android?
It depends. For example, let's compare providing an event listener via a lambda vs an anonymous inner class. Using the lambda will increase your method count by 1. However, if you're accessing class member variables, it will reduce the method count for each variable you use, because it's added as a method of the containing class and doesn't need to generate accessors.
> 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.
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.
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.)
> 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.
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.
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.
"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."
I found Samsungs implementation very useful on my Galaxy Tab S 10.5. I would read a pdf for example and take notes in the other. I tried using it for simple development as well, running a local dev server. Unfortunately js ides were still lacking on Android last time I tried, but it's clearly something that could be improved.
Definitely super excited for Android itself to have this feature.
I wish they'd add grouping to the window switcher, something similar to what's in WebOS. Because it's somewhat difficult to implement tabs without cluttering the UI in appssuch as web browesers, reddit clients, mail clients, etc.
the $150 discount on Pixel C is really telling. It's clear that revenue is higher for tablet optimized apps and games and Android really needs to step up to compete with Apple.
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.
To do that, all they'd really need to do is have a mechanism to build native apps in C, after which various language communities would be able to write simple wrappers that would allow them to use said C API.
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.
It's easy to run other languages on Android (see Go binaries). It would be a huge effort (and some would say a distraction) to port the Android SDK to another language. It would also fragment the developer ecosystem if that language was not compatible with Java libraries (reducing your choices to Scala, Clojure, etc).
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.
OTOH, that same fragmentation also means competition. Allowing for multiple independent languages to run on the platform means a plethora of developers to whom the platform is now accessible.
Having an API that is easy to use would really open up the ecosystem. Also, having much faster, machine targeted code (ie: compiled with CPU architecture and model specific optimizations and instructions) in C, C++, Rust, Go, etc. would mean better performance and less battery usage in some apps, which overall would translate to a superior user experience.
> which overall would translate to a superior user experience.
Only for users of devices that the dev bothered to put out binaries for. I guarantee you most devs that use the NDK are not building for all 8 ABIs that the NDK supports. ARMv7-neon may be the most common arch but it is far, far from the only one.
Since the compilation to native code takes place at installation time, supposedly ART would take advantage of the CPU specific features.
Also they could in theory do escape analysis to do stack allocation.
And assuming Google does indeed keep up with Java versions, eventually value types will be supported.
The only way they are going to move away from all the framework code they have invested in Java (the language) is if they create a common runtime like WinRT or Objective-C runtime.
However, it is quite telling that the Android team doesn't even bother to add Go or Dart support to the NDK.
Having used the 4.3 version I wouldn't recommend it, specially since looking at the web site it seems anything has hardly changed in that area since my attempt.
It adds very little value over Java + NDK on Android.
The Android native widgets aren't supported, rather emulated via QML and only the most well known ones.
For the majority of Android APIs no support is provided, offering no advantage over we having to write our own JNI wrappers.
Also iOS and Windows Phone support are even worse than Android.
That's a strange complaint. The whole premise of putting QML, or any other UI toolkit for that matter, on Android is to use those instead of native Android widgets. In that sense, it adds a lot of value.
The premise of a portable framework is to allow me to write my code in a portable way across multiple operating systems.
If I have to spend time writing bindings to OS APIs and faking UI widgets for each OS I am targeting, then the framework is not doing anything to help me, rather on the contrary.
As extra info, on 5.3 some of the C++ widgets render on Android as if it was a desktop. Just try to use a Qr file selector on your phone.
Apparently this has worked so well that 5.6 is going to have yet another re-write of the controls.
The purpose of porting alternative UI toolkits is to let developers use their preferred programming language. Users don't want to see UI widgets that look out of place. Ideally there should be no perceivable difference in the end result.
That doesn't feel like the primary problem with Android. The lowest hanging fruit in that department is officially supporting Kotlin which is gaining traction in the community already.
That would be awesome but I think it's a huge job so it really need a purpose. Java is awesome but I love rust, yet that's not really a good enough reason I think.
I'm disappointed to see that it will take Android N for the Doze feature to be practical [0]. As it currently stands, Doze only activates when the device is stationary. My phone never leaves my pocket, since I'm paranoid about setting it down, so the gyrometer being engaged is enough to prevent Doze from triggering.
This is very true, but I think doing it one step at a time is a good way to slip into a more power-efficient system without breaking tons of top apps.
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.
No, I don't, but I don't often forget to hook up my phone to the charger.
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.
Sounds more like you want a setting of "syncing is not important to me"
Doze backs off sync period, trading timeliness for battery life. That's why significant motion prevents it from happening, it assumes that if it's on your person then syncing is important. Which is a generally true assumption.
Hope the faster release will also show in a faster update cycle for vendors. Or some kind of guarantee that devices who got/get M, will also get N. The quick reply API and notification tweaks are pretty great and doze is now useful (seems like a something like Sony Stamina mode).
Ice Cream Sandwich, which is 5 years old, has about vanished.
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.
How much does a digital sign really benefit from tracking the most recent releases anyways? Other than the obvious issue of security fixes, it doesn't seem like that is a domain that would really care that much about trying to keep up.
Then make the business case to the right stakeholders that supporting the latest versions of Android is important. I don't see how the digital signage ecosystem not staying up to date is Google's fault.
I have millions of installs for my apps and my minSdk is 16, and I'm very close to bumping it to 19.
>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.