 next we will try to color android kernels that is mostly we will color the driver part in kernel so within these five topics we are going to cover first is android system architecture that you will are familiar with this architecture then we will see a runtime work through so how android system boot and what are the services will start from the booting process to the till system will get up to work and then we will see for that binary driver that is inter process communication mechanism in android and then layer interaction so those four layer are there application, application, framework, libraries and kernel layer so how they are interactive when some system is running some application or try to access kernel driver and then last we will check it power manager that is also power management driver in android system so you are all familiar with the architecture so mainly we will focus on this Linux kernel part so Linux kernel now some different different drivers so apart from that Linux kernel we also need some other drivers because we are using this android system we are installing mobile phones or some other tablet system so we need camera driver, wifi driver this flash memory driver, audio driver and binder IPC driver and power management so these two binder IPC driver and power management is major modification in the Linux kernel driver so what is android kernel so it is not fully, android is not fully Linux system it is just realized in Linux kernel 2.6 so why we are mainly using the Linux kernel because it is already provided as process management then memory management, then security and the network state so this kernel is basically layer between hardware and software so this is the reason why we are using Linux kernel so it is already contained in memory management and process management so we don't need to create the same code for android also and this is permission based security model so we are familiar that we can provide permission to group user and others also so then Linux system so the same thing we are using in android also and the main use is support for same libraries so those library part will cover that question so in this we are sharing the library between different application so these are the main modifications are made to Linux kernel first is binder driver well smem that is android share memory driver that is sharing between two different applications how they are sharing memories between two different applications then alarm driver, power management memory killer kernel debugger and logger that is already explained more layer is that that is hardware abstraction layer so this is the what hardware abstraction layer is providing it is providing the libraries these basic libraries are C and C++ libraries so then it provides the interface of the libraries to the Linux kernel now why we need this hl layer so it is the big first one thing is that not all companies are familiar with standardized kernel driver so some need to some modification then only it can communicate with Linux kernel so at that time this hl layer will be useful and then add some hardware specific requirement are there at that time this hl layer will be useful now we will see the runtime work through so how the system will boot so android booting is a similar to linux booting when you will put it power on your android device so boot loader will load linux kernel linux kernel will start the first process which is init this init then will start the other demons like usb demon then android debugger debugger bridge demon and debugger demon and radio interface layer demon in this usb demon is just like usb and there is android debugged bridge demon so this is the mainly when you are collecting your device through the computer at that time this android debugged bridge demon will be used and this debugger demon is mainly involved when your application throw some exception or some error at that time this demon is used radio interface layer demon is just like your sim card or that radio interface will be used once this demon is started init will start zygode now what is the zygode so basically application has run on delvic vm so whenever you start application each application will be done delvic vm will be started so each application need delvic vm so if you start delvic vm each and every time so it will create some sort of overhead so what we are doing we are putting zygode process which will do clone of the delvic vm whenever it will start only once then it will put clone and then clone will be used by application so this is the delvic vm install it will initialize then it will link all core libraries so zygode is linked with all core libraries so whenever application will stop it will allow it will link application to this whole library and say the library is on application so those are sharing libraries so initially when application will start it will not create some different memory space for those libraries it will save it and whenever application try to run those libraries at that time only it will use copy and write and it will allocate some other different memory for those libraries now once zygode process is started so it will start run time process that is ended run time and then it will start the service manager basically the service manager is the complex manager for the binder handle service once the service manager is completely started run time will inform the zygode to start the remaining system then zygode will create start the delvic vm and it will start the system those system will later on start the surface failure that is our surface touch on the mobile device and then audio failure so these are main driver parts so those are now started and after this they are providing some sort of services to the other application which we are creating and we are using so for those so those application can use this surface failure and audio failure surface failure and audio failure to register their application to the service manager so they are registering their services to service manager and later on this binder will come in picture when you are using these services so once this is done then system will start the remaining manager there is window manager, activity manager, package manager those are collected with window manager is managing the windows which are open once they started they also need to register their services to the service manager so they will register their services to start some application so now you open the menu on your mobile device so how it will work so this is the way it will work so zygote will claim that Dalvik VM other than Dalvik VM the whole will run menu list it is there in each and every process so lipsy are linked in each and every process through zygote itself starting another application so same way zygote will claim the VM and between another application you will get delvik VM and one more thing is that to reduce the starting time zygote will whenever new application will be started the memory clone will be done by zygote so application memory structure and zygote memory structure are almost same so first of all the ITC list is interversal communication so what is the ITC so you are exchanging data with some other application like you have some application which is going to get some GPS location so the GPS location will give your data that location of your mobile device to your application this is the exchange between two different applications so this is the interversal communication so why we interversal communication need so we cannot directly your application cannot directly call to the GPS location dial up because each application running in all address space so they cannot access other application memory area so for that we need interversal communication then what is the data isolation so isolation is there through providing normal memory address space and use of the ITC will interact sorry it will direct interaction with the application so it will avoid some sort of hacking when you are trying to some application GPS location it will modify the location your mobile will show some right GPS location so this will be avoided normal normal line up so what are the IPC mechanism are there first of all is signal just as simple oldest mechanism it is one process will use some specific signal and those signal are different some 5 type of signal I have suppose I will get this type of signal type 1 then I have to do this type of work type 2 then I will do this type of work so they say just some sort of signal like it is similar to we can say some type 3 then left is a pipe that is an undirectional channel you need directional channel so that is only one way to communicate if there is a pipe channel between server client and server so either client can send data or server can send data both of them are not able to send data so if you want to communicate bidirectional then you need 2 pipes same process then next one is socket that is the bidirectional client will open the socket on server side both of them can use that socket to send and receive the data then next one is semaphore it is just a variable semaphore can be like a file descriptor you are sharing 2 application are sharing same file and they want to use same file descriptor can be a semaphore or may be some pointer where pointer is pointing to some area or location so at that time the pointer can be semaphore so that can be shared between 2 process now next one is the message queue so in that message queue is as simple as you have one message queue client is writing and server is reading after some time server is writing and client will read those things then next one is shared memory you have some shared physical memory are there which is allocated by kernel bug that server will allocate those memory and same thing like as a message that client will write data in that shared memory and server will read and some other specific location where server will write and from that location client will read data so and now what is the IPC mechanism in the android so android provides the binder that is the lightweight no-procedure core mechanism why we need to create this binder driver for IPC mechanism so what was the problem with old mechanism application server may run in separate process but communication must be must communicate and save data so like if you are using semaphore so you can just save variable you can save a bunch of the data so at that time this you need and IPC can and those old mechanism are providing us some sort of overhead so when you are communication is you are communicating with server at that time overhead will be high so to avoid that we need binder driver the solution is provide some driver which facilitated inter process communication so those facilities can be provided by same memory location same memory one more thing we can create is that on server side we can create a pool of thread pool which will reply to each and every request individually so suppose like if you are using socket that is for inter process communication mechanism so suppose a client will connect to the server so 100 client are there each and every client will connect to different different socket so it will need 100 socket so server will need to manage this 100 socket that is quite difficult than managing the 100 thread next is reference counting if your memory is so the reference counting how much client is referring to this memory memory page is quite easy to refer and synchronization is called between process so how the synchronization will not good in IPC mechanism so suppose you are connected with socket or pipe with server so whenever you are writing at that time server can also be writing so whenever you are writing some paragraph in middle of that server will reply so that is not synchronization so in this in this diverse facility what we are doing client will call the server we will client will wait and then server will reply after that client will again call the server function so caller and caller both are in same process so at that time we don't need to worry about those inter process communication mechanism because they can create their object because in same process and they can use their services so but what if the caller and caller both are on different process so how can we create how can we provide the inter process communication so for that we need interface so how we are creating so basically we are creating the proxy object we are creating caller side and we are creating stop object this proxy object is just a proxy like we are using a network proxy that is we are collecting to the internet so same way this client caller we use proxy object to collect the the query and this stop object is directly collected to with the server which is going to the server function which client will use so this proxy object will call the binary driver that is in kernel and the kernel will pass the relative to stop object and stop object will reply to the kernel and kernel will reply to proxy so this is the small interaction between two processes so here is process one and process two is the client and process two is the server so process two providing some service implementation or process one want to call the function of the process two so how they are using how IPC work here so process one will inform the service manager that I want to use this service this interface so service manager will return the object that is the proxy object to the client process one and using this call interface that proxy object it will call the proxy proxy stop stop object that is in the process two and the stop object will directly use the server implementation so this is the blue line will call it this directly so how it is client will go to this proxy object will interact with stop and then stop will interact with server implementation so this way how the client will get service from server so some sort of more detail in how binder will exactly will work so the binder will provide the binder object that is the interface to access to the remote process and the binder protocol that is some protocol to communicate with the driver so how the driver will work which driver will reply so that is the main protocol then I binder interface this is the thing which is returned by the service manager so I binder object will be returned to the client and client use this I binder object to communicate with the remote procedure then binder token each and every binder have unique identifier that is called binder token so this is the binder this whole facility are provided binder so binder is not providing interface as communication so what can you do with binder so first we indirectly so by using binder you can pass the share variable and you can pass the memory location and you can share the memory between two different processes then what is the direct implementation provided by binder first one is the notification so notification are attached with the binder that is a link to depth so this notification will occur whenever the binder process will get killed so at that time the manager will say manager will send the binder that is collected with those that binder that your binder is get killed you can re-collect it or you can wait it so this may be notification purpose is used by windows manager so like some windows is open which is providing some interface and those interface are collected with binder suppose your binder is get killed so still your window is there but that window manager will implement that window that you can turn off so the notification is by windows manager then calls so we can call two way synchronize synchronize is two way communication so once you client call the server and it will reply it will get suspended reply reply from the server so that is the two way communication and one way communication is possible just client will inform the server I have written some data you can read it whenever you want so that is done and client will do other work so that is one way and two way communication will also done the binder then identify so in this thing whenever client will collect to the server through binder it will send the data so in that data client will put it's ID vlick ID so that is the vlick ID server will get and it will identify client whether it is authenticated or not so therefore that personal binder it is useful then managing all the memories said thread reference count so reference count is just how many client are referring to the binder some boundary space so now how binder will interact with service manager so first of all first step is to when service provider it is our server will start it will register itself to the service manager so it will register every service at the service manager side and the service manager will inform that about registration into the binder driver now when arms are when client can use the service so client do not know exactly memory address there is address of the remote binder he know only interface client cannot directly communicate with the binder so he know just interface so it will first go to interface that is the service manager so client will ask for the great service and that service manager will inform the binder for the service and binder will reply the name and address of the interface so that will pass to the client and client then directly will use that those address and interface to communicate with server so now the binder implementation so binder is implemented mainly in a by 3 layer first is our API for application those we are writing in java that is 3++ and then kernel that is our binder so first of all it is API layer so in application layer mainly we are using AIDL AIDL is interface definition language so what is exactly this task task is to facilitate implementation of Android application so it make it easy so whenever we are writing some java file java file also after writing the java file AIDL parser will use and this parser will create the class file so this class file will use 2 space one is proxy side that is a proxy object it client and then use for stuff class that is a server side so here this AIDL that is a proxy object and the stuff class so now that java API those API will try to cover the middle layer so we try to reduce the hmas work on middle layer that is c++ so now how to communicate with server so transaction is data from one process to other is called transaction so what is the parcel this data send over the transaction is called parcel so data can be bunch of the object or maybe some other extra variable like integer or some other so all together will create a parcel so now we want to send this parcel to the server side so what we will do we will do marshalling that is the building the parcel so we will create a new object that is called parcel and we will send to the server so this is one example of the parcel so when we are defining the target then binder driver command which command we want to run on this binder then cookies that is used for communication between the client and server then server ID so client will identify himself himself to server then data data will contain a bunch of objects so parcel is just container of data and parcel can be contain floating data that is a marshalling data and it may be possible it contains on marshalling data so whenever you are doing marshalling through some using some mechanism binder will send this thing to the server side and server will on marshalling this data and it will use that data so to create the parcel that parcel class is there which will help to write your data in the parcel so some methods are there write stream which will write in the parcel that is provided by parcel class now the next one is wooden layer so it is implemented in c++ and it will provide the interaction between there is a that application layer and the to kernel layer and that marshalling and marshalling will be provided through wooden layer kernel data will provide some sort of the system called that is operation open and some IOCTN operation system called to IOCTN basically that control a stream device so you have some devices there I don't know exactly which type of how it is working but it will help try to control some devices so what is the difference between the binder driver and the Linux so in binder driver server will maintain the status per thread whether status is running or not that thread is suspended thread will wait for high so that status is maintained by server and in Linux socket we are maintaining the status of the socket socket are used or not if it is not used so how many duration when last last use so this is the binder driver come in picture so what is the application process will ask context manager context manager is basically service manager where the whole provider has registered their services so it will ask for service that is good service and it will reply so now it will once is reply interface now it is used as interface and it will call some function to the function with some argument so this will pass to the binder driver will do marshalling stop and it will pass to the pass to the thread at the server side that thread will do un-marsalling do some process and reply to the client so this is the cold wind return now what are the limitations of the binder IPC so binder use the binder use the command to communicate over the between two different processes so we are not interacting it directly we are indirectly we are interacting so it may be possible somewhere we need to access their name and boundary pages directly at that time this binder driver will not useful and second thing is that since we are doing that marshalling so that marshalling and un-marsalling is some sort of similar to the encoding and decoding which we are using in a network when we are sending a packet so client will encode the packet and it will send to the server and server will decode so same way we are doing the marshalling so if you want to send large amount of data at that time this marshalling and un-marsalling will create a overhead so that is the limitation of the binder now we will see the layer interaction so how basically this layer will interact with each other so there are only three way to interact interaction first is the application layer which will talk with the runtime services and runtime service will communicate with the libraries that live see another one is application will communicate with the runtime service and runtime service will communicate to live see and third one is application will communicate with runtime service and it will communicate with native domain and native domain will communicate with live see so domains are basically those processes which are running on the ground which will not directly interact with user so which interaction you are going to use so it is basically depend on the application and libraries so which are the easiest way which will give lowest overhead so this interaction we are going to use for those interaction so basically our application and application framework those two layer are written in java and libraries and this kernel part is written in c and c++ so how go java will communicate to the c++ so in the meantime this java will come in picture so java native interface which will define the name coding and conversion so that java vm can find and code the libraries and that is as I mentioned mainly it is the bridge between the application framework and the library so java class can use those c++ library and they can so first layer interaction so in these three application will call the runtime services so application is running in application one which is top of and the runtime service is running in application framework so at that time bounder IPC will happen so this is just directly shown the initially application will first get services from the service manager and service manager will do replies to the interface and then application will communicate to the runtime service so this will happen then runtime service will call to the native service which are running in the libraries so here we are moving from application framework to library so we did jli so here jli will be useful and then runtime services will use that rrfxn layer library so this is the initial initially that one layer is there between this library which is providing some c++ tab and some easy interaction with the kernel which are not separated direct interaction so at that time hl library will come and so native service will call hl library and hl library will call kernel-dialog so here is the example application application will get interface through binder IPC mechanism then application will call the co-manager that is service provider of the location then this location manager will ask for interact with gps provider so this is the runtime service part then this runtime service will communicate with the service so this is similarly native service and then hl library so here is our gps location provider so that is our native service and libgps that is our library provided by hl layer and it will call to the kernel what is the main so in this thing what is the application runtime first it will call the runtime service runtime service will interact with the native service then it will go to the native service part and hl library and then it will communicate with kernel so here is the difference between the previous method and this method is that binding binder IPC in this case binder IPC is happening here so native service will get the interface for the native service binding will get interface for native service and it will call native service and it will use hl library and it will call kernel so what is the example is media player so one application will call the media player so media player will ask that audio player there are libraries which are used for audio it will call audio player in the library this will use hl library and it will directly interact with kernel driver so this is the application called runtime service and it will go to native service binding and native service binding will call demone instead of native service it will call demone native service use hl library and it will go to kernel so this is the example for a telephone when you are using telephone means you are trying to call or receive some call or sending with a message at that time this telephone will open so application will call telephone manager telephone manager and this will call telephone manager will call rild that is radio interface lower demone that is started and it will start so it will interact with this is the demone and it will call hl library and hl library will interact with kernel last one is power manager first one is advanced power management that is the simplest easiest and it is the coldest bias based power management so concern configuration are there in bias if you set up and your monitor will get off that will done in line up and second thing is advanced configuration power interface in which you will can do some more configuration which is useful so basically scp is far better than apm and what android we use android is not using neither using apm nor using acp instead of that android have their own power extension cold power manager so how power manager will work so basically your device is limited battery mobile device is only limited is only desktop as infinite battery so which thing you can control in your mobile device so mainly first thing is come is your screen so if your model is ideal for a few 5 second your screen will be off so at that time you can save power and the keyboard light suppose your model is with keypad and at that time your keyboard you are not using key so keyboard light we can put it off so this way we can reduce the power in mobile device so this is power so we are using so weight lock is some sort of the signal which we are sending to the power manager and power manager will interact with the hardware so there are different other weight lock are there partial weight lock in which we are keeping CPU on obviously we will keep CPU on each and every weight lock so we will put that screen and keyboard light off then we will ask for dim screen at that time we will start the screen in dim mode and then drive to a screen and then we will completely start our screen and then full wake that is we are putting screen on and keyboard light also this is the state machine for power manager so how power manager will work suppose power manager in screen off state so if some user activity will happen then screen and bright will be done so screen will start using full power and when user activity continue then we will be in screen bright state suppose the screen will be ideal for a sometime at that time in after 5 seconds suppose the screen will get dim at that time we will get screen dim mode suppose at that time when some user activity will happen then it will go to the screen bright mode state when we are in screen dim mode and dim dim mode is done which you wait for 10 seconds still user is not interacting with your device so you will put that your screen that is screen off state so here is the application we will sell the weight lock that is partial so you will put the screen off then power manager will inform the driver and the driver will create a new weight lock and it will put it screen off LCD is off here after once application is done its work it will release the weight lock then power manager once it is done power manager will inform the driver and nothing to run we will put CPU off so we don't have any other application so we will put CPU off this reference is good this internal philosophy and android so this youtube one video is there for this one if you want they have described very well how the android internal will work so this is the good reference for the beginner from the android team itself there is android team itself any question that is just one pdf is given that serve on android versus linux when you search on google and you will get some pdf in just pdf they describe which things are modified in linux and this is one also good pdf inter process communication so it is very big around 35 pages are there so they have mentioned each and everything quite in very very detail thank you