>> Android is Linux on the phone. It's Linux kernel with stuff on top.

Android is just the Linux kernel on the phone -- that's the issue I have with it. It comes with none of the other stuff that makes GNU/Linux great: philosophically/socially it's different, but on a technical level it's missing rest of the GNU/Linux stack (e.g. package management, and the plethora of developer tools -- including languages and libraries). The GNU/Linux stack is developed by a diverse ecosystem of contractors, big and small business, and non-for-profits (e.g. Red Hat, Intel, Mozilla, Samsung, Canonical, Document Foundation, Fujitsu, Google, etc). Android is largely controlled by one company.

The lack of package management and standard kernel/modules is a huge issue from Android. It keeps it from being truly open. I wrote a post about this a while ago:

http://penguindreams.org/blog/android-fragmentation/

The TL;DR, Android needs to be fixed so ASOP can be installed on any phone, just like Linux/Windows. The current state is bizarre for what's essentially now a general purpose operating system.

I think you mean AOSP (Android Open Source Project) not ASOP (the linked article makes the same typo).

Wow...I even spelled it out at one point and still screwed it up while abbreviating it! Thanks man. I'll fix it. :)

I habitually think of it as 'aesop' of the fables fame in my head, even though I know it's inaccurate. Hard habit to break. Like eye-terator instead of it-erator.

And with Brillo and Fuchsia, Google is removing whatever is left of it.

What is Brillo taking away? I thought it was more a standardization of the HAL and Linux kernel?

Imagine Android with the Java Frameworks replaced by a similar C++ Framework, using Android IPC (not UNIX), bionic libc and Android's own Linux kernel fork.

https://www.youtube.com/watch?v=ig9GKAFzDxQ

https://www.youtube.com/channel/UCthvmTSlmIcMH93LIJNe-2w/sea...

Is Tizen any closer to this?

I honestly don't know what's happening with Tizen these days -- Samsung has invested money into it, but it has (IMO) very little to show. Again, my bias is showing, but I think Jolla (SailfishOS) and Canonical (Ubuntu Touch) have achieved infinitely more with smaller teams and less capital.

From what I've read, you want as little as possible to do with Tizen:

https://what.thedailywtf.com/topic/15001/enlightened

Taking away those things doesn't make it not Linux. Adding those things wouldn't make it not Android. These guys could have had the best of both worlds.

He didn't say anything about it not being Linux; he said it isn't GNU/Linux, which it isn't, the GNU parts are missing.

A lot of the things that he mentioned (package management, even development tools) don't necessarily require a GNU stack.

It is, and it isn't. Android has controversial patches on Linux that aren't merged upstream. They are more significant than say the patches Linux distributions maintain in their releases.

If anything, Android is a fork of Linux.

And the android UI framework is still garbage, having to freeze and thaw activity state just to handle screen rotation is the most insane thing I have ever heard of. Hell, even the various Symbians handled this better (I loved my Symbian S60 devices, but programming for them was an exercise in frustration).

I'm assuming you're referring to the behavior where activities are restarted on rotation and onSaveInstanceState() gets called.

This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework.

If you set android:configChanges="orientation" in your application manifest, your app won't be automatically restarted. However, you'll become responsible for swapping out any UI resources at that point.

(Keep in mind that Android lets you declare completely different UI layouts and drawables for different device configurations, so depending on how you wrote your app, you may need to re-inflate part of your UI.)

Or just implement onSaveInstanceState() and let the OS do everything for you.

>This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework.

No, the framework uses it to let you automatically handle those changes, the reason it's there is because early Android devices were weak (obviously) and the pipe dream was that we'd write apps that didn't mind randomly getting their processes killed as long as we used onSaveInstanceState... man-centuries later and it's clear the dream didn't pan out. I wonder how many billions of NPEs it was worth to be able to say Android does what iOS don't (multitasking) back then.

And that android:configChanges line misses out on many other triggers that cause you to need to handle onSaveInstanceState (like someone plugging in a keyboard). Even with every flag set for configChanges you still need to implement onSaveInstanceState for process death to work as intended.

The Android framework really is garbage. I might be biased though, I spent the day trying to trick it into not going to 7(!) FPS because our designers had the audacity to request we translate a video in an animation (and don't get me started on the insanity that is animations on Android [the X ways we've now gotten to do it which all have their own limitations]).

Yet both Windows Mobile and iOS handle this flawlessly without having to wire all sorts of extra code up. Sure, it's possible to do it with Android, but it's a hell of a lot more work than any other platform.

Android is not GNU

I think @maheart knows that and that is his main problem with Android.

Not really, there are lots of APIs missing from the NDK, UNIX IPC being a set of them.

Unfortunately it's also JVM [edit: Java] on the phone.

It is a fork of the Java language with its own AOT/JIT compiler, nothing to do with a certified JVM.

Larry Ellison doesn't seem to agree with your "nothing to do with [...] JVM" assertion, to the tune of a 9.3 billion USD lawsuit, and indeed Google itself is developing Fuchsia with no java stack at all in it.

Moreover, it's not Linux if you have to use a Java API to do anything useful.

Nothing to do from the point of view of the headaches that brings to those of us that care about Java.

And everything to do regarding being a fork on the Java ecosystem, and I side with Oracle.

It remains to be seen if Brillo or Fuchsia will have any relevance on the market, even when coming from Google.

and I'm not a java lover as you can tell, but I can super-appreciate that for java guys, having some fork that tries to be java-not-java and confuses the ecosystem, is a pain in the butt. Be java fully committed and move it forward, or leave java well alone. Don't sit there and create a java version of the Python 2/3 mess that screws everyting up. I can totally appreciate that. Well put.

The lawsuit was not about the VM.

Look. The gist of the comment is that Android forces you to use java, or at the very least, a java API. You can dance around semantics as much as you like, but it will not change the fact that, unlike Linux, Android is intricately interlinked with java.

It's a subset of Java, with a totally different compiler, JIT, etc. Newer versions don't even use Dalvic, but compile/cache the bytecode into ELF/machine code.

What does it matter what's underneath? At the visible layer which most of us have to use, it's java.