Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First Preview of Android N: Developer APIs and Tools

android-developers.blogspot.com

Post reply on HN
Print view View original

61–70 of 74 posts

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

#61

Post by pjmlp »

AnimalMuppet wrote: post #54
pjmlp wrote: 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.

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

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

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

#62

Post by pjmlp »

haneefmubarak wrote: post #49
habosa wrote: post #43

Earlier quoted context omitted.

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

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, et…

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.

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

#63

Post by afsina »

riskable wrote: post #22

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.

Still experimental but https://flutter.io/ is promising.

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

#64

Post by vetinari »

pjmlp wrote: post #60
blinkingled wrote: post #8

Earlier quoted context omitted.

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

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.

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.

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

#66

Post by mike_hearn »

blinkingled wrote: post #8
pjmlp wrote: 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…

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.

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

#67

Post by mserdarsanli »

sandGorgon wrote: post #58
haneefmubarak wrote: post #33

Earlier quoted context omitted.

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…

Nobody has a problem with jvm - it is one if the fastest platforms around. It's java the language we are talking about. Basically kotlin or dart targeting the jvm.

> Nobody has a problem with jvm [citation needed]

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

#68

Post by pjmlp »

vetinari wrote: post #64
pjmlp wrote: post #60

Earlier quoted context omitted.

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.

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.

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

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

#70

Post by vetinari »

pjmlp wrote: post #68
vetinari wrote: post #64

Earlier quoted context omitted.

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.

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

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

Post reply on HN