1. What IPC methods does the Android FrameWork use?

KaoChaDian

  • See if you are familiar with cross-process communication in Linux
  • Have you studied the Android Framework and understand how it works
  • Whether you understand the communication mechanism between Framework components

Linux IPC way

  • The pipe
    • Half duplex, one way, either read or write
    • Typically used between parent and child processes
    • It can be used across processes or within processes
    • As shown in figure 74
      • Fd1 writes fd0 reads
    • In android 4.4 FrameWork code, Looper uses a pipe. Looper’s Java layer corresponds to a class of the same name in the Native layer, which creates a pipe in the constructor
      • As shown in figure 75
  • Socket, the Socket is not a network Socket, but a local Socket
    • Full duplex, can read and write
    • There is no need for a kinship between the two processes (unlike the pipe parent-child relationship)
    • In the Android Framework, Zygote uses sockets
    • As shown in figure 76
  • The Shared memory
    • Very fast, no need for multiple copies (socket and pipe require at least two copies of data, data transfer is not too large), after taking the file descriptor, it is mapped to the memory space of both processes, so that one process can write data, the other process can read, so very fast
    • Processes need not be related to each other
    • In the Android FrameWork, large data transfer is mainly related to images. This paper mainly analyzes the shared memory of Android, taking MemoryFile as an example
      • As shown in figure 77
  • signal
    • One way, how to deal with it is someone else’s business, you do not know
    • Only one signal, no other parameters
    • Signals can be sent to a group of processes at a time (requires permissions)
    • In the Android FrameWork, you use signals to kill application processes
      • As shown in figure 78
  • Binder, further details

2. Talk about understanding Binder

KaoChaDian

  • What’s a Binder for? -> Cross-process communication
  • What is the point of binder?
  • What is the architecture of Binder?

Binder is for communication

  • A binder has two ends, a Client and a Server
  • The Client and Server can be in or out of the same process
  • The Clinet side can make remote function calls to the Server side as well as transfer data
    • As shown in Figure 79, to make a remote call to the call function on the Server, the Client needs to serialize parameters into a buffer first, and then transfer the buffer to the Server through various cross-process communication methods of Linux, and deserialize the buffer data to restore each parameter on the Server. The call function is then called, and the result of the function execution is returned to the Client
    • Figure 79
  • The Binder mechanism provides performance, convenience, and security for cross-process transport

What is the point of binder? (Why Binder is android’s primary IPC communication mechanism)

Binder runs on the driver layer and is a self-invented mechanism that doesn’t use Linux’s cross-process communication technology

  • Performance: Only need to copy once
    • Because of the pipes, sockets need to be transferred to the kernel to communicate across processes, which means that data is copied twice, once from the application layer to the kernel and once from the kernel to the application layer.
    • A binder is a user space that maps a block of physical memory to both the kernel and the target process, so that all you need to do is copy data into the kernel
  • Convenient and easy to use: the logic is simple and direct, not easy to problem
    • Shared memory, while good, is far more complex to use than binders
  • security
    • Common Linux cross-process communication methods, such as sockets, are not secure enough, and IP addresses are open for malicious use, mainly because there is no reliable identity of the caller
    • The reliable way is that identity tags can only be added in kernel mode by the IPC mechanism itself, which Binder does

Communication architecture with Binder

  • Four drivers: Client, Server, ServiceManager, and Binder drivers
  • Note: This figure shows the binder communication of system services. Only system services can be registered with ServiceManager. Application services binders cannot be registered with ServiceManager.
  • The Client is the application process, and the Server is the system service. The Server may run in the system_sever process, or it may be a separate process
  • The ServiceManager is a separate system process
  • Binder is a prerequisite for any process to be started with binder enabled
    • How do I enable binder mechanisms
      • Open binder drive
      • Memory mapping, allocating buffers
      • Start the Binder thread, enter a loop, interact with the Binder driver continuously, and wait for requests from the Client and Server

ServiceManager

Start with the ServiceManager entry function main, as shown in Figure 81

  • The Server starts by registering its binder objects with the ServiceManager
  • SurfaceFlinger, for example
    • As shown in figure 82

Binder Communication layered architecture

  • Three roles: Client, Server, and Binder drivers
  • Hierarchical perspective: application layer, FrameWork layer (Java layer and Native layer), driver layer
  • From the perspective of binder objects, they are divided into two ends: the proxy end and the entity end
  • From the Client side:
    • When you get a BinderProxy, make an IPC call, drop it down to BinderProxy, drop it down to the native Proxy BpBinder object, which in turn forwards the request to IPC Thread State. Send requests to binder drivers via Transact
    • The driver forwards to the Server process
    • The Server process’s binder threads handle the onTransact function and then up the application layer

3. What is the complete IPC communication process?

KaoChaDian

  • Understand the overall architectural principles of Binder (see above)
  • Understand how applications interact with Binder drivers
  • What is the process from client to end of binder invocation?
  • Understand communication protocols in IPC process

As shown in figure 84

Protocol communication process

  • The Client initiates an IPC call to the Server, first writing BC_TRANSACTION instructions to the Binder driver
  • The Binder driver receives this and sends the Client a return receipt BR_TRANSACTION_COMPLETE
  • Binder drivers forward requests to the Server through the BR_TRANSACTION directive
  • The Server receives the request, processes it, and then drives BC_REPLAY to Binder
  • The Binder driver receives a reply from the Server and sends the Server a return receipt BR_TRANSACTION_COMPLETE
  • Finally, the Binder driver forwards the Server results to the Client via BR_REPLY
  • The CLIENT sleeps while waiting for a reply. Procedure
  • Server side binder threads are also dormant outside of processing requests

4. How do Binder objects transfer across processes?

KaoChaDian

  • What are the means of binder delivery?
  • How is binder stored during delivery?
  • Binder object serialization and deserialization process?
  • What does the driver layer do during binder object passing?

The Binder mechanism is too complex, leaving out code and maps

conclusion

Answer the questions on the point

  • Parcel’s writeStrongBinder and readStrongBinder
  • Binder stores principles, flat_binder_object, in parcels
  • So binder_node, binder_ref
  • The target process creates BpBinder from the Handle of binder_ref
  • From BpBinder up to BinderProxy to Proxy at the business layer

conclusion

  • Binder is transmitted across processes through the Parcel, written to the Parcel by writeStrongBinder and read by the target process via readStrongBinder
  • Binder stores flat_binder_object in Parcel. Flat_binder_object is stored in the Binder buffer. Parcel has an array that holds the offset of flat_binder_object, So once the parcel reaches the target process it can restore flat_binder_object based on the offset
  • After the parcel is passed to the Binder driver, the driver takes flat_binder_object from the parcel and creates a series of data structures based on the binder objects inside. This includes creating binder_node for binder entity objects and binder reference binder_ref. A binder entity may correspond to multiple binder reference objects
  • Binder_ref corresponds to a Handle in the target process, which is passed up to create a BpBinder, which is an object of binder in the FrameWork native layer
  • Then BpBinder goes up to BinderProxy, which encapsulates a business-layer Proxy object

5. Talk about Binder’s Oneway mechanism

KaoChaDian

  • What does binder’s Oneway mean?
  • What are the features of Oneway?
  • How does it work?

Oneway communication process protocol diagram

  • As oneway, oneWay is asynchronous to the client side and does not require the Server side to return results, so the overall process looks simpler than non-OneWay
    • Figure 86
  • The Client initiates an IPC call to the Server, first writing BC_TRANSACTION instructions to the Binder driver
  • The Binder driver receives this and sends the Client a return receipt BR_TRANSACTION_COMPLETE
  • The Binder driver then forwards the request to the Server and, with the BR_TRANSACTION directive, the Server does nothing else after the processing is complete

Oneway application in the FrameworkOneway has many application scenarios in the Framework, mainly applicable to system services initiating calls with Binder to application ends. These interfaces are basically oneway, as shown in Figure 88

  • Take lanchActivity as an example: The system service invokes the application to start the activity. Note that reply is null and FLAG_ONEWAY is displayed, so this is a typical Oneway
  • IWindow is also oneway, and WMS calls the application side
  • IServiceConnection is a binder object registered with AMS by the application side during binderService. When AMS holds binder object, it can also initiate binder call to the application side
  • The IIntentReceiver registers the Binder object with AMS when the application registers the broadcast. The AMS receives the Binder object and makes calls to the application

Oneway is widely used for two reasons:

  • One is that OneWay is asynchronous, so it does not block system services even if it takes time for the application side to process these requests
  • Second, Oneway is serialized, and the driver distributes binder calls to the application side one by one, rather than throwing them all at once

conclusion

  • Oneway is an asynchronous binder call (no need to wait for the result to return and move on to the next thing)
  • Server side serialization processing
  • Oneway implementation mechanism