Android: parcelable/bundle/ibinder

Public interface

Parcelableclass Overview

Interface for classes whose instances can be written to and restored fromParcel. Classes implementing the parcelable interface must also have a static field calledCREATOR, Which is an object implementingParcelable.CreatorInterface.

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~

 

Public final class

Bundle

Extends object
Implements parcelable cloneable a mapping from string values to various parcelable types. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ 'Public Interface

Ibinder

Android. OS. ibinder

Class Overview

Base interface for a remotable object, the core part of a lightweight Remote Procedure Call mechanic designed for high performance when Discovery Ming in-process and cross-process CILS. this interface describes the abstract protocol for interacting with a remotable object. do not implement this interface directly, instead extend fromBinder.

The key ibinder API istransact()MatchedBinder.onTransact(). These methods allow you to send a call to an ibinder object and receive a call coming in to a binder object, respectively. This transaction API is synchronous, such that a calltransact()Does not return until the target has returned fromBinder.onTransact(); This is the expected behavior when calling an object that exists in the local process, and the underlying inter-process communication (IPC) Mechanisms ensures that these same semantics apply when going processing SS processes.

 

Role: it is the basic interface of the core part of the remote object and Lightweight Process calling mechanism. This interface describes the abstract protocol for interaction with remote objects. Generally, you do not directly implement the ibinder interface, but implement its subclass: binder.

The most important APIs of ibinder are the binder. ontransact () APIs corresponding to transact (). These APIs are synchronized.

 

The data sent through transact () isParcel, A Generic Buffer of data that also maintains some meta-data about its contents. the meta data is used to manage ibinder object references in the buffer, so that those references can be maintained as the buffer moves into SS processes. this mechanism ensures that when an ibinder is written into a parcel and sent to another process, if that other process sends a reference to that same ibinder back to the original process, then the original process will receive the same ibinder object back. these semantics allow ibinder/binder objects to be used as a unique identity (to serve as a token or for other purposes) that can be managed into SS processes.

 

Transcat () transmits data through parcel. During the interaction between processes, the ibinder/binder objects are consistent.

 

The system maintains a pool of transaction threads in each process that it runs in. these threads are used to dispatch all IPCS coming in from other processes. for example, when an IPC is made from process a to process B, the calling thread in a blocks in transact () as it sends the transaction to process B. the next available pool thread in B has es the incoming transaction, callbinder. ontransact () on the target object, and replies with the result parcel. upon processing its result, the thread in process a returns to allow its execution to continue. in effect essentially, other processes appear to use as additional threads that you did not create executing in your own process.

 

The whole IPC (inter-process communication) process is like this: when the call thread of process a sends transaction to process B, it blocks itself in the transact. The idle thread in process B receives the transaction and calls the binder to the target object. ontransact () and reply with the result parcel. After the thread in process a receives the message, it continues to run from the blocked place.

 

The binder system also supports recursion extends SS processes. for example if process a performs a transaction to process B, and process B while handling that transaction calltransact () on an ibinder that is implemented in, then the thread in a that is currently waiting for the original transaction to finish will take care of calling binder. ontransact () on the object being called by B. this ensures that the recursion semantics when calling remote binder object are the same as when calling local objects.

 

The binder system also supports recursion between processes.

 

When working with remote objects, you often want to find out when they are no longer valid. There are three ways this can be determined:

• Thetransact()Method will throwRemoteExceptionException If you try to call it on an ibinder whose process no longer exists.
• ThepingBinder()Method can be called, and will return false if the remote process no longer exists.
• ThelinkToDeath()Method can be used to registerIBinder.DeathRecipientWith the ibinder, which will be called when its containing process goes away.

Common member methods:

Public Abstract Boolean transact (INT code, parcel data, parcel reply, int flags) since: API Level 1

Perform a generic operation with the object.

Parameters

Code	The action to perform. This shocould be a numberFIRST_CALL_TRANSACTIONAndLAST_CALL_TRANSACTION.
Data	Please alled data to send to the target. Most not be null. If you are not sending any data, you must create an empty parcel that is given here.
Reply	Stored alled data to be stored ed from the target. May be null if you are not interested in the return value.
Flags	Additional operation flags. Either 0 for a normal RPC, orFLAG_ONEWAYFor a one-way RPC.

Throws

RemoteException

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

 

Public class

Binder

Extends object
Implements ibinder

Class Overview

Base class for a remotable object, the core part of a lightweight Remote Procedure Call mechanic definedIBinder. This class is an implementation of ibinder that provides the standard support creating a local implementation of such an object.

Most developers will not implement this class directly, instead using the aidl tool to describe the desired interface, having it generate the appropriate binder subclass. you can, however, derive directly from binder to implement your own custom RPC protocol or simply instantiate a raw binder object directly to use as a token that can be shared using SS processes.

 

The binder is mainly used for remote communication between processes, and the core mechanism of these communication is implemented by ibinder. You can also directly derive subclass from binder and implement your own RPC protocol.

 

Common member methods:

 

Protected Boolean ontransact (INT code, parcel data, parcel reply, int flags) since: API Level 1

Default implementation is a stub that returns false. You will want to override this to do the appropriate unmarshalling of transactions.

If you want to call this, call transact ().

Throws

RemoteException