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

Android Is a Dead End

osnews.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Android Is a Dead End

#61

Post by chickenbane »

haberman wrote: post #29
axaxs wrote: post #4

Earlier quoted context omitted.

Java can be performant, but still typically has a huge footprint and memory profile. Others will point out that there are multiple implementations of Java, which is true, but to what adoption? IMO, the only thing propping up Java is legacy enterprise and Android. The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. They had a place in the self hosted world, but in the microservice/cloud…

A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image). Java on the other builds its process image on the heap, using the executable file as input. Nothing…

I have good news for you! Android (which never had a JVM) Lollipop replaced its old runtime Dalvik with ART, which is on around 1.5B devices. ART actually compiles Android's bytecode to ELF, though Android calls their variant OAT.

OAT, in turn, is a playful anagram of AOT, because what Android now does is even more powerful than the JVM or ELF. Android includes a JIT but it also does nightly profile guided optimizations. So not only does Android perform the preloading optimization you mention for ELF but as the user continues to use their apps Android will continue to optimize the compiled binaries.

Re: Android Is a Dead End

#62

Post by haberman »

chickenbane wrote: post #61
haberman wrote: post #29

Earlier quoted context omitted.

A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image). Java on the other builds its process image on the heap, using the executable file as input. Nothing…

I have good news for you! Android (which never had a JVM) Lollipop replaced its old runtime Dalvik with ART, which is on around 1.5B devices. ART actually compiles Android's bytecode to ELF, though Android calls their variant OAT. OAT, in turn, is a playful anagram of AOT, because what Android now does is even more powerful than the JVM or ELF. Android includes a JIT but it also does nightly profile guided optimizati…

Good to know. Does that mean Java classloaders are not supported on Android? And does this approach require breaking compatibility with that aspect of the Java spec?

Re: Android Is a Dead End

#63

Post by mgkimsal »

millstone wrote: post #40
chickenbane wrote: post #21

This is a very confusing argument. The summary seems to be Android defined as "a Linux kernel with libraries" is a dead end. Well, okay, although given its deployment on 2B devices it's probably the best argument for Linux. A couple of years ago Android replaced Dalvik, the runtime for all apps. Did anyone say Android is a dead end then? Nobody defines Android in this way, by a single component, and in a way the auth…

> Well, okay, although given its deployment on 2B devices it's probably the best argument for Linux. One could have said more or less the same about Symbian not that long ago. > Nobody defines Android in this way, by a single component, and in a way the author even acknowledges this. That's right, it's not defined by any particular software component. Any particular component can be replaced until the whole thing is…

> OEMs would revolt

but.. where would they go? what other options do they have, realistically?

> you can bet they'll be tripling-down on Tizen or forks or whatever

really? i'm just not that sure. I think many OEMs would happily give up all the engineering expense/effort they carry right now to compete in what is essentially a commoditized market.

Re: Android Is a Dead End

#64

Post by MikusR »

mgkimsal wrote: post #63
millstone wrote: post #40

Earlier quoted context omitted.

> Well, okay, although given its deployment on 2B devices it's probably the best argument for Linux. One could have said more or less the same about Symbian not that long ago. > Nobody defines Android in this way, by a single component, and in a way the author even acknowledges this. That's right, it's not defined by any particular software component. Any particular component can be replaced until the whole thing is…

> OEMs would revolt but.. where would they go? what other options do they have, realistically? > you can bet they'll be tripling-down on Tizen or forks or whatever really? i'm just not that sure. I think many OEMs would happily give up all the engineering expense/effort they carry right now to compete in what is essentially a commoditized market.

Windows mobile.

Re: Android Is a Dead End

#65

Post by akmarinov »

chickenbane wrote: post #60
0xbear wrote: post #30

Don't know if it's a dead end or not, but both the apis and the developer tools are a massive clusterf#%k compared to Apple and Microsoft. Just one head scratcher after another, especially if you dare to support older versions. In comparison, Apple has a relatively pain free API, and lets you access it with one of the most elegant languages I've ever programmed in (Swift). After delving into Android just for a bit, i…

Interesting POV, but I'd much rather develop for Android than any other platform. You are correct that currently developing for Android is not for the faint of heart. Happily, it also turns out understanding Java and Gradle and IntelliJ is generally useful for a software engineer and let me develop for many more targets and vendors than one. And since all the components are all open source, the community can provide…

Your argument is moot, if you replace Swift with Objective C. Also you don't have to abandon previous iOS versions to support the latest, it just doesn't make sense to when 90% of the users are on the latest.

Re: Android Is a Dead End

#66

Post by joselreyes »

remir wrote: post #35

I would say apps are at a dead end. The way we are using our mobile devices with rows and rows of single purpose apps seems so... primitive now. I mean, you need "Pizza Place" app to order pizza, "TicketMaster" app to order concert tickets, "HotelWhatever" app for hotel reservation, "Parking Meter" app, "Fitness" app, "News" app, etc... Like I said; rows and rows of information silos taking place on your phone, unabl…

Having to create and track separate identities for each app, particularly transactional/infrequently used apps, does indeed seem dated. But I think it’s a mistake to confuse the identity issue with apps as a whole.

AI won’t solve every use case. There will always be a need for experiences tailored for niche needs in productivity/creativity, utilities, entertainment, etc.

Re: Android Is a Dead End

#67

Post by justinv »

hota_mazi wrote: post #54
millstone wrote: post #51

Earlier quoted context omitted.

I am sorry to inform you that Google engineers are not doing their daily pushes to github.com/android. Yes, Android is developed behind closed doors. Primary development occurs with a Google-private repository, and only made public at or near the point of a release. This is different from the way Chrome, ChromeOS, Linux, Swift, etc. are developed, where primary development occurs in the open.

Ok. So how do iOS and Windows Mobile fare in your opinion?

When did the OP ever mention iOS or Windows Phone being OSS? They've never claimed to be either.

Re: Android Is a Dead End

#68

Post by YZF »

jayd16 wrote: post #38
YZF wrote: post #12

Earlier quoted context omitted.

What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? Can you do inline assembly for the target architecture? I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened. High performance code is written in AOT/native languages.

>I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened. Why do you say this? There's lots of examples out there and Android is one of them.

How is an Android an example? What AOT are we comparing to here?

Re: Android Is a Dead End

#69

Post by tatersolid »

ponizibio wrote: post #6

Android is slow? that's news to me. Been using Android for years.

Try out an iPhone for real world use.

I did the opposite. Android is extraordinarily slow ("feels unresponsive") even on high end hardware compared with a comparable iPhone. I had to use a Galaxy S8 for a spell at work and every non-keyboard tap seems to generate a half-second-plus delayed response.

I actually thought something was wrong (malware on a recycled company device?) and wiped the phone, installed all patches, and... still slow as hell despite the hardware that is 4x more powerful than my iPhone 6S.

It's as if they somehow ported the as-yet-unfixed lagginess of all Linux desktop managers to the phone on purpose, because they didn't know the world could be better.

And no, I'm not a fanboy, my phone is my only iThing. And no, there was no MDM or AV installed on the phone by my company that caused this lagginess.

Re: Android Is a Dead End

#70

Post by on_and_off »

nextInt wrote: post #23
Animats wrote: post #14

Extend, engulf, devour. Most of the comments here miss the point of the article. The article author is saying that Google will replace the Linux component of Android with something proprietary. Then Google will have total control, and will be able to prevent Android clones. Already, Android apps make such heavy use of Google proprietary code that open source Android systems such as Cyanogen and FDroid have mostly giv…

Except that the only evidence provided is Fuschia which is open source

Also, how does google prevent Samsung & co from taking over the AOSP codebase ?

Sure they could add rules to the "Google Play agreement for Fuchsia" but they are already in hot water because of the current Play Store contracts.

Post reply on HN