8 ms·

Android is Linux on the phone. It's Linux kernel with stuff on top. Check out Replicant. It removes most of the stuff you might find objectionable.

by skrowl 10y ago

vegabook 10y ago
Unfortunately it's also JVM [edit: Java] on the phone.
- pjmlp 10y ago
  It is a fork of the Java language with its own AOT/JIT compiler, nothing to do with a certified JVM.
  - deleted 10y ago
    [deleted]
  - vegabook 10y ago
    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.
    - jsight 10y ago
      The lawsuit was not about the VM.
      - vegabook 10y ago
        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.
    - pjmlp 10y ago
      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.
      - vegabook 10y ago
        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.
- djsumdog 10y ago
  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.
  - vegabook 10y ago
    What does it matter what's underneath? At the visible layer which most of us have to use, it's java.
maheart 10y ago
>> 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.
- pjmlp 10y ago
  And with Brillo and Fuchsia, Google is removing whatever is left of it.
  - cpeterso 10y ago
    What is Brillo taking away? I thought it was more a standardization of the HAL and Linux kernel?
    - pjmlp 10y ago
      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/watch?v=ig9GKAFzDxQ https://www.youtube.com/channel/UCthvmTSlmIcMH93LIJNe-2w/search?query=brillo https://www.youtube.com/channel/UCthvmTSlmIcMH93LIJNe-2w/sea...
- jsight 10y ago
  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.
  - LukeShu 10y ago
    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.
_ZeD_ 10y ago
Android is not GNU
- AsyncAwait 10y ago
  I think @maheart knows that and that is his main problem with Android.
pjmlp 10y ago
Not really, there are lots of APIs missing from the NDK, UNIX IPC being a set of them.
xyzzy_plugh 10y ago
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.
snuxoll 10y ago
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).
- tjohns 10y ago
  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.
  - snuxoll 10y ago
    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.
  - BoorishBears 10y ago
    >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]).

Android is Linux on the phone. It's Linux kernel with stuff on top. Check out Replicant. It removes most of the stuff you might find objectionable.

by skrowl 10y ago

Android is Linux on the phone. It's Linux kernel with stuff on top. Check out Replicant. It removes most of the stuff you might find objectionable.

vegabook 10y ago

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

pjmlp 10y ago
It is a fork of the Java language with its own AOT/JIT compiler, nothing to do with a certified JVM.
- deleted 10y ago
  [deleted]
- vegabook 10y ago
  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.
  - jsight 10y ago
    The lawsuit was not about the VM.
    - vegabook 10y ago
      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.
  - pjmlp 10y ago
    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.
    - vegabook 10y ago
      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.
djsumdog 10y ago
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.
- vegabook 10y ago
  What does it matter what's underneath? At the visible layer which most of us have to use, it's java.

maheart 10y ago

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

pjmlp 10y ago
And with Brillo and Fuchsia, Google is removing whatever is left of it.
- cpeterso 10y ago
  What is Brillo taking away? I thought it was more a standardization of the HAL and Linux kernel?
  - pjmlp 10y ago
    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/watch?v=ig9GKAFzDxQ https://www.youtube.com/channel/UCthvmTSlmIcMH93LIJNe-2w/search?query=brillo https://www.youtube.com/channel/UCthvmTSlmIcMH93LIJNe-2w/sea...
jsight 10y ago
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.
- LukeShu 10y ago
  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.

_ZeD_ 10y ago

Android is not GNU

AsyncAwait 10y ago
I think @maheart knows that and that is his main problem with Android.

pjmlp 10y ago

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

xyzzy_plugh 10y ago

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.

snuxoll 10y ago

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).

tjohns 10y ago
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.
- snuxoll 10y ago
  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.
- BoorishBears 10y ago
  >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]).