4 ms·

The Guts of Android

121 points by wallflower 15y ago

jschrf 15y ago
Nice summary. Two things that I find to be very nice/cool when developing for Android: - As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points. - The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use.
- jamesbritt 15y ago
  - As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points. Like Web sites. The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use. Almost RESTy. Except for the callback part. But using an app model that is similar to Web service and Web app development is quite handy.
  - martythemaniak 15y ago
    You know, when I first learned android development, its similarity to web development stuck me. Xml layouts (html), content resources (rest), the back button etc etc. I don't think its a coincidence or my web dev background
Roritharr 15y ago
The Intent system is indeed awesome, but Google seems to have forgotton something. How does a developer know all the possible intents? If i define a new intent, it isn't registered anywhere globally for other developers to use, so every app developer has to communicate it through some unofficial channel. There is some community work in that direction, i'd hope google would endorse it more: http://www.openintents.org/en/intentstable http://www.openintents.org/en/intentstable
- Zigurd 15y ago
  Google does document Intent constants that work with the standard application compliment of AOSP, and SDK add-ons typically document their Intent constants. An SDK add-on would be one way an app with a rich Intent interface could make that interface known in a more-formal way.
- GeneralMaximus 15y ago
  This is indeed a huge problem. My friends were once building an app that needed to talk to a bunch of other apps via intents. It required hours of reverse engineering and hit-and-trial to get it working. They gave up on it after a few weeks.
- mahmud 15y ago
  Intents are an open messaging system. The fact that they use java package names shows you they're meant to be user-extensible and infinite. Compare this to the bit-packing retardedness that is the Win32 message crackers[1]. Commercial software companies used it just like intents, and whenever you licensed "components" you got a print-out of all the magic constants the developers thought were available. Dammit, Java IS a better language than either C and C++ for application development. -- [1] Remember Me? MagicProc(HWND hwnd,WORD msg,WPARAM wParam, LPARAM lParam);
  - blub 15y ago
    So intents are just like D-Bus, except with fewer features, docs and used only on Android? By the way, from your statements you can at most conclude that the Java libraries are better than Win32.
    - mahmud 15y ago
      What do you mean fewer features? Intents are how everything is done. Android is basically four major components: Activities, Intents, ContentProviders and Services (Views are not really a components, just a nice hack which uses reflection & XML to make the GUI DOM-like .. but without having the foresight to allow for DOM-like manipulation -- why can't I configure layouts & content with xpath-like selectors?) Android has the cleanest architecture of any visual environment out there, bar none. D-Bus is far lower level than Intents (you can't send a D-Bus message to fire up the default "camera" application to take a picture, then fire up another message to the default "email" application sending the picture you just took as an attachment.) Java libraries ARE better than anything on win32. They're equally verbose, but java has better tooling, and it wears toddler gloves, so it doesn't scratch itself and doesn't gouge your eyes out while you feed it.
daemon 15y ago
Video of the talk can be found here: http://free-electrons.com/blog/abs-2011-videos/ http://free-electrons.com/blog/abs-2011-videos/
AretNCarlsen 15y ago
"It was a political decision not to use Busybox, rather than a technical one, he said." Anybody know what that means? Licensing conflict, perhaps?
- bostonvaulter2 15y ago
  It's probably because busybox is gpl
- cpeterso 15y ago
  GPL paranoia in part because: In late 2007, BusyBox also came to prominence for actively prosecuting violations of the terms of its license (the GPL) in US courts. https://secure.wikimedia.org/wikipedia/en/wiki/BusyBox https://secure.wikimedia.org/wikipedia/en/wiki/BusyBox
shareme 15y ago
Some important things are missing: For example in Android development we do not use java serialization but instead use a parcelable interface to store stuff and write to an android OS bundle to pass data between activities, etc as it is somewhat faster than java serialization.
reirob 15y ago
Very nice description of the Android architecture. I understand that all the applications have to be written in Java. But how did Firefox port its browser to Android? I doubt they have ported it from C++ to Java. At least from the article I do not understand what is necessary to write Android applications in non-Java languages. Can anybody please explain or give a link?
- koko775 15y ago
  What you're looking for is the NDK. Here: http://developer.android.com/sdk/ndk/index.html http://developer.android.com/sdk/ndk/index.html
  - nl 15y ago
    To expand on this - apps on Android do not need to be written in Java. To use the full Android SDK, you can write in any language that produces Java .class files (eg, Java, Scala, etc). However, if you are happy to work at a lower level you can use the NDK (= Native Developer Kit, linked in the parent), which lets you work in C with a fairly traditional Linux/C API. It also gives you access to OpenGL etc etc.
    - kelnos 15y ago
      [The NDK] also gives you access to OpenGL etc etc. The Java interfaces also give you this. Unfortunately, since OpenGL is mostly about making a ton of little function calls that build up a list of GL commands, it can be kinda slow since each call has to cross the JNI boundary. But it's performant enough for most things, and you can find your bottlenecks and drop down to native code where necessary.
dave1010uk 15y ago
Here's a nice diagram of the framework / structure of the Android / Linux libraries [1]. It's interesting to compare it to Nokia's Maemo [2] and Intel's MeeGo [3], which are much closer to a desktop Linux. I haven't been able to find a diagram for WebOS but expect it to be fairly similar. [1] http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android-architecture-485b.jpg http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android-a... (strange the 1st Google hit for this was on Nokia) [2] http://wiki.maemo.org/images/9/90/MaemoArchitecture.png http://wiki.maemo.org/images/9/90/MaemoArchitecture.png [3] http://www.99bits.com/wp-content/uploads/2010/09/meego-architecture.jpg http://www.99bits.com/wp-content/uploads/2010/09/meego-archi...
krosaen 15y ago
nice tour / deef dive. similar content in this 2008 google i/o talk, "anatomy and physiology of an android" http://www.youtube.com/watch?v=G-36noTCaiA http://www.youtube.com/watch?v=G-36noTCaiA

121 points by wallflower 15y ago

Nice summary. Two things that I find to be very nice/cool when developing for Android: - As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points. - The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use.

jamesbritt 15y ago
- As mentioned in the article, applications are bundles of components and have no specific entry point. To be more accurate, they have multiple entry points. Like Web sites. The Intent system. Not only does it provide an easy and robust way to integrate deeply with other apps, it also provides a simple IPC mechanism. Intents can be used to publish and subscribe to events between applications and are incredibly simple to use. Almost RESTy. Except for the callback part. But using an app model that is similar to Web service and Web app development is quite handy.
- martythemaniak 15y ago
  You know, when I first learned android development, its similarity to web development stuck me. Xml layouts (html), content resources (rest), the back button etc etc. I don't think its a coincidence or my web dev background

Roritharr 15y ago

The Intent system is indeed awesome, but Google seems to have forgotton something. How does a developer know all the possible intents? If i define a new intent, it isn't registered anywhere globally for other developers to use, so every app developer has to communicate it through some unofficial channel. There is some community work in that direction, i'd hope google would endorse it more: http://www.openintents.org/en/intentstable http://www.openintents.org/en/intentstable

Zigurd 15y ago
Google does document Intent constants that work with the standard application compliment of AOSP, and SDK add-ons typically document their Intent constants. An SDK add-on would be one way an app with a rich Intent interface could make that interface known in a more-formal way.
GeneralMaximus 15y ago
This is indeed a huge problem. My friends were once building an app that needed to talk to a bunch of other apps via intents. It required hours of reverse engineering and hit-and-trial to get it working. They gave up on it after a few weeks.
mahmud 15y ago
Intents are an open messaging system. The fact that they use java package names shows you they're meant to be user-extensible and infinite. Compare this to the bit-packing retardedness that is the Win32 message crackers[1]. Commercial software companies used it just like intents, and whenever you licensed "components" you got a print-out of all the magic constants the developers thought were available. Dammit, Java IS a better language than either C and C++ for application development. -- [1] Remember Me? MagicProc(HWND hwnd,WORD msg,WPARAM wParam, LPARAM lParam);
- blub 15y ago
  So intents are just like D-Bus, except with fewer features, docs and used only on Android? By the way, from your statements you can at most conclude that the Java libraries are better than Win32.
  - mahmud 15y ago
    What do you mean fewer features? Intents are how everything is done. Android is basically four major components: Activities, Intents, ContentProviders and Services (Views are not really a components, just a nice hack which uses reflection & XML to make the GUI DOM-like .. but without having the foresight to allow for DOM-like manipulation -- why can't I configure layouts & content with xpath-like selectors?) Android has the cleanest architecture of any visual environment out there, bar none. D-Bus is far lower level than Intents (you can't send a D-Bus message to fire up the default "camera" application to take a picture, then fire up another message to the default "email" application sending the picture you just took as an attachment.) Java libraries ARE better than anything on win32. They're equally verbose, but java has better tooling, and it wears toddler gloves, so it doesn't scratch itself and doesn't gouge your eyes out while you feed it.

daemon 15y ago

Video of the talk can be found here: http://free-electrons.com/blog/abs-2011-videos/ http://free-electrons.com/blog/abs-2011-videos/

AretNCarlsen 15y ago

"It was a political decision not to use Busybox, rather than a technical one, he said." Anybody know what that means? Licensing conflict, perhaps?

bostonvaulter2 15y ago
It's probably because busybox is gpl
cpeterso 15y ago
GPL paranoia in part because: In late 2007, BusyBox also came to prominence for actively prosecuting violations of the terms of its license (the GPL) in US courts. https://secure.wikimedia.org/wikipedia/en/wiki/BusyBox https://secure.wikimedia.org/wikipedia/en/wiki/BusyBox

shareme 15y ago

Some important things are missing: For example in Android development we do not use java serialization but instead use a parcelable interface to store stuff and write to an android OS bundle to pass data between activities, etc as it is somewhat faster than java serialization.

reirob 15y ago

Very nice description of the Android architecture. I understand that all the applications have to be written in Java. But how did Firefox port its browser to Android? I doubt they have ported it from C++ to Java. At least from the article I do not understand what is necessary to write Android applications in non-Java languages. Can anybody please explain or give a link?

koko775 15y ago
What you're looking for is the NDK. Here: http://developer.android.com/sdk/ndk/index.html http://developer.android.com/sdk/ndk/index.html
- nl 15y ago
  To expand on this - apps on Android do not need to be written in Java. To use the full Android SDK, you can write in any language that produces Java .class files (eg, Java, Scala, etc). However, if you are happy to work at a lower level you can use the NDK (= Native Developer Kit, linked in the parent), which lets you work in C with a fairly traditional Linux/C API. It also gives you access to OpenGL etc etc.
  - kelnos 15y ago
    [The NDK] also gives you access to OpenGL etc etc. The Java interfaces also give you this. Unfortunately, since OpenGL is mostly about making a ton of little function calls that build up a list of GL commands, it can be kinda slow since each call has to cross the JNI boundary. But it's performant enough for most things, and you can find your bottlenecks and drop down to native code where necessary.

dave1010uk 15y ago

Here's a nice diagram of the framework / structure of the Android / Linux libraries [1]. It's interesting to compare it to Nokia's Maemo [2] and Intel's MeeGo [3], which are much closer to a desktop Linux. I haven't been able to find a diagram for WebOS but expect it to be fairly similar. [1] http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android-architecture-485b.jpg http://www.forum.nokia.com/piazza/wiki/images/e/ef/Android-a... (strange the 1st Google hit for this was on Nokia) [2] http://wiki.maemo.org/images/9/90/MaemoArchitecture.png http://wiki.maemo.org/images/9/90/MaemoArchitecture.png [3] http://www.99bits.com/wp-content/uploads/2010/09/meego-architecture.jpg http://www.99bits.com/wp-content/uploads/2010/09/meego-archi...

krosaen 15y ago

nice tour / deef dive. similar content in this 2008 google i/o talk, "anatomy and physiology of an android" http://www.youtube.com/watch?v=G-36noTCaiA http://www.youtube.com/watch?v=G-36noTCaiA