Pages

Label

Tampilkan postingan dengan label Binder. Tampilkan semua postingan
Tampilkan postingan dengan label Binder. Tampilkan semua postingan

Rabu, 30 Januari 2019

AIDL and its uses in Android

Hello Guys !!! Hope You all are doing well. Today I am going to discuss AIDL and its uses in Android Application. 

AIDL (Android Interface Definition Language) is similar to other IDLs.
It allows us to define the programming interface that both the client and service agree upon in order to communicate with each other using interprocess communication (IPC).

On Android, one process cannot normally access the memory of another process. So to talk, they need to decompose their objects into primitives that the operating system can understand, and marshall the objects across that boundary for you. The code to do that marshalling is tedious to write, so Android handles it for us with AIDL.

# When to use AIDL

  1. Clients from different applications want to access your service for IPC.
  2. Your service want to handle multithreading for IPC(any method defined in service can be executed simultaneously by more than one application).
  3. If you want to share data and control something in another application.
  4. You want to create some new functionalities and distribute them as a library.


# AIDL Implementation Steps
In order to allow for one application to call into another, we typically have to:
  1. Define the AIDL interface
  2. Implement the Stub for the remote service
  3. Expose the remote service to the local client
# The data types supported by AIDL
  • All primitive types (Supported by Java such as int, long, char, boolean, and so on)
  • String
  • CharSequence
  • List(must be one of the supported data types or parcelables)
  • Generic List such as List<String> supported
  • Map (must be one of the supported data types or parcelables )
  • Generic maps, such as Map<String,Integer> are not supported
# Defining the AIDL
  • AIDL syntax is very similar to regular Java interface , Define AIDL interface in an .aidl
  • Then save it in the source code (in the src/ directory) of both the application hosting the service and any other application that binds to the service.
  • When you build each application that contains the .aidl file, the Android SDK tools generate an IBinder interface based on the .aidl file and save it in the project's gen/ directory.
# Steps for creating a bounded service using AIDL

1. Create the .aidl file
This file defines the programming interface with method signatures.
2. Implement the interface
The Android SDK tools generate an interface in the Java programming language, based on your .aidl file. This interface has an inner abstract class named Stub that extends Binder and implements methods from your AIDL interface. You must extend the Stub class and implement the methods.
3. Expose the interface to clients
Implement a Service and override onBind() to return your implementation of the Stub class.

Note:

  1.   Any changes that you make to your AIDL interface after your first App release must remain backward compatible in order to avoid breaking other applications that use your service.
  2. That is, because your .aidl file must be copied to other applications in order for them to access your service's interface, you must maintain support for the original interface.

















In above example, I am using two application Client App and Server App.  Client App will get number from user and send it to server.
Server App will receive number from client and perform addition and send result back to client App.

In my example code App is server App and app2 is client App.
Hope you people enjoy it. Flow Diagram for AIDL.



Note:- Please proved your comment and suggestion for my post. It will energize me.

The Android Booting process

Hello Guys!!! Hope You all are doing well....
Today I am going to discuss Android Boot Sequence . 
When we switch off our Android powered device and switch on it again, this process known as Android Booting sequence. 

Above Image showing 5 stage of Booting process for Android powered device.
  • 1st Stage  is Boot ROM and Boot Loader
  • 2nd Stage is  Kernel
  • 3rd Stage is Init 
  • 4th Stage is Zygote and DVM
  • 5th Stage is SystemServer and Managers 
First stage Boot ROM & Boot Loader 
On pressing POWER button, the Boot ROM code starts executing from a pre- defined location which is hardwired in ROM. It loads the Bootloader into RAM. 

Bootloader is code that is executed before any Operating System starts to run. Bootloaders is a low-level code contains the instructions that tell a device how to start up and find the system kernel.


The bootloader usually lives on the system board in non-volatile memory and is often specific to a device.

The boot loader is usually split into stages. Primary Boot Loader and Secondary Boot Loader.

The bootloader can be found at:

<android source>/bootable/bootloader/legacy/usbloader

This legacy loader contains 2 important files:

1- Init.s :: Initializes stacks, zeros the BSS segments and  call_main() in main.c
2- Main.c :: Initializes hardware (clocks, board, keyboard, console) and creates linux tags
Primary Boot Loader will load Secondary Boot Loader from a specific sector on the disk, then Secondary Boot Loader will initialize the system and load the kernel from 'boot' flash partition into RAM.

Second Stage Android kernel

The Android kernel starts in a similar way as the linux kernel.  As the kernel launches, is starts to setup cache, protected memory, scheduling and loads drivers. When the kernel finishes the system setup, it looks for “init” in the system files. 

Here one question came into picture. What is the difference between the linux and android kernels? 

Here's a list of changes/addons that the Android Project made to the Linux kernels:-
  1. Binder: It is an Android specific interprocess communication mechanism and remote method invocation system.
  2. ashmem:  "Android Shared Memory". It is a new shared memory allocator, similar to POSIX SHM but with a different behavior and sporting a simpler file-based API.
  3. pmem: "Process memory allocator": It is used to manage large (1-16+ MB) physically contigous regions of memory shared between userspace and kernel drivers.
  4. logger:  This is the kernel support for the logcat command.
  5. wakelocks: It is used for power management files. It holds the machine awake on a per-event basis until wakelock is released.
  6. oom handling: It kills processes as available memory becomes low.
  7. alarm manager: It lets user space tell the kernel when it would like to wake up.
  8. RAM_CONSOLE: Allows to save kernel printk messages to a buffer in RAM, so that after a kernel panic they can be viewed in the next kernel invocation.
  9. USB gadget driver for ADB
  10. yaffs2 flash filesystem
Third Stage init process
Init is the very first process, we can say it is a root process, or the grandfather of all processes. The init process has two responsibilities.
     1- Mounts directories like /sys , /dev or /proc
     2- Runs init.rc script
- The init process can be found at /init :: <android source>/system/core/init
- Init.rc file can be found at :: <android source>/system/core/rootdir/
Android has specific format and rules for init.rc files. 
More information about this rules  used for and init.rc file detail I will post in next blog.
At  this stage, We can finally see the Android logo in our device screen.
Fourth Stage Zygote and Dalvik
In Java, As we know that a separate Virtual Machine instance will popup in memory for separate per app. But in the case of Android, the VM should run as quick as possible for an app. Here is one question comes in mind what happens if we have several apps thus launching several instances of theDalvik  (VM)?, it would consume an immense amount of memory.
To overcome this problem, the Android OS has a system called “Zygote”.  The Zygote enables code sharing across the Dalvik VM, achieving a lower memory footprint and minimal startup time.  Zygote is a virtual machine process that starts at system boot. The Zygote preloads and initializes core library classes.
 The Zygote loading process: Load Zygote Init class: 
<android source>/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
registerZygoteSocket() :: It registers a server socket for zygote command connections.
preloadClasses() :: Is a simple text file that contains a list of classes that need to be preloaded, you can find the file at <android source>/framework/base
preloadResources()  :: Everything that is included in the android.R file will be loaded with this method (themes and layouts).
At this time, you can see the boot animation.
Fifth Stage SystemServer and Managers..
After zygote preloads all necessary Java classes and resources, The Zygote forks a new process to launch the System Server. 
  • The system server is the core of the Android system and it is started as soon as Dalvik is initialized and running. 
  • The other system services will be running in the context of the System Server process. 
  • The first thing that happens is that the server will load a native library called android_servers that provides interfaces to native functionality.
  • Then the native init method that will setup native services is called. 
  • After setting up the native services it create the server thread. This thread will start the remaining services in the system according to the necessary start order.
  • Each service is running in a separate Dalvik thread in the SystemServer process.
Once System Services up and running in memory, Android has completed booting process, At this time “ACTION_BOOT_COMPLETED” standard broadcast action will fire.
Following is the Services started by SystemServer:- 
Core services:
Starting power manager
Creating the Activity Manager
Starting telephony registry
Starting package manager
Set activity manager service as system process
Starting context manager
Starting system contact providers
Starting battery service
Starting alarm manager
Starting sensor service
Starting window manager
Starting Bluetooth service
Starting mount service
Other services:
Starting status bar service
Starting hardware service
Starting NetStat service
Starting connectivity service
Starting Notification Manager
Starting DeviceStorageMonitor service
Starting Location Manager
Starting Search Service
Starting Clipboard Service
Starting checkin service
Starting Wallpaper service
Starting Audio Service
Starting HeadsetObserver
Starting AdbSettingsObserver
Now we have finally completed the booting process (system service are up and running in memory).
Need to analyze the Android Bootup?
The logcat ::  Use adb to get the booting process events from the logcat.
‘adb logcat –d –b events | grep “boot”
‘adb logcat –d | grep preload’

 
[tutup]