Google previews next version of Android, codenamed “L release”

Move over KitKat, a new version of Android is coming.

Read the whole story

 

[gbjbaanb]

So why didn't they go the whole hog and make the ndk the preferred development tooling? Would have saved so much bother all along.

 

[brendanlong]

redleader[/url]":1welf7pb]

qazwart[/url]":1welf7pb]Is ART open source?

Yes, you can download the source right now:

https://android-review.googlesource.com ... atform/art

That's the code review site. The git repo is here:

https://android.googlesource.com/platform/art/

And it's licensed under the Apache license:

https://android.googlesource.com/platfo ... ter/NOTICE

 

[BoogieWonderland]

sk3l[/url]":12ihrp25]

lewax00[/url]":12ihrp25]AOT compilation...also know as just compilation. Welcome to the Gentoo model?

Yes, but Gentoo's major benefit is that it also offers the "aggressive hardware optimization" option that was touted as part of JIT, so it's a slightly different paradigm.

From reading the article, I'd say that apps are compiled after downloading, optimizing for your hardware, so it seems to me as exactly the same paradigm as Gentoo. With the slight difference that in Gentoo you compile from source, while with ART you compile the Java bytecode.

 

[Danrarbc]

gbjbaanb[/url]":mypbllt7]So why didn't they go the whole hog and make the ndk the preferred development tooling? Would have saved so much bother all along.

Because then developers have to worry about all of the different platforms Android can run on. Do you limit yourself to ARMv6? What about x86? MIPS? Do you need to compile for the 64 bit variants of all of those platforms? It's a complicated world. Yes, Linux developers do it every day and have for years, but mobile development is expected to be easier.

 

[PlutoPrime]

Epitope[/url]":1kksnrug]The navigation icons are possibly the ugliest and non-intuitive icons I have ever seen. A circle now means home? A square represents multitasking?

The android design team has to do this, otherwise Apple would've owned the color white, and the shape "circle". Two design elements that are impossible to improve upon (in this universe at least and with our laws of physics).

It's really a designers dilemma. Sometimes you have to copy because it's hard to improve upon perfection. But Google often applies perfection the same way Samsung releases products. They add some sticky spaghetti sauce and throw their bowl of "perfect" elements at the wall. On the bright side, at lease they can put "simple elegant shapes" on their spec sheet! Who cares if an ounce of thought was or wasn't put into where the shapes are used...

 

[alagemo]

The changing of the 'up' into a 'home' should make things simpler for users.

The square makes sense (I think), and does follow from the Playstation-style group. Having a multiple "window over window" ties it to a UI representation, rather than being abstract. Freeing it from that means it can work in other settings, like watches/cars.

 

[BullBearMS]

redleader[/url]":1tv2qako]

lewax00[/url]":1tv2qako]

tayhimself[/url]":1tv2qako]

academic.sam[/url]":1tv2qako]

ART switches to Ahead of Time (AOT) compilation, meaning the app is compiled once.

Cool.
... Goes on to do some AOT with gcc

Haha this is awesome, and I +1'd it but there is a difference between native and AOT that the wiki page details and I hadn't really thought about myself.

AOT in most cases produces machine optimized code, just like a 'standard' native compiler. The difference is that AOT transforms the bytecode of an existing virtual machine into machine code.

http://http://en.wikipedia.org/wiki/AOT_compiler

From my understanding, LLVM basically works this way too: generate VM code, then generate native code from that. So you just distribute the intermediate step instead of source code, and compile that per-user.

FWIW, ART actually uses llvm.

There is something amusing about Android switching over to Apple's compiler toolchain after years of hearing that Dalvik was not the reason for Android performance problems and memory bloat.

 

[Kazper]

I'm loving ART. Have been using it on my Nexus 5 for about a month with no problems - and massive performance improvement. But switching from a JIT compiler to an AOT compiler is not something you do lightly when your product is entirely dependent on said compiler. I imagine this has been underway for a while.

 

[BullBearMS]

Kazper[/url]":1hdp2yku]I'm loving ART. Have been using it on my Nexus 5 for about a month with no problems - and massive performance improvement. But switching from a JIT compiler to an AOT compiler is not something you do lightly when your product is entirely dependent on said compiler. I imagine this has been underway for a while.

Quite some time

http://meincmagazine.com/gadgets/2013/10/ ... r-android/

 

[uhuznaa]

I can't quite put my finger on it but I have seen this new color scheme somewhere lately...

But I like it and I also like the new button shapes.

 

[wien]

Danrarbc[/url]":3rkdyooo]Yes, Linux developers do it every day and have for years, but mobile development is expected to be easier.

As a "mobile developer" up to his friggin neck in broken tools, constantly changing APIs, wildly differing hardware capabilities and pointlessly complex deployment platforms... HAH!

 

[Boreas]

jdale[/url]":2ntmqxkq]

GodsMadClown[/url]":2ntmqxkq]I'm trying to think of candies that start with L.

Lolipop
Licorice
Laffy Taffy
Lemon Heads
Lifesavers

Any more?

I assume it's "L" as in "we haven't found a sponsor for this version yet, but after making money on what we called K we are certainly going to keep trying."

I'm assuming that the alliterative candy names were Rubin's thing, and that Pichai put an end to it. Perhaps it's not the sort of image they want to cultivate moving forward. Perhaps it underlines a further move away from the open source model for Android, and towards a more straight-laced, conventionally corporate future.

edit: Because "L release" is clearly the name. Normally, they'd have called it "lollypop" or whatever by this point.

 

[excessivelime]

BullBearMS[/url]":2darom83]

There is something amusing about Android switching over to Apple's compiler toolchain after years of hearing that Dalvik was not the reason for Android performance problems and memory bloat.

LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

 

[jamiahx]

With ART, Google ships uncompiled code through the Play Store and compiles it at install time.

So Android is reverting back into Gentoo? Why did they even remove this feature in the first place?

 

[BestUsernameEver]

CrookedKnight[/url]":1gnr1xsc]So how many apps that are no longer being updated will be broken by the switch to ART? Looking at what's on my phone a decent amount of software that I still use weekly is dated 2013 or even 2012 in the Play store.

I've used the experimental preview in KitKat all along. Except for gapps it didn't break anything. Unfortunately, Google Play Services force closes A LOT in the background. I can't tell any difference in performance though with normal usage.

 

[sk3l]

BoogieWonderland[/url]":3fk0kq8f]

sk3l[/url]":3fk0kq8f]

lewax00[/url]":3fk0kq8f]AOT compilation...also know as just compilation. Welcome to the Gentoo model?

Yes, but Gentoo's major benefit is that it also offers the "aggressive hardware optimization" option that was touted as part of JIT, so it's a slightly different paradigm.

From reading the article, I'd say that apps are compiled after downloading, optimizing for your hardware, so it seems to me as exactly the same paradigm as Gentoo. With the slight difference that in Gentoo you compile from source, while with ART you compile the Java bytecode.

AFAIK AOT typically does not involve performing any hardware-specific tuning.

From the article:

Traditionally, JIT takes longer to start up but can be more aggressively optimized because it has information about the device it is running on. AOT will start up faster, but it usually has less information about the hardware it's running on.

Gentoo's optimizations are like those attributed to JIT, i.e. hardware-specific. You can actually tune the compiler based on the footprint of the processor, registers, cache and its instruction set.

With AOT, the compilation target is presumably not manipulated in such a fine-grained manner. It's just like compiling std C++. It will be portable, but may not take advantage of all the bells and whistles of the underlying hardware.

 

[BullBearMS]

excessivelime[/url]":1dv2qg2v]

BullBearMS[/url]":1dv2qg2v]

There is something amusing about Android switching over to Apple's compiler toolchain after years of hearing that Dalvik was not the reason for Android performance problems and memory bloat.

LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

The lead developer behind LLVM has been on Apple's payroll for the better part of the last decade. Apple hired him right out of college.

In late 2000, Lattner joined the University of Illinois at Urbana-Champaign as a research assistant and M.Sc. student. While working with Vikram Adve, he designed and began the implementation of LLVM, an innovative infrastructure for optimizing compilers, which was the subject of his 2002 M.Sc. thesis. He completed a Ph.D. in 2005, researching new techniques for optimizing pointer-intensive programs and adding them to LLVM.

In 2005, Apple Inc. hired Lattner to begin work bringing LLVM to production quality for use in Apple products. Over time, Lattner built out the technology (personally implementing many major new features in LLVM), formed and built a team of LLVM developers at Apple, started the Clang project, took responsibility for evolution of Objective-C (contributing to the "blocks" language feature, and driving the ARC and Objective-C literals features), and nurtured the open source community (leading it through many open source releases).

Lattner's recent work involves designing, implementing, and evangelizing the LLVM and Clang compilers, productizing and driving LLDB, and overseeing development of the low-level toolchain. LLVM technologies are currently the core of Apple's developer tools, the default toolchain on FreeBSD, and may eventually replace GCC, GDB, and Binutils in other contexts in the future.

http://en.wikipedia.org/wiki/Chris_Lattner

He's also behind OpenCL and most recently Apple's Swift programming language.

 

[sk3l]

I went back & re-read the article, after seeing it touched on here in the comments, particularly the part mentioning that the Google-fied implementation of AOT (ART or whatever) does actually produce a compilation output, from source, using the hardware profile of the target machine. So, I'll have to retract what I said earlier rebutting the comparison between this ART and Gentoo. They do appear to have similarities when it comes to their manner of optimization.

 

[Cyric]

L could be Liquorice.

 

[pixel4e]

Lettuce
Lasagna
Linguine
Lamb
Lima Beans

 

[Shannara]

It looks like Android kidnapped that mental person who designed metro. Seriously... I can throw up on phone and it would look better than this android metro.

 

[Danrarbc]

pixel4e[/url]":3b3bii8l]Lettuce
Lasagna
Linguine
Lamb
Lima Beans

None of them are sweet.

 

[RCook]

I like that there is an early release of 'L', hopefully this mean that ROM developers can start the process of customising the ROM now so that when it's ready to go the roll out is much faster. It would be nice to have a CM12 ready to go the same day that the official L version is ready.

 

[vassago]

Lychee

 

[Zero2360]

Being release some time this fall...

hmmn.. so i just got an OS update on my nexus a few minutes ago.. something different? guess i'll keep reading.
lots of cools stuff though.

 

[grrrr]

lloeki[/url]":18e16z5k]

academic.sam[/url]":18e16z5k]I would really wish for some CLR (a la Microsoft) type approach which would support multiple languages. Just hate programming with Java and it is sapping my motivation to write some apps that are useful for me.

Fundamentally there's no difference, really. Java becomes byte code which then get exec/JIT'd/AOT'd. Replace Java with any other language (e.g JRuby, Scala, Clojure) and it works.

Only that for a language like scala, because of the java / dalvik / art runtime, it seems impossible to get something like tail call elimination right which is pretty fundamental for a language like that.

 

[rex86]

Nice. Google just found a way to sell everyone a watch. Overall, this might be one of the best Android versions ever.

 

[Danrarbc]

RCook[/url]":3kwdj5mk]I like that there is an early release of 'L', hopefully this mean that ROM developers can start the process of customising the ROM now so that when it's ready to go the roll out is much faster. It would be nice to have a CM12 ready to go the same day that the official L version is ready.

Not going to happen without source code. ROMs will still be made, but they'll be limited in what they can do.

Zero2360[/url]":3kwdj5mk]Being release some time this fall...

hmmn.. so i just got an OS update on my nexus a few minutes ago.. something different? guess i'll keep reading.
lots of cools stuff though.

Probably 4.4.4 - KitKat still.

 

[alxx]

academic.sam[/url]":2gzsnif2]I would really wish for some CLR (a la Microsoft) type approach which would support multiple languages. Just hate programming with Java and it is sapping my motivation to write some apps that are useful for me.

? You don't have to write in java.
Use one of the many third party tools that will let you use a lot of other languages.

Could code using c# and clr if you want to and compile to both android and ios - tools aren't free though
Either xiamin or unity3d http://unity3d.com/learn/documentation

Can write in lots of languages - delphi , javascript , c , c++ , python, erlang , scala , lua etc etc
http://stackoverflow.com/questions/1994 ... oid-dalvik
http://stackoverflow.com/questions/3316 ... in-android . Not all tools are free though

Personally I'd love to be able to write apps in python for both android and ios but
only android at the moment (more of a QT app than plain python)
https://ep2013.europython.eu/conference ... -in-python

 

[tdlf]

What could be really cool about ART is that since it's based on LLVM, if Apple releases Swift as an open standard (and I don't see any major reason they wouldn't), we might be able to program Android apps in Swift.

 

[Walt French]

excessivelime[/url]":19fo047l]…LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

You might better quibble about the implication that it's “only Apple's compiler toolchain.” It certainly is essentially the only tool for Apple OS development; also, their contributions to it are consistent with their reliance on it.

But LLVM is definitely the compiler toolchain for the huge majority of Apple's 9 million developers.

 

[Kasoroth]

Lemon cakes!

 

[CaptainTightpants]

uhuznaa[/url]":38zhgvx5]I can't quite put my finger on it but I have seen this new color scheme somewhere lately...

But I like it and I also like the new button shapes.

Kinda reminds me of Novell's retail boxes back in the day...

 

[Zarsus]

Walt French[/url]":1cbw71pw]

excessivelime[/url]":1cbw71pw]…LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

You might better quibble about the implication that it's “only Apple's compiler toolchain.” It certainly is essentially the only tool for Apple OS development; also, their contributions to it are consistent with their reliance on it.

But LLVM is definitely the compiler toolchain for the huge majority of Apple's 9 million developers.

And this is relevant how?

 

[Comment Zilla]

immunizer[/url]":38e8xtd3]Just what we need: 5,000 new APIs.

5,000 API x 1000 phone variations

 

[SNico]

I use both Android and iOS. I develop apps for both platforms. I watched the June Apple keynote and I was jumping on my seat. I watched the Google I/O and half way through the presentation of L... I fell asleep.

 

[BullBearMS]

Zarsus[/url]":2e1539ns]

Walt French[/url]":2e1539ns]

excessivelime[/url]":2e1539ns]…LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

You might better quibble about the implication that it's “only Apple's compiler toolchain.” It certainly is essentially the only tool for Apple OS development; also, their contributions to it are consistent with their reliance on it.

But LLVM is definitely the compiler toolchain for the huge majority of Apple's 9 million developers.

And this is relevant how?

Ditching Dalvik for Apple's compiler toolchain yields a 2X speedup for apps and significant memory savings, according to Google.

They also called out significant improvements in garbage collection.

 

[tragiclifestories]

Zarsus[/url]":1n16opxy]

Walt French[/url]":1n16opxy]

excessivelime[/url]":1n16opxy]…LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

You might better quibble about the implication that it's “only Apple's compiler toolchain.” It certainly is essentially the only tool for Apple OS development; also, their contributions to it are consistent with their reliance on it.

But LLVM is definitely the compiler toolchain for the huge majority of Apple's 9 million developers.

And this is relevant how?

I suspect the idea is that google's adoption of LLVM amounts to an embarrassing climbdown from a NIH attitude - "look who's come crawling back", etc.

OT: I've not experienced any noticeable performance issues on my Nexus 5 (never owned any other android stuff), but if there's a battery life knock-on effect from ART, I will be most pleased.

 

[Zarsus]

BullBearMS[/url]":12tguiek]

Zarsus[/url]":12tguiek]

Walt French[/url]":12tguiek]

excessivelime[/url]":12tguiek]…LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

You might better quibble about the implication that it's “only Apple's compiler toolchain.” It certainly is essentially the only tool for Apple OS development; also, their contributions to it are consistent with their reliance on it.

But LLVM is definitely the compiler toolchain for the huge majority of Apple's 9 million developers.

And this is relevant how?

Ditching Dalvik for Apple's compiler toolchain yields a 2X speedup for apps and significant memory savings, according to Google.

They also called out significant improvements in garbage collection.

LLVM is a compiler toolchain, garbage collection is part of ART, which is not compiled using LLVM, therefore the improvement mentioned in GC's performance is not due to LLVM. Not to mention all the changes made to a performance focused runtime as opposed to space focused one.

Don't get me wrong, LLVM is a nice technology, but you are attributing unrelated improvement to it.

 

[Zarsus]

tragiclifestories[/url]":vqkwxu4x]

Zarsus[/url]":vqkwxu4x]

Walt French[/url]":vqkwxu4x]

excessivelime[/url]":vqkwxu4x]…LLVM has been around for years now (project started back in the early 2000's at the University of Illinois). I don't think it's accurate to call it "Apple's compiler toolchain" simply because they're the most prominent organization using it.

You might better quibble about the implication that it's “only Apple's compiler toolchain.” It certainly is essentially the only tool for Apple OS development; also, their contributions to it are consistent with their reliance on it.

But LLVM is definitely the compiler toolchain for the huge majority of Apple's 9 million developers.

And this is relevant how?

I suspect the idea is that google's adoption of LLVM amounts to an embarrassing climbdown from a NIH attitude - "look who's come crawling back", etc.

OT: I've not experienced any noticeable performance issues on my Nexus 5 (never owned any other android stuff), but if there's a battery life knock-on effect from ART, I will be most pleased.

Not really, Android started life back in 2003 and Apple itself only made LLVM the default compiler for XCode 4 circa 2011, I hardly find it to be a case of NIH. Also, those AoT generated code would have to be stored somewhere, and considering how I had to check for apps to delete every damn week with my Nexus One, using AoT was probably not a very good idea for a large part of Android's life.