The document provides information about the Android stack and layers. It discusses the Linux kernel layer, which manages processes, memory, system calls, and device drivers. It describes the user-space native layer and its components like Bionic libc and hardware abstraction layer. It covers the application framework layer and key services like activity manager, package manager, power manager, and alarm manager. It also discusses the Android runtime layer and Dalvik virtual machine. Finally, it provides an overview of the Native Development Kit and how to integrate native code using the Java Native Interface.

1. Android Course
Day 1

2. Android Stack

3. Android Linux Kernel Layer
 Kernal Responsible for
 Manage process
 Manage Memory
 Manage System call
 Manage file system
 Manage network stack
 Manage device drivers etc.
 Major component of Android Linux Kernel
 Binder
 A new mechanism to implements IPC
 Use synchronous method call
 Client process is blocked during answer of the server
 Remote object method can be called as local object method
 Process Isolation

4. Android Linux Kernel Layer
 Due to security reason one process can’t be manipulate data of other.
 Virtual memory concept to achieve this isolation
 Virtual memory mapped to the physical memory by OS
 Process is limited to its virtual memory, only OS has access to Physical memory
 Multitasking, processing, threading
 Parallel execution of work
 OS provide fair proportioning, because only one process can use the CPU at a time.
 Thread is a process without own address space in memory
 Ashmem (Android Shared Memory)
 Addon to linux kernel.
 Ashem allow processes which are not related by ancestry to shared memory maps by name which
is cleaned up automatically.
 Maintain reference counting, so that if some process share same area the area will not removed
until all processes has release it.

5. Android Linux Kernel Layer
 PMEM/ION
 The PMEM (physical memory) driver is used to provide contiguous physical memory
 PMEM is considered obsolete now
 From Android 4.0 ICS release Google introduced ION is a generalized memory manager to address
the issue of fragmented memory management interfaces across different Android devices
 Wake Lock
 Software method for applications to control the power state of your device
 Use to prevent to go device in deep sleep while viewing some application like media players ect.
 Its always critical to handle, as it directly depends on battery life of device.
 Early Suspends
 State is between really suspend, and trun off screen
 After Screen is off, several devices such as LCD backlight, gsensor, touchscreen will stop for
battery life and functional requirement

6. Android Linux Kernel Layer
 Alarm
 User space tell the kernel when it would like to wake up
 Allowing the kernel to schedule that appropriately and come back (holding a wake lock) when
the time has expired regardless of the sleep state of the CPU
 Any program can be schedule to run at a certain time.
 Low Memory Killer
 Low memory killer can kill off processes to free up memory as necessary
 It is designed to provide more flexibility than the Out Of Memory (OOM) killer in the standard
kernel
 Before kill the process it notifies the process about low memory triggered so that process can
manage their current state
 Logger
 Paranoid Network Security
 Restricts access to some networking features depending on the group of the calling process.

7. Android User-space Native Layer
 This layer provide an abstraction for Kernel and responsible for handling all the system related
services like, GPS, Sensor, Media, power management etc.
 4 major component
 Bionic Libc
 The Bionic libc is a derivation of the BSD standard C library code that was originally developed by Google for the
Android embedded operating system
 Bionic has several major Linux-specific features and development continues independent of other code bases
 BSD license
 Small size
 Speed
 User-space Hardware Abstraction Layer (HAL)
 implemented in software, between the physical hardware of a computer and the software that runs on that
computer
 Its function is to hide differences in hardware from most of the operating system kernel
 This layer contains services for Sensor, GPS, audio, camera, Bluetooth, WiFi ect

8. Android User-space Native Layer

9. Android Linux Kernel Layer
 Native Daemons
 Zygote
 Zygote process basically cold boots a VM on system start up
 Once done, it listens to a socket for incoming commands
 Whenever a new process for an application (e.g. ActivityManagerService) writes commands
to this socket
 Zygote read the command and fork() child process
 Racoon
 Racoon speaks the IKE (ISAKMP/Oakley) key management protocol, to establish security
associations with other hosts
 The SPD (Security Policy Database) in the kernel usually triggers racoon
 Usually sends all informational messages, warnings and error messages to syslogd with the
facility LOG_DAEMON and the priority LOG_INFO

10. Android Linux Kernel Layer
 Ueventd
 Kernel can send a uevent as the notification to user space
 In Android it is the ueventd daemon that receives and handles these events
 Vold
 Mounting of physical external storage volumes is handled by vold
 which performs staging operations to prepare the media before exposing it to apps
 Servicemanger
 Provide context for Binder framework
 Rild
 Android's Radio Interface Layer (RIL) provides an abstraction layer between Android telephony
services (android.telephony) and radio hardware
 The RIL is radio agnostic, and includes support for Global System for Mobile communication
(GSM)-based radios

11. Android Linux Kernel Layer
 Mediaserver
 Provide daemons for Audio, video, images all kind of media
 Functional Libraries
 Web kit (web related API)
 SQLite (lightweight rational database)
 Libssl (SSL layer to communicate server)
 openGL (Graphics API implementation)
 Media lib (Audio, Video, images etc)
 Android Runtime/Dalvik Virtual Machine
 Dalvik is the process virtual machine (VM) in Google's Android operating system.
 software that runs the apps on Android devices
 Programs are commonly written in Java and compiled to bytecode. They are then converted
from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable)
files before installation on a device

12. Android Linux Kernel Layer
 A tool called dx is used to convert some (but not all) Java .class files into the .dex
format
 Java bytecode is also converted into an alternative instruction set used by the
Dalvik VM
 An uncompressed .dex file is typically a few percent smaller in size than a
compressed .jar (Java Archive) derived from the same .class files

13. Android Course
Day 2

14. Android Application Framework Layer
 Abstraction b/w core lib implementation and user application
 It provides direct interaction with applications, to support necessary services of
the system with application
 These programs manage the basic functions of phone like resource management,
voice call management etc
 Written in java and provide basic manager and services Application.
 Services are essential component of Android Application framework
 Pre-defined services usually exposed via a specific Manager class. Access to them can be
gained via the getSystemService() method
 Activity Manager Service
 This service usually Interact with the overall activities running in the system
 Provide basic information related to applications like launcher icon, memory, list of other
processes
 Also, can execute command to kill background processes etc.

15. Android Application Framework Layer
 Package Manager Service
 To get this manager use getPackageManager()
 Get for version of application package, permission, all other packages install in the device etc.
 Get all services and applications match with a given intent.
 Power Manager
 Control to the power state of the device
 Device battery life will be significantly affected by the use of this API
 Alarm Manager
 Schedule your application to be run at some point in the future
 When an alarm goes off, the Intent that had been registered for it is broadcast by the system,
automatically starting the target application if it is not already running
 Registered alarms are retained while the device is asleep (and can optionally wake the device up
if they go off during that time), but will be cleared if it is turned off and rebooted

16. Android Application Framework Layer
 Notification Manager
 Class to notify the user of events that happen. This is how you tell the user that something has
happened in the background
 Notification can be in different form
 A persistent icon that goes in the status bar and is accessible through the launcher
 Turning on or flashing LEDs on the device
 Alerting the user by flashing the backlight, playing a sound, or vibrating
 Each of the notify methods takes an int id parameter and optionally a String tag parameter
 Search Manager
 This class provides access to the system search services
 To retrieve it use context.getSystemService(Context.SEARCH_SERVICE)
 Launch search UI
 Get information about searchable activity

17. Android Application Framework Layer
 Connectivity Manager
 Class that answers queries about the state of network connectivity
 It also notifies applications when network connectivity changes
 Get an instance of this class by calling
Context.getSystemService(Context.CONNECTIVITY_SERVICE).
 The primary responsibilities of this class are
 Monitor network connections (Wi-Fi, GPRS, UMTS, etc.)
 Send broadcast intents when network connectivity changes
 Attempt to "fail over" to another network when connectivity to a network is lost
 Provide an API that allows applications to query the coarse-grained or fine-grained state of the available
networks
 Telephony Manager
 Provides access to information about the telephony services on the device
 Applications can use the methods in this class to determine telephony services and states, as well
as to access some types of subscriber information

18. Android Application Framework Layer
 Applications can also register a listener to receive notification of telephony state changes
 Main responsibilities of this service
 Get all observed cell information of the device
 Get a constant indicating the call state (cellular) on the device
 Get the current location of the device
 Get the software version number for the device, for example, the IMEI/SV for GSM phones
 Retrieve an instance through Context.getSystemService(Context.TELEPHONY_SERVICE)
 WiFi Manager
 This class provides the primary API for managing all aspects of Wi-Fi connectivity
 Get an instance of this class by calling Context.getSystemService(Context.WIFI_SERVICE)
 Add permission in manifest file to access wifi state <uses-permission
android:name="android.permission.ACCESS_WIFI_STATE" />
 It deals with several categories of items
 The list of configured networks. The list can be viewed and updated, and attributes of individual entries
can be modified

19. Android Application Framework Layer
 The currently active Wi-Fi network, if any. Connectivity can be established or torn down, and dynamic
information about the state of the network can be queried
 Results of access point scans, containing enough information to make decisions about what access point to
connect to
 It defines the names of various Intent actions that are broadcast upon any sort of change in Wi-Fi state
 Input Method and UI manager
 Central system API to the overall input method framework (IMF) architecture, which arbitrates
interaction between applications and the current input method
 Retrieve an instance of this interface with
Context.getSystemService(Context.INPUT_METHOD_SERVICE)
 An input method (IME) implements a particular interaction model allowing the user to generate
text
 Multiple client applications arbitrate with the input method manager for input focus and control
over the state of the IME
 Show/hide soft keyboard
 Set different type of soft keyboard

20. Android Application Framework Layer
 Window Manager
 Use Context.getSystemService(Context.WINDOW_SERVICE) to get one of these
 Each window manager instance is bound to a particular Display
 Location Manager
 This class provides access to the system location services
 These services allow applications to obtain periodic updates of the device's geographical
location, or to fire an application-specified Intent when the device enters the proximity of
a given geographical location
 Location API methods require the ACCESS_COARSE_LOCATION or
ACCESS_FINE_LOCATION permissions
 Retrieve it through Context.getSystemService(Context.LOCATION_SERVICE)

21. Android Application Framework Layer
 Download Manager
 The download manager is a system service that handles long-running HTTP downloads
 Clients may request that a URI be downloaded to a particular destination file
 The download manager will conduct the download in the background, taking care of HTTP interactions and retrying
downloads after failures or across connectivity changes and system reboots
 Instances of this class should be obtained through getSystemService(DOWNLOAD_SERVICE)
 Apps that request downloads through this API should register a broadcast receiver for
ACTION_NOTIFICATION_CLICKED to appropriately handle when the user clicks on a running download in a
notification or from the downloads UI
 Storage Manager
 StorageManager is the interface to the systems storage service. The storage manager handles storage-related items
such as Opaque Binary Blobs (OBBs)
 OBBs contain a filesystem that maybe be encrypted on disk and mounted on-demand from an application
 OBBs are a good way of providing large amounts of binary assets without packaging them into APKs as they may be
multiple gigabytes in size
 However, due to their size, they're most likely stored in a shared storage pool accessible from all programs

22. Android Native Development Kit (NDK)
 What is NDK?
 The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++
 For certain types of apps, this can be helpful so you can reuse existing code libraries written in these languages, but
most apps do not need the Android NDK
 Notably, using native code on Android generally does not result in a noticable performance improvement, but it always
increases your app complexity
 Why NDK?
 Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such
as signal processing, physics simulation, and so on
 You only need to use the NDK if your application is truly processor bound. That is, you have algorithms that are using all
of the processor within the DalvikVM and would benefit from running natively
 Another reason to use the NDK is for ease of porting. If you’ve got loads of C code for your existing application, using the
NDK could speed up your project’s development process as well as help keep changes synchronized between your Android
and non-Android projects. This can be particularly true of OpenGL ES applications written for other platforms
 Don’t assume you’ll increase your application’s performance just because you’re using native code. The Java<->Native C
exchanges add some overhead, so it’s only really worthwhile if you’ve got some intensive processing to do

23. Android Native Development Kit (NDK)
 Java Native Interface (JNI)
 The Java Native Interface (JNI) is a programming framework that enables Java code running in a Java Virtual
Machine (JVM) to call, and to be called by, native applications (programs specific to a hardware and operating
system platform) and libraries written in other languages such as C, C++ and assembly
 To create native method in Java, we need to put “native” keyword at the front of method declaration and left
method unimplemented
 A typical example: public native String stringFromJNI();
 Once native method created in java we need to implement this method in C/C++. Then compile the program to
create shared library and include in java clasee using System.loadLibrary("hello-jni");
 Using NDK
 Installing
 Download NDK using http://developer.android.com/tools/sdk/ndk/index.html
 For 32-bit windows machine download android-ndk-r8e-windows-x86.zip
 Install cygwin

24. Android Native Development Kit (NDK)
 Getting Started with the NDK
 Place your native sources under <project>/jni/
 Create <project>/jni/Android.mk to describe your native sources to the NDK build system
 Optional: Create <project>/jni/Application.mk.
 Build your native code by running the 'ndk-build' script from your project's directory. It is located in the
top-level NDK directory:
 cd <project>
 <ndk>/ndk-build
 The build tools copy the stripped, shared libraries needed by your application to the proper location in
the application's project directory
 Finally, compile your application using the SDK tools in the usual way. The SDK build tools will package
the shared libraries in the application's deployable .apk file
 Two way write code in NDK
 Write your application using the Android framework and use JNI to access the APIs provided by the
Android NDK.
 Write a native activity, which allows you to implement the lifecycle callbacks in native code.

25. Android Native Development Kit (NDK)
 NDK’s stable APIs
 The C Library
 The Math Library
 C++ Library
 Android-specific Log Support
 ZLib Compression Library
 Dynamic Linker Library
 The OpenGL ES 1.x Library
 The OpenGL ES 2.0 Library

26. Android Course
Day 3

27. Inter Process Communication (IPC) with
Android Binder and AIDL
 Why IPC?
 inter-process communication (IPC) is a set of methods for the exchange of data among multiple threads in one or more processes
 Processes may be running on one or more computers connected by a network
 IPC methods are divided into methods for
 message passing
 synchronization
 shared memory
 remote procedure calls (RPC)
 There are several reasons for providing an environment that allows process cooperation:
 Information sharing
 Computational speedup
 Modularity
 Convenience
 Privilege separation
 IPC may also be referred to as inter-thread communication and inter-application communication

28. Inter Process Communication (IPC) with
Android Binder and AIDL
 What is Binder?
 Unlike traditional Linux machines, Android uses its own mechanism for IPC called the
Binder
 Binder was originally developed as OpenBinder and was used as the IPC in BeOS
 The current Binder implementation in Android is a customized implementation of the
OpenBinder
 This was mainly to ensure the new implementation uses a license that is compatible with
the Android’s user space code
 Each Binder object is an implementation of the IBinder implementation
 An important difference between Binder and other IPC mechanisms is the use of Binder
token.
 A binder token is value that uniquely identifies any Binder. This capability to uniquely
identify a binder across processes allows the binder id to act as a ‘shared token’ across
multiple processes.

29. Inter Process Communication (IPC) with
Android Binder and AIDL
 Communication model

30. Inter Process Communication (IPC) with
Android Binder and AIDL
 What is AIDL?
 To write a proxy and stub class that would be interacting with the client and server
 Developers write the interface for their remote services using AIDL
 The AIDL parser takes care of generating Java classes for the proxy and stub and
logic to convert data into parcels that the Binder middleware understands

31. Android Security
 Android Security Architecture
 No application, by default, has permission to perform any operations that would adversely impact other
application, the OS, and the user
 This include read, write user’s private data etc.
 Android sandboxes applications from each other
 Applications statically declare the permissions they require
 Android has no mechanism for granting permissions dynamically ( as it complicate user experience)
 The application sandbox does not depend on the technology used to build an application
 Application Signing
 All Android applications (.apk files) must be signed with a certificate whose private key is held by their
developer
 This certificate identifies the author of the application
 The certificate does not need to be signed by a certificate authority
 The purpose of certificates in Android is to distinguish application authors

32. Android Security
 User IDs and File Access
 At install time, Android gives each package a distinct Linux user ID
 The identity remains constant for the duration of the package's life on that device
 On a different device, the same package may have a different UID; what matters is that
each package has a distinct UID on a given device
 Because security enforcement happens at the process level, the code of any two
packages cannot normally run in the same process, since they need to run as different
Linux users
 You can use the sharedUserId attribute in the AndroidManifest.xml's manifest tag of
each package to have them assigned the same user ID. By doing this, for purposes of
security the two packages are then treated as being the same application, with the same
user ID and file permissions
 Any data stored by an application will be assigned that application's user ID, and not
normally accessible to other packages

33. Android Security
 Using Permissions
 A basic Android application has no permissions associated with it by default
 To use permission in your application you must include <uses-permission> tag in
your manifest file
 Often times a permission failure will result in a SecurityException being thrown
back to the application
 For example, an application that needs to monitor incoming SMS messages would
specify

34. Android Security
 Permission Enforcement
 To enforce your own permissions, you must first declare them in your
AndroidManifest.xml using one or more <permission> tags
 The <protectionLevel> attribute is required, telling the system how the user is to
be informed of applications requiring the permission, or who is allowed to hold
that permission, as described in the linked documentation
 The <permissionGroup> attribute is optional, and only used to help the system
display permissions to the user

35. Android Security
 ContentProvider URI permission
 A content provider may want to protect itself with read and write permissions
 the caller can set Intent.FLAG_GRANT_READ_URI_PERMISSION and/or
Intent.FLAG_GRANT_WRITE_URI_PERMISSION. This grants the receiving activity permission
access the specific data URI in the Intent
 It is strongly recommended that content providers implement this facility, and declare that
they support it through the android:grantUriPermissions attribute or <grant-uri-permissions>
tag
 Intent Broadcast permissions
 BroadcastReceiver
 It used to send some messages across register Receivers
 Base class for code that will receive intents sent by sendBroadcast()
 There are two major classes of broadcasts that can be received
 Normal broadcasts
 Ordered broadcasts

36. Android Security
 Security
 Receivers used with the Context APIs are by their nature a cross-application facility
 When you publish a receiver in your application's manifest and specify intent-filters for it, any
other application can send broadcasts to it regardless of the filters you specify. To prevent others
from sending to it, make it unavailable to them with android:exported="false“
 To enforce a permission when sending, you supply a non-null permission argument to
sendBroadcast(Intent, String) or sendOrderedBroadcast(Intent, String, BroadcastReceiver,
android.os.Handler, int, String, Bundle). Only receivers who have been granted this permission
(by requesting it with the <uses-permission> tag in their AndroidManifest.xml) will be able to
receive the broadcast
 To enforce a permission when receiving, you supply a non-null permission when registering your
receiver -- either when calling registerReceiver(BroadcastReceiver, IntentFilter, String,
android.os.Handler) or in the static <receiver> tag in your AndroidManifest.xml. Only
broadcasters who have been granted this permission (by requesting it with the <uses-
permission> tag in their AndroidManifest.xml) will be able to send an Intent to the receiver

37. Android Security
 Pending Intents
 By giving a PendingIntent to another application, you are granting it the right to
perform the operation you have specified as if the other application was yourself
(with the same permissions and identity)
 A PendingIntent itself is simply a reference to a token maintained by the system
describing the original data used to retrieve it

38. Android Startup
 Bootloading the Kernel
 Bootloader
 The first program which runs on any Android system is the bootloader.
 Technically, the bootloader is outside the realm of Android itself, and is used to do very
low-level system initialization, before loading the Linux kernel.
 The kernel then does the bulk of hardware, driver and file system initialization, before
starting up the user-space programs and applications that make up Android.
 Often, the first-stage bootloader will provide support for loading recovery images to the
system flash, or performing other recovery, update, or debugging tasks.
 The bootloader on the ADP1 detects certain keypresses, which can be used to make it load
a 'recovery' image (second instance of the kernel and system), or put the phone into a
mode where the developer can perform development tasks ('fastboot' mode), such as re-
writing flash images, directly downloading and executing an alternate kernel image, etc.

39. Android Startup
 Kernel boots
 core kernel initialization
 memory and I/O areas are initialized
 interrupts are started, and the process table is initialized
 driver initialization
 kernel daemons (threads) are started
 root file system is mounted
 the first user-space process is started
 usually /init (note that other Linux systems usually start /sbin/init)
 Android’s init Startup
 A key component of the Android bootup sequence is the program 'init'
 It is a specialized program for initializing elements of the Android system

40. Android Startup
 Unlike other Linux systems (embedded or otherwise), Android uses its own
initialization program. (Linux desktop systems have historically used some
combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with
symlinks in /etc/rc.d/rc.)
 Some embedded Linux systems use simplified forms of these -- such as the init
program included in busybox, which processes a limited form of /etc/inittab, or a
direct invocation of a shell script or small program to do fixed initialization steps
 The Android 'init' program processes two files, executing the commands it finds in
them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the
name of the hardware that Android is running on. (Usually, this is a code word. The
name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is
'goldfish‘
 The 'init.rc' file is intended to provide the generic initialization instructions, while
the 'init. <machine_name>.rc' file is intended to provide the machine-specific
initialization instructions

41. Android Startup
 Startup of daemons
 After init phase has been done, init phase start kernel daemons
 Daemons generally known as System Helper.
 They run from time to time performing small but important tasks like:
 Handling mail
 Running network communications
 Feeding data to your printer
 Keeping track of the time, and so on.
 Zygote Startup
 init runs the C++ program /system/bin/app_process, and gives the resulting process the name "zygote".
 app_process executes, and executes a runtime environment for a dalvik class
 app_process does a 'runtime.start("com.android.internal.os.ZygoteInit", startSystemServer)
 AndroidRuntime is the main class for starting the dalvik runtime environment

42. Android Startup
 com.android.internal.os.ZygoteInit:main() starts executing
 The profiler is started
 The Zygote socket is registered (for later communication to start apps)
 classes and resources are preloaded
 if startSystemServer is set, then the system server is started
 eventually, a call is made to Zygote.forkAndSpecialize(), which does the actual forking
 System Server Startup
 After dalvik get started, its start System servers.
 System server control and manage all systems services
 Startup of system services
 System server load all system services one by one.
 Services/ Managers like LocationManager, WindowManager etc. started in this phase.

43. Android Startup
 Startup of Applications
 Once all services get started, the Application layer initialized
 Here is complete picture how things get initialized

44. Android Course
Day 4

45. Mics topics
 Cryptographic API from C
 The Linux crypto-API is an internal kernel API used for things such as IPsec and dm-
crypt. It's not directly usable by user-mode applications.
 All cryptographic API can be found in #include <linux/crypto.h>
 Scatterlist Cryptographic API takes page vectors (scatterlists) as arguments, and
works directly on pages.
 Scatterlist Cryptographic API can be used by including #include
<linux/scatterlist.h>
 Some list of API can be find
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/crypt
o.h?v=2.6.25.8

46. Mics topics
 Accessing the device from PC via usb, ADB
 Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator
instance or connected Android-powered device.
 It is a client-server program that includes three components:
 A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb
command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
 A server, which runs as a background process on your development machine. The server manages communication
between the client and the adb daemon running on an emulator or device.
 A daemon, which runs as a background process on each emulator or device instance.
 You can find the adb tool in <sdk>/platform-tools/.
 When you start an adb client, the client first checks whether there is an adb server process already running. If
there isn't, it starts the server process. When the server starts, it binds to local TCP port 5037 and listens for
commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server.
 The server then sets up connections to all running emulator/device instances. It locates emulator/device
instances by scanning odd-numbered ports in the range 5555 to 5585, the range used by emulators/devices.
Where the server finds an adb daemon, it sets up a connection to that port. Note that each emulator/device

47. Android Tools and Debugging
 Overview of Android Tools
 AVD (Android virtual device)
 Dalvik Debug Monitor Server (ddms)
 dmtracedump
 Generates graphical call-stack diagrams from trace log files. The tool uses the Graphviz Dot
utility to create the graphical output, so you need to install Graphviz before running
dmtracedump. For more information on using dmtracedump, see Profiling with Traceview and
dmtracedump
 Draw 9-patch
 Android Emulator (emulator)
 Hierarchy Viewer (hierarchyviewer)
 hprof-conv
 Layoutopt
 Mksdcard

48. Android Tools and Debugging
 Monkey
 monkeyrunner
 ProGuard
 Systrace
 Sqlite3
 traceview
 Zipalign
 Debugging applications and system services
 The Android SDK provides most of the tools that you need to debug your applications.
 You need a JDWP-compliant debugger if you want to be able to do things such as step through
code, view variable values, and pause execution of an application.
 If you are using Eclipse, a JDWP-compliant debugger is already included and there is no setup
required. If you are using another IDE, you can use the debugger that comes with it and attach
the debugger to a special port so it can communicate with the application VMs on your devices.

49. Android Tools and Debugging
 The main components that comprise a typical Android debugging environment are:
 Adb
 Dalvik Debug Monitor Server
 Device or Android Virtual Device
 JDWP debugger

50. Android Tools and Debugging
 Debugging Java code on Android

51. Customizing Android
 Setting up Custom Device Directory Structure, Registering device and build make file
 Create a company directory in //vendor/
 Create a products directory beneath the company directory you created in step 1
 Create a product-specific makefile
 In the products directory, create an AndroidProducts.mk file that point to (and is responsible for finding) the
individual product make files
 Create a board-specific directory beneath your company directory that matches the PRODUCT_DEVICE variable
<board_name> referenced in the product-specific make file above
 Create a BoardConfig.mk file in the directory created in the previous step
 Generating Our Own Platform Signing Keys
 The core Android platform uses four keys to maintain security of core platform components:
 Platform: a key for packages that are part of the core platform.
 Shared: a key for things that are shared in the home/contacts process.
 Media: a key for packages that are part of the media/download system.
 Releasekey: the default key to sign with if not otherwise specified

52. Customizing Android
 Generating Keys
 A device manufacturer's keys for each product should be stored under vendor/<vendor_name>/security/<product_name>,
where <vendor_name> and <product_name> represent the manufacturer and product names
 Create mkkey.sh.
 To generate the required 4 platform keys, run mkkey.sh four times specifying the key name and password for each:
 sh mkkey.sh platform # enter password
 sh mkkey.sh media # enter password
 sh mkkey.sh shared # enter password
 sh mkkey.sh release # enter password
 Build our Device for the First time
 In order to build device first time we need to go following steps:
 Build the simple APK
 Build APK that depends on a static .jar file
 Build APK that should signed with the Platform key
 Build APK that should signed with a specific vendor key

53. Customizing Android
 Add pre build APK
 Add static java library
 Execute Android.mk file to build system
 Adding a Custom Kernel to our Device
 Create a custom kernel
 Place kernel zip file into device SD card
 Reboot device into recovery mode
 Locate kernel zip file in SD card
 Select kernel zip
 Choose install
 After this device will start installing new kernel to your device.
 After finish, it will restart the device

54. Customizing Android
 Adding a Custom Native Library and Executable to our Device
 Create custom executable (.apk) files of system application, to replace with original one.
 Batch Backup all user apps & data in current ROM using Titanium Backup (TB)
 File Manager:
 Astro: sdcardbackupapps
 Gemini App: sdcardgmutilsbackupapk
 com.keramidas.TitaniumBackup*.apk
 com.keramidas.TitaniumBackupPro*.apk
 (Restores TB - alternatively download from Market)
 Batch Restore all system data
 + DESELECT ALL
 + CHECK GREEN ITEMS ONLY (NOT RED)
 Note: icons will not show correctly yet.
 Reboot

55. Customizing Android
 Using our Native Library via a Custom Daemon
 Daemon runs in system background
 Once native lib added to Android device we can have access to their API in Daemon.
 Create a custom Daemon in Android.
 Copy custom Daemon in SD card
 Reboot device in recovery mode
 Locate Daemons file in SD card and choose update.
 Reboot device
 Exposing our Native Library via Java (i.e. JNI)
 Consuming our a Custom Java/JNI, Native Library via a Custom App
 Exposing our Custom Library via a Custom IPC/Binder Service
 Building a Custom App Using a Custom Service Manager