On Android, one process cannot normally access thememory of another process.
You must define your AIDL interface in an
.
aidl
file using the Javaprogramming language syntax, then save it in the source code (in the
src/
directory) of boththe 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 toolsgenerate an IBinder interface based on the .aidl file and save it inthe project's gen/ directory. The service must implement the IBinderinterface as appropriate. The client applications can then bind to the service and call methods fromthe IBinder to perform IPC.
To create a bounded service using AIDL, follow these steps:
1. Create the .aidl file
2. Implement the interface
3. Expose the interface to clients
Caution: Any changes that you make to your AIDL interface afteryour first release must remain backward compatible in order to avoid breaking other applicationsthat use your service. That is, because your .aidl file must be copied to other applicationsin order for them to access your service's interface, you must maintain support for the originalinterface.
1. Create the .aidl file
Each .aidl file must define a single interface and requires only the interface declaration and method signatures.
By default, AIDL supports the following data types:
● All primitive types in the Java programming language (such as int, long,char, boolean, and so on)
● String
● List
● Map
You must include an import statement for each additional type not listed above, even ifthey are defined in the same package as your interface.
When defining your service interface, be aware that:
● Methods can take zero or more parameters, and return a value or void.
● All non-primitive parameters require a directional tag indicating which way the data goes.Either in, out, or inout (see the example below).
● Primitives are in by default, and cannot be otherwise.
● All code comments included in the .aidl file are included in the generated IBinder interface (except for comments before the import and packagestatements).
● Only methods are supported; you cannot expose static fields in AIDL.
Simply save your .aidl file in your project's src/ directory and when youbuild your application, the SDK tools generate the IBinder interface file in yourproject's gen/ directory. The generated file name matches the .aidl file name, butwith a .java extension (for example, IRemoteService.aidl results in IRemoteService.java).
2. Implement the interface
When you build your application, the Android SDK tools generate a .java interface filenamed after your .aidl file. The generated interface includes a subclass named Stubthat is an abstract implementation of its parent interface (for example, YourInterface.Stub) and declares all the methods from the .aidl file.
Note: Stub also defines a few helper methods, most notably asInterface(), which takes an IBinder (usually the one passed to a client's onServiceConnected() callback method) and returns an instance of the stub interface. See the section Calling an IPCMethod for more details on how to make this cast.
There are a few rules you should be aware of when implementing your AIDL interface:
● Incoming calls are not guaranteed to be executed on the main thread, so you need to think about multithreading from the start and properly build your service to be thread-safe.
● By default, RPC calls are synchronous. If you know that the service takes more than a few milliseconds to complete a request, you should not call it from the activity's main thread, because it might hang the application (Android might display an "Application is Not Responding" dialog)—you should usually call them from a separate thread in the client.
● No exceptions that you throw are sent back to the caller.
3. Expose the interface to clients
Once you've implemented the interface for your service, you need to expose it
To clients so they can bind to it. To expose the interface for your service, extend Service and implement onBind() to return an instance of your class that implements the generated Stub (as discussed in the previous section). Here's an example service that exposes the IRemoteService example interface to clients.
Now, when a client (such as an activity) calls bindService() to connect to this service, the client's onServiceConnected() callback receives the mBinder instance returned by the service's onBind()method.
The client must also have access to the interface class, so if the client and service are in separate applications, then the client's application must have a copy of the .aidl file in its src/ directory (which generates the android.os.Binder interface—providing the client access to the AIDL methods).
When the client receives the IBinder in the onServiceConnected() callback, it must callYourServiceInterface.Stub.asInterface(service) to cast the returned parameter to YourServiceInterface type. For example:
You must define your AIDL interface in an
.
aidl
file using the Javaprogramming language syntax, then save it in the source code (in the
src/
directory) of boththe 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 toolsgenerate an IBinder interface based on the .aidl file and save it inthe project's gen/ directory. The service must implement the IBinderinterface as appropriate. The client applications can then bind to the service and call methods fromthe IBinder to perform IPC.
To create a bounded service using AIDL, follow these steps:
1. Create the .aidl file
2. Implement the interface
3. Expose the interface to clients
Caution: Any changes that you make to your AIDL interface afteryour first release must remain backward compatible in order to avoid breaking other applicationsthat use your service. That is, because your .aidl file must be copied to other applicationsin order for them to access your service's interface, you must maintain support for the originalinterface.
1. Create the .aidl file
Each .aidl file must define a single interface and requires only the interface declaration and method signatures.
By default, AIDL supports the following data types:
● All primitive types in the Java programming language (such as int, long,char, boolean, and so on)
● String
● List
● Map
You must include an import statement for each additional type not listed above, even ifthey are defined in the same package as your interface.
When defining your service interface, be aware that:
● Methods can take zero or more parameters, and return a value or void.
● All non-primitive parameters require a directional tag indicating which way the data goes.Either in, out, or inout (see the example below).
● Primitives are in by default, and cannot be otherwise.
● All code comments included in the .aidl file are included in the generated IBinder interface (except for comments before the import and packagestatements).
● Only methods are supported; you cannot expose static fields in AIDL.
Simply save your .aidl file in your project's src/ directory and when youbuild your application, the SDK tools generate the IBinder interface file in yourproject's gen/ directory. The generated file name matches the .aidl file name, butwith a .java extension (for example, IRemoteService.aidl results in IRemoteService.java).
2. Implement the interface
When you build your application, the Android SDK tools generate a .java interface filenamed after your .aidl file. The generated interface includes a subclass named Stubthat is an abstract implementation of its parent interface (for example, YourInterface.Stub) and declares all the methods from the .aidl file.
Note: Stub also defines a few helper methods, most notably asInterface(), which takes an IBinder (usually the one passed to a client's onServiceConnected() callback method) and returns an instance of the stub interface. See the section Calling an IPCMethod for more details on how to make this cast.
There are a few rules you should be aware of when implementing your AIDL interface:
● Incoming calls are not guaranteed to be executed on the main thread, so you need to think about multithreading from the start and properly build your service to be thread-safe.
● By default, RPC calls are synchronous. If you know that the service takes more than a few milliseconds to complete a request, you should not call it from the activity's main thread, because it might hang the application (Android might display an "Application is Not Responding" dialog)—you should usually call them from a separate thread in the client.
● No exceptions that you throw are sent back to the caller.
3. Expose the interface to clients
Once you've implemented the interface for your service, you need to expose it
To clients so they can bind to it. To expose the interface for your service, extend Service and implement onBind() to return an instance of your class that implements the generated Stub (as discussed in the previous section). Here's an example service that exposes the IRemoteService example interface to clients.
Now, when a client (such as an activity) calls bindService() to connect to this service, the client's onServiceConnected() callback receives the mBinder instance returned by the service's onBind()method.
The client must also have access to the interface class, so if the client and service are in separate applications, then the client's application must have a copy of the .aidl file in its src/ directory (which generates the android.os.Binder interface—providing the client access to the AIDL methods).
When the client receives the IBinder in the onServiceConnected() callback, it must callYourServiceInterface.Stub.asInterface(service) to cast the returned parameter to YourServiceInterface type. For example:
扫一扫
238
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
