Live data from Hacker News

First Preview of Android N: Developer APIs and Tools

android-developers.blogspot.com

31–40 of 74 posts

Re: First Preview of Android N: Developer APIs and Tools

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

Re: First Preview of Android N: Developer APIs and Tools

#33

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.

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

Re: First Preview of Android N: Developer APIs and Tools

#34

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.

Any language they add support for in the short term will have to be a JVM language so they don't have to rewrite the SDK.

Re: First Preview of Android N: Developer APIs and Tools

#35
post #6

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.

> 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 aft…

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.

Re: First Preview of Android N: Developer APIs and Tools

#37
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).

Re: First Preview of Android N: Developer APIs and Tools

#38
post #19

Earlier quoted context omitted.

In fact, they've implemented lambdas exactly like retrolambda does via anonymous classes.

So this is just another way to blow up your dex method count?

disclaimer: I work on Android dev tools

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.

Re: First Preview of Android N: Developer APIs and Tools

#40

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.

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 yo…

Qt has already been ported to Android via the NDK. Nothing stops other UI frameworks from doing the same.
Post reply on HN