I wonder why the Pixel C developer discount is us-only.
First Preview of Android N: Developer APIs and Tools
21–30 of 74 posts
Re: First Preview of Android N: Developer APIs and Tools
#22I 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.
Re: First Preview of Android N: Developer APIs and Tools
#23Besides 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…
Out of curiousity, where'd you hear this? I love learning low-level details like that.
Re: First Preview of Android N: Developer APIs and Tools
#24Earlier quoted context omitted.
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.
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.
Security fixes are reason enough.
Re: First Preview of Android N: Developer APIs and Tools
#25Earlier quoted context omitted.
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.
Sure, but ask yourself if that's a market you want to target. Do you care if digital signage terminals can run your app?
I really care if digital signage terminals can run my apps, because I sell digital signage terminals with these apps installed.
Re: First Preview of Android N: Developer APIs and Tools
#26Woah: >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…
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?
Re: First Preview of Android N: Developer APIs and Tools
#27Besides 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.
> Introduction of support to hardware keystores, with the mention that one use case is to prevent jailbreaking
This makes no sense, android already has hardware keystore support, jailbreaking is an ios term, and this is not mentioned anywhere in the lost...?!
Re: First Preview of Android N: Developer APIs and Tools
#28Earlier quoted context omitted.
Sure, but ask yourself if that's a market you want to target. Do you care if digital signage terminals can run your app?
I really care if digital signage terminals can run my apps, because I sell digital signage terminals with these apps installed.
Ok, fair enough. I see now in your comment,
the part of the Android market I actually care about
Don't know if I wasn't paying enough attention when I replied, or if you ninja-edited, but that's certainly relevant context.
Re: First Preview of Android N: Developer APIs and Tools
#29Earlier 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…
Out of curiousity, where'd you hear this? I love learning low-level details like that.
developer.android.com and the Android Developer blog are good sources apart from XDA, G+ for various Android low level devs - this particular one came from - http://developer.android.com/preview/api-overview.html
Re: First Preview of Android N: Developer APIs and Tools
#30I 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.
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.