
First Preview of Android N: Developer APIs and Tools - krat
http://android-developers.blogspot.com/2016/03/first-preview-of-android-n-developer.html
======
ubertaco
Woah:

>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.

~~~
joelhaasnoot
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.

~~~
richdougherty
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?

~~~
pas
Maybe in general, Java 8 generated bytecode won't run on earlier JVMs, but a
lot of shops are still on Java 6/7\. (Allegedly.)

------
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.

------
trequartista
Extremely interested in the multi-window support. With phone screens getting
bigger than ever, this could be a very useful feature for multi-tasking

~~~
smrtinsert
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.

------
RivieraKid
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.

------
Wonnk13
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.

------
riskable
I was really hoping for something more exciting. Like maybe native support for
a new, different language (like Apple did with Swift).

It would be absolutely amazing if Google came out with a mechanism for
building native apps in, say, Rust.

~~~
haneefmubarak
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).

~~~
habosa
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.

~~~
haneefmubarak
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.

~~~
kllrnohj
> 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.

------
fulafel
I wonder why the Pixel C developer discount is us-only.

------
AdmiralAsshat
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.

[0] [http://www.androidpolice.com/2016/03/09/android-n-feature-
sp...](http://www.androidpolice.com/2016/03/09/android-n-feature-spotlight-
doze-will-now-work-whenever-the-screen-is-off-even-when-the-device-isnt-
stationary/)

~~~
kllrnohj
You sleep with your phone in your pocket?

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.

~~~
AdmiralAsshat
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.

~~~
kllrnohj
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.

------
tdkl
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).

------
geodel
So Java 8 support is finally here. I think this is the effect of Android
moving to OpenJDK.

~~~
EddieRingle
They've been adding Java 8 features to ART and Jack in AOSP for many months
now, even before the OpenJDK move.

------
oDot
I really wish they would get the camera and gyro APIs on par with iOS so
Instagram could port Hyperlapse

~~~
sahaskatta
Microsoft Hyperlapse works quite well
[https://play.google.com/store/apps/details?id=com.microsoft....](https://play.google.com/store/apps/details?id=com.microsoft.hyperlapsemobile)

------
estefan
It's blatantly going to be called Nutella.

------
creshal
I guess I'll take a look at the APIs in 5 years, when it has enough market
share to be worth considering.

~~~
sliverstorm
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.

Lollipop, at a year and half old, has another 30%

~~~
creshal
KitKat is three years old at this point. And I still see new phones and
tablets with 4.1 or 4.2 on sale.

Digital Signage platforms especially (the part of the Android market I
actually care about) seem to be largely stuck on 4.1.

~~~
dyladan
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.

~~~
creshal
Security fixes are reason enough.

