Android training course

Android CourseDay 1

Android Stack

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


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.


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


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.

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

Android User-space Native 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


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


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


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

Android CourseDay 2

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.


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


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


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


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


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


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)


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

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


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

http://developer.android.com/tools/sdk/ndk/index.html

http://dl.google.com/android/ndk/android-ndk-r8e-windows-x86.zip


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.


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

Android CourseDay 3

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



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.



Communication model



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

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

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

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

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

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

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

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

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.

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

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 initprogram 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

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

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.

Android Startup

Startup of Applications

Once all services get started, the Application layer initialized

Here is complete picture how things get initialized

Android CourseDay 4

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

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/crypto.h?v=2.6.25.8

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 adbcommand. 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

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


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.


The main components that comprise a typical Android debugging environment are:

Adb

Dalvik Debug Monitor Server

Device or Android Virtual Device

JDWP debugger


Debugging Java code on Android

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

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

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

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: \sdcard\backup\apps\

Gemini App: \sdcard\gmutils\backup\apk\

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

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

Date post:	15-Jul-2015
Category:	Software
Upload:	adarsh-pandey
View:	177 times
Download:	0 times