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

51–60 of 74 posts

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

#51

Post by kllrnohj »

AdmiralAsshat wrote: post #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...

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.

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

#52

Post by kllrnohj »

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…

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

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

#53

Post by nly »

pjmlp wrote: post #44
nly wrote: post #40

Earlier quoted context omitted.

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

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

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.

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

#54

Post by AnimalMuppet »

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.

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

#56

Post by curt15 »

nly wrote: post #53
pjmlp wrote: post #44

Earlier quoted context omitted.

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

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

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

#57

Post by pas »

richdougherty wrote: post #26
joelhaasnoot wrote: post #20

Earlier quoted context omitted.

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?

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

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

#58

Post by sandGorgon »

haneefmubarak wrote: post #33
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.

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.

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

#59

Post by pjmlp »

nly wrote: post #53
pjmlp wrote: post #44

Earlier quoted context omitted.

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

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.

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

#60

Post by pjmlp »

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…

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.

Post reply on HN