Android is Client Java

One of the themes of Programming Android is that Android is now client Java. Client Java is what
every Java coder started with when they start learning Java, but then, when it gets down to working for
a living, it’s all server Java. Millions of coders are primed for a successful client Java, and many of
them work in enterprise IT. How will those millions of coders impact Android, and vica versa, how will
Android impact the work of Java coders?

This session will cover:

Android is client Java

Client Java was:

• Swing
• SWT
• JavaFX

Android is successful client Java

• Even before Android could be counted as a successful mobile OS, it had far more apps, with far
  more users, than other client Java technologies had ever produced.

The recipe for modern smartphone OSs:

• Linux or other embedded UNIX-like OS +
• Managed language runtime +
• Full-featured browser
  Examples:
• iOS
• Android
• Windows Phone
  Partial:
• Meego – more like Linux-goes-mobile
• Bada – C++ app runtime and APIs

Why was Android successful?

• Java: Be popular by being everywhere
  • Not native anywhere
  • Write once, test everywhere
• Android Java: Be popular by having lots of apps and users
  • Be really good in one place: The Android OS
  • And then…?
• Write the OS for the Java runtime
• Write the Java runtime for the OS and the apps you have in mind
  • It helps to be the second draft: Learned from Danger
    • Android’s implementation decisions are relatively mature

Android solves important Java problems:

• Multi-processing
  • Real multi-processing – multiple VM instances
  • Low memory overhead per instance
    • Sharable heap – copy-on-write
    • “Swap” – save component and process state
  • Security benefits from true multi-processing
    • Process per app
    • UID per publisher
    • Effective sandboxing of multiple publishers
• VM efficiency for mobile
  • Smaller bytecode
  • Faster bytecode
  • Mobile-tuned JIT compiler
    • Much less CPU/power-intensive than previous JIT compilers
    • Compiles much less code
      • Relies on efficiency of non-compiled code
• Modularity and code-sharing in a multi-processing Java environment
  • High-level simple IPC and code sharing
  • Low-level remote method calls
• Conclusion: Android is a large advancement over a one-runtime-with-variations-fits-all model

Android as client Java in practice:

• Android as a runtime, separate form an OS
• Sizing the problem:
  • 5000 JNIs
  • Some functional areas are the same as Java SE
  • Some are radically different
  • Some are somewhat dependent on Linux
• Can it be done?
  • Show Meego Tablet and Netbook UX running Android apps
    • App demos
    • Native integration:
      • Launching apps from Meego
      • Notifications
        • Binder use in Meego
    • Buying and installing apps
      • Demo new app install
• Show Android apps in Ubuntu
• Why?
  • Why do it? Why not just port Android OS
  • OEMs’ and carriers’ competitive situations
  • OEMs, carriers, and ecosystems

Conclusions:

• Android is a really good Java app runtime
• Android is substantially different from Java SE
• Android’s app runtime can be ported to other OSs
• This probably will happen in OEMs’ devices running non-Android OSs