
Android Is a Dead End - MBCook
http://www.osnews.com/story/29924/Android_is_a_dead_end
======
chickenbane
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 author even acknowledges this. You might
as well say given enough time Linux itself is a dead end.

What Android is is what Andy Rubin originally said it would be - an open
source mobile operating system. And I doubt this will be a dead end any time
soon, certainly not in our lifetimes. Important libraries and frameworks
themselves will be improved and replaced as they have been for many years now,
and yes perhaps Linux itself will be succeeded. But why would anybody care,
especially if its transparent to users and even to developers (I'd imagine
maybe a Linux emulation mode for NDK users.) To me, this sounds like a healthy
project, which is sort of the opposite of a dead end.

~~~
millstone
> 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 replaced, a la
Theseus's ship. So what is Android - what can't be replaced?

The answer is the development model. This can't be replaced because it's
definitional to Android. You said it yourself: Android is "an open source
operating system." More specifically, it's an open source OS that follows a
particular development model:

1\. Development of mainline Android happens behind Google's closed doors, and
is thrown over the wall to OEMs. 2\. Development of Android for particular
devices happens behind OEMs closed doors, and is thrown over the wall to
customers.

#2 is the rub. It annoys customers, who have to wait to get updates and fixes.
It annoys developers due to the fragmentation problem. And it annoys Google
because they don't control the update cycle, and instead have to shoehorn
things into Google Play Services, etc. But critically it doesn't annoy OEMs,
who love being able to apply their kernel "fixes," shovelware, and other
familiar Android condiments.

Google would love love love to transition to a ChromeOS-like model, where they
can exercise a lot more control. But they can't just do that outright - OEMs
would revolt. They probably can't do it at all within the confines of Android
and the development model they've established. That's their key problem.

> But why would anybody care, especially if its transparent to users and even
> to developers

It won't be. There is no universe where Google can provide a new OS that works
on all their customers devices and supports all the apps. The best they can
hope for is a new OS with a compatibility layer that works well enough - think
Apple's transition from classic Mac OS to OS X.

But as soon as OEMs get wind of those, you can bet they'll be tripling-down on
Tizen or forks or whatever. That's the dilemma that Google finds itself in.

Android is a sort of asymptotic dead-end, where Google can keep providing
fixes like Dalvik->ART, but those can't address the essential problems.
Eventually those problems will be severe enough to open a space for a new
offering to thrive. Google hopes to own that offering, cannibalizing Android
instead of letting someone else eat it.

(Oh, but then there's China...)

~~~
hota_mazi
> Development of mainline Android happens behind Google's closed doors, and is
> thrown over the wall to OEMs

You don't know much about Android, do you?

Here's Android: [https://github.com/android](https://github.com/android)

Developed behind closed door? I don't think so.

Maybe you meant iOS, though? Because that OS is certainly being developed
behind closed doors.

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

~~~
hota_mazi
Ok.

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

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

------
remir
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,
unable to talk to each other, requiring new account for each of them, entering
your credit card again and again. It's terrible.

Now let's say you want to order pizza. Instead of downloading yet another app,
you could just type "order pizza" in the search box and an interface is
created by the OS and you can chose the pizza place you want, toppings, etc,
and the OS handles everything (adresse, payments).

AI is getting more and more capable and I think we reached the end of the _"
There's an app for that"_ era. Can Android evolve to this post-app paradigm? I
don't think so. Same thing with iOS.

That's why, I think, Google is working on Fuchsia.

~~~
hota_mazi
> you could just type "order pizza"

"Type"? What year is this, 2005?

That's a surprisingly narrow view of what the future looks like.

Today, you can already ask your phone "order pizza" and it will do just that.
Whether it's done by an app or an intent or a web site is irrelevant: it just
works.

Which is why the OP article "Android is a dead end" is so preposterous. There
is no analysis, no reasoning, no evidence. Just a silly claim that criticizes
the OS used by 80% of the phones in the entire world for simple click baiting.

~~~
BenjiWiebe
The year is 2017, and speech to text still isn't perfect.

~~~
hota_mazi
And it will never be.

For English, and this kind of specific sentence, it's above 99%, though. Good
enough for you?

What you are doing is called the Nirvana fallacy. Look it up, and stop doing
it.

~~~
BenjiWiebe
I actually meant more the speed rather than the accuracy. At least on my
phone, it takes a fair bit longer to listen to me and process my voice than to
swipe in two words.

------
Animats
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 given up.

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

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

------
mrkrabo
So... there's absolutely no proof of what this article says, other than the
existence of Fuchsia? Whose purpose we don't even know yet.....

------
0xbear
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, it is no surprise that there are so few
decent, non-trivial apps for it, and even Google's own apps work better on
iOS.

~~~
chickenbane
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 excellent updates, bugfixes, support,
libraries, frameworks, etc.

Not to bash on Swift, but even with the incoming Swift 4 they still don't even
have an ABI compatibility story (leading to bigger apps since they to bundle
the runtime, and framework/library devs can't offer binaries), and they even
had to break source compatibility (though the compiler will have a flag to
compile Swift 3). And since most Android app development actually depends on
the Android Support Libraries, you can provide great compatibility to current
devices. Whereas - and this is according to iOS devs - supporting the latest
version of iOS usually means abandoning supporting previous versions. Also, I
heard the newest xcode 9 just got refactoring support - cute!

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

------
hota_mazi
Pretty silly.

Let's take a look at the landscape:

\- Windows Mobile: irrelevant market share, closed source.

\- iOS: 10-20% market share depending on the country, closed source.

\- Android: 80-90% market share. Based on Linux, open source.

I know who I'm rooting for.

------
jayd16
> over the coming two to three years, Android will undergo a radical
> transformation. This transformation will be mostly transparent to users -
> their next Android phone won't actually be "Android" anymore, but still run
> the same applications, and they literally won't care - but it won't be a
> Linux device, and it won't suffer from Android's core problems.

How laughable. Google can't even get most users on a two year old upgrade let
a loan an entire rewrite.

------
RandyRanderson
createArticle(template='IsDead', target=buzzwordList.get(random()))

------
pasbesoin
Apple's iPhone is central to the product/value they deliver. And it's treated
as such by Apple.

Google's Android is not. They deliver ads, and now some services that don't
depend on ads. They needed to keep the channel open for these, in the face of
a mobile transition that could otherwise be dominated by Apple and maybe
Microsoft. Thus, Android.

Of course, this was also back when Google was still willing to really take a
flyer on something.

------
Apocryphon
Surprised at the lack of comments about how Kotlin might help the situation.

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

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

------
thebiglebrewski
"X Is Dead"

straight to the front page with this one!

I, for one, love my Google Pixel :)

------
hoodoof
Seems to me the long standing "Java is slow" versus "that's an old wives tale,
Java software can be as fast native" all converges right down to the evidence
of Android - compared to iOS, it's slow. If Java was just as fast then this
would never come up.

~~~
axaxs
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 world, it's a -lot- of overhead.
The same is true in smartphones...we have a huge memory use problem in
Android. It may be 'performant', but it's still a resource dog.

~~~
amelius
> people just aren't that into VMs anymore

Bytecode can be translated quite well to native code. So I'm wondering if this
isn't about "VMs versus native" as much as it is about "garbage collected
versus unmanaged memory".

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

~~~
gizmo686
>What's an example of an ahead-of-time compiler that takes bytecode and spits
out native code?

I believe that is how .NET works (the byte code gets distributed, and the user
compiles it to native immidietly before execution).

Also, Android's ART is the replacement for Dalvik that compiles Dalvik
bytecode into native code at installation.

~~~
jayd16
Actually, ART is now "JIT guided AOT." The JIT will (re)compile code as needed
but the JIT code is stored to disk, thus creating an AOT binary on future
runs.

