Android Architecture

Android Architecture
Android Architecture
Karthik Dantu and Steve Ko
Administrivia
•  Show us your build!
•  Assignment 2 is out and due in one week.
Project Meetings: This Friday
•  Multi-Interface Connectivity: Aditya, Chaitanya,
Devanshu, Swapnesh
•  Location Services API: AnujG, Subhendu, Sriram,
Gokhan
•  Smart Services: Ankesh, Varun, Arshaq, AnujK
•  Automated cloud backup: Kyle, Rakesh, Sharath,
Hrishikesh
•  Quantified Self: Yash, Pratik, Tanmay
Project Meetings: Next Friday
•  Analyzing memory pressure in Android: Alex, Ankit,
Brandon, Engin
•  Wakelock resource accounting: Rajesh,
Kshitijkumar, Aravindhan, Babu Prasad
•  RTAndroid: Pranav, Jerry, Aswin, Mohit
•  Google Glass Visual Inertial Navigation: Srivathsa,
Nishanth, Rohit, Priyanka
Today: Overview of Android
•  Why?
•  A good example to start with in order to
understand the source (I think)
•  Getting deeper with the source
•  Not quite straightforward to understand
•  Goal: giving you enough pointers so you can navigate
the source yourself.
Things You Need to Know
•  Android Programming Model
•  Launcher is implemented with this model.
•  Android Architecture
•  Android IPC mechanisms
•  ActivityManager uses IPC mechanisms.
•  Zygote
Android Programming Model
•  No main()
•  Four main components: Activity, Service,
ContentProvider, BroadcastReceiver
•  You need to implement at least one of them to
write an Android app.
•  Event-driven
Example - Activity
Example - Activity
Android Architecture
Apps
APIs
System Services
Activity Manager
Location Manager…
Java Libraries
android.*
java.*
Dalvik, Zygote, Android Runtime
JNI
Native Libraries
Daemons
Tools
Linux Kernel with Android Extensions
(Wakelocks, Binder, lowmem, etc.)
HAL
Zygote
•  C++ (e.g., app_main.cpp, AndroidRuntime.cpp) and
Java (e,g., ZygoteInit.java)
•  Starts at boot.
•  ZygoteInit.java manages a domain socket and listens
to incoming VM creation requests.
•  This uses ZygoteConnection.java.
•  Main flow
•  Forks a new VM instance.
•  Loads the class that has the process’s main().
•  Calls the main().
Android IPC Mechanisms
•  Android relies heavily on IPC mechanisms.
•  This goes with the event-driven programming
model.
•  Three main mechanisms
•  Intent
•  Binder
•  Looper-Handler
Intent
•  You can think of it as a message or a command.
•  Main fields
•  Action (e.g., ACTION_VIEW) and Data
•  Many system events are communicated as intents.
•  E.g., ACTION_BATTERY_CHANGED,
ACTION_POWER_CONNECTED, etc.
•  A reasonable strategy for code navigation
•  Locate where the switch-case code is for
different actions
Binder
•  The main IPC mechanism on Android
•  Binder enables method calls across process
boundaries.
•  Caller side: A proxy and marshalling code
•  Callee side: A stub and unmarshalling code
•  Two ways to use it.
•  Automatic proxy & stub generation (.aidl)
•  Manual proxy & stub implementation
Binder with .aidl
•  .aidl defines the interface.
•  Naming convention: I*.aidl.
•  E.g., IPackageManager.aidl
•  The stub compiler generates I*.java
•  E.g., IPackageManager.java
•  This is part of the build process, i.e., you will not
find I*.java file in the source (unless you’ve
compiled already, then it’s under out/).
•  It contains I*.Stub abstract class
•  E.g., abstract class IPackageManager.Stub
Binder with .aidl
•  A Stub class should be extended.
•  This is the actual implementation for IPC calls.
•  E.g., class PackageManagerService extends
IPackageManager.Stub
•  Callers can use the interface to make IPC calls.
•  Callers can import classes in I*.java and use
Stub.asInterface() when making IPC calls.
•  E.g., IPackageManager.Stub.asInterface() returns
an object for making IPC calls.
Binder with .aidl
•  A reasonable strategy for code navigation
•  If you encounter a call using an object returned
from .asInterface() call, it’s a Binder call.
•  Don’t worry about marshalling/unmarshalling
code, e.g., onTransact().
•  Find the class that extends the Stub class. (Use
croot;jgrep)
Binder without .aidl
•  Manual implementation of the interface,
marshalling/unmarshalling, and methods.
•  E.g., IActivityManager.java defines the interface for
accessing ActivityManager.
•  abstract class ActivityManagerNative implements
IActivityManager and has the marshalling/
unmarshalling code.
•  There’s a class that extends ActivityManagerNative
and provide the actual callee-side implementation.
Binder without .aidl
•  A reasonable strategy for code navigation
•  Manual implementation typically follows the
ActivityManager example.
•  Interface file à abstract class à extended class
•  E.g., startActivity() goes through this flow of
classes.
Looper-Handler
•  Looper is a per-thread message loop.
•  Looper.prepare()
•  Looper.loop()
•  A Handler is shared by two threads to send/receive
messages.
•  Looper-Hanlder is used in the app control process to
handle various messages.
Code Flow for App Start
•  Launcher sends an intent to start an activity.
•  startActivity() is a Binder call to ActivityManager.
•  ActivityManager sends a process fork request.
•  This request uses a socket to Zygote.
•  Zygote forks a new VM instance that loads
ActivityThread.
•  ActivityThread has the real main() for an app.
Code Flow for App Start
•  ActivityThread calls the app’s onCreate()
•  ActivityThread notifies ActivityManager.
•  ActivityManager makes a Binder call to
ActivityThread to start the app (i.e., call onStart()).
Code Navigation
•  Let’s see the code!
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising