Bringing Firefox to Android
June 14th, 2011
First, some background
First, some background
Why?
First, some background
Why?
  • Bring browser add-ons to mobile devices
First, some background
Why?
  • Bring browser add-ons to mobile devices
    • Drastically increases opportunities for innovation
First, some background
Why?
  • Bring browser add-ons to mobile devices
    • Drastically increases opportunities for innovation
  • Increased competition drives the web forward
First, some background
Process separation
  • Primary motivation is chrome responsiveness
    • Browser UI always reponsive to user input even with JS-heavy sites
    • Constant-rate panning and zooming
  • Also provides stability
    • App can continue to run if content crashes
First, some background
Terminology
  • Chrome - the browser UI
  • Content - the web page
  • Gecko - Mozilla's rendering engine
  • User Agent - essentially, the browser
Some challenges along the way
  • Native app on Java platform
  • Multi-process application
  • Library loading
  • Fitting in on the platform
  • NPAPI Plugins (like Flash)
Native App on a Java Platform
Problems
  • No native windows
  • Lack of native APIs
    • All system calls must be "translated"
  • No control of message loop
Native app on Java platform
Solutions
  • Simple" Java app with SurfaceView
  • SurfaceView passed to Gecko
  • Gecko draws to ByteBuffer (or OpenGL Surface)
  • GeckoAppShell class has static methods for OS access
    • Clipboard access
    • Audio API
    • File-picker
    • IME interactions
    • Alerts/Notifications
Two "main" threads (in chrome)
Communication between chrome threads
Multi-process on Android
  • Child processes don't inherit all parent process's privileges
  • No JNIEnv in content process
    • Certain OS-level functions must be "remoted"
      • Clipboard access
      • Audio API
      • File-picker
Communication between chrome and content processes
  • IPC messages received on main thread in each process
  • Messages are async by default
  • Content process can send sync messages to chrome
    • Sync messages can have return values
  • Chrome process cannot send sync messages to content
Library loading
Stock Android
  • Native libs stored in .apk
  • Extracted on load to data dir
  • Essentially doubles on disk install size
  • Slow on first run
Library loading
Gecko
  • Michael Wu wrote a custom dlopen
  • Extracted to mmap'd ashmem
  • 176KB on disk
  • Extracted on demand
    • faster start up
  • Background process writes out to disk
    • Only if there's enough free space (150Mb metric)
Fitting in on the platform
  • Gecko doesn't use any native widgets
  • UI implemented in JS, CSS and XUL (like HTML)
  • CSS themed to look like a native app
  • Platform has JS binding to expose OS features to application
  • Implemented "Android style:"
    • Context menus
    • System menu
    • Honeycomb action bar
  • nsILookAndFeel now implemented
Fitting in on the platform
Froyo vs. Gingerbread themes
Plugins (i.e. Flash) support
  • Google and Adobe defined extensions to NPAPI
  • New interfaces:
    • Log - Access to android log
    • Audio - Play sound
    • Matrix - Matrix operations (rotate, skew, etc.)
    • Paint -Color, style, stroke attributes for drawing APIs
    • Path - Path (vector) drawing api
    • Typeface - API for querying font system
    • Window - API to set visible rect and request fullscreen
    • Surface - Lock and unlock surface
    • System - Query app data dir and load plugin classes
    • Event - API to send events to plugin
Plugins support
Continued
  • New plugin enumeration values
    • getters
      • All the interfaces
      • Application Context
      • Supported drawing models
    • setters
      • Selected drawing model
      • Accept events
  • Plugin initialized with pointer to JNIEnv
Plugins support
Current status
  • Required interfaces implemented
  • Remote JNI implemented
  • Sample plugins render
    • In both chrome and content process
  • Flash doesn't render (yet)
Thanks!