Android communicates between two apps through Aidl

① Android interface definition language (Aidl), which aims to realize cross process call. Process is the carrier of program execution in OS. A program corresponds to a process. Different processes refer to different programs. Aidl realizes the call between different programs.

② the main thread communicates with the sub thread using the handler. The handler can send messages in the sub thread and process messages in the main thread, so as to complete the communication between threads. Even if there are multiple threads, it is still a program.

③ different programs need to communicate through Aidl. There can be many communication modes, and Aidl is one of them. The result of the implementation is like its own program calling its own other methods, which feels like a program.

Business scenarios: for example, shopping app needs to be paid, shopping app is Taobao, and payment app is Alipay. Therefore, different programs are needed to communicate.

【MyService】

[prompt]

① create service

② if it is not created through the above method, be sure to register

[Code]

【layout_main】

Add button, click for easy calling

【MainActivity】

[effect]

Click to output the contents of the pay method in the service

The code is the same as above

[registration]

I. when registering (Android: enabled = "true" Android: exported = "true"), set it to true, expose the service, and another app can access it

II. Add "< intent Filter >". Since it is not the same app, filter the intent through the intent filter and let another app start the service through action

[Code]

[prompt] the methods defined in the interface should be consistent with those in mybinder in service

[prompt] inherit ipay.stub. Before that, you must make project, otherwise there will be no association

【layout-main】

[prompt] i. the package name should be the same. Copy it according to the directory location. Copy it directly in the folder through the following methods. "You can view the project structure here, and you can see that the package names are the same"

II. Make project is also required after copying

[installation]

Install apppayprovider before apppayuser.

[effect]

Transfer the view in run to apppayprovider and click the pay button in the simulator apppayuser to execute the content in the pay method in myservice in apppayprovider.

① Opening a service across apps means that the app providing the service needs to set an intent filter, and the app controlling the service needs to pass. Set the action and package name with setaction and setpackage methods to start the service. The same app only needs to specify the service to start.

② Mybinder instances across apps need to be obtained through Aidl. The two applications define the same interface method, get the binder instance through the corresponding Aidl name. Stub.asinterface method, and then it is different from mybinder of the same app.

③ The use of mybinder objects across apps must catch exceptions, which are not required for the same app.

④ Many similar functions can be implemented according to the simple example above.

@H_ 403_ 812@

Error reason: the application providing the remote service and the application calling the remote service are not the same application, and the two applications use the same applicationid. To install on the same phone, they have to set different applicationid (buy. Gradle)

About applicationid: applicationid defaults to the package name of the application, which can be modified and has corresponding naming rules. Set setpackage in bindservice intent. This is not the literal application package name, but the application ID of the application, which will also cause bindservice to return false. For more information, please refer to the blog: gradle learning setting applicationid（ https://www.jianshu.com/p/4653c8a38771 ）

When I first started to solve the problem, I always focused on the code for compatibility. I didn't get any information from the official website.

Park friends said that it is OK to set targetsdkversion to 28.

Targetsdkversion sets the target version of the application. When the Android version is lower than the target API of the app, the Android mobile phone version API, i.e. 28, will be used. When the app target version is lower than the Android mobile phone version, the app target version API will run in the target version behavior on the Android mobile phone, that is, the target version is set to 28 and run in the API 28 behavior on the mobile phone of api30, This is the upward compatibility of app.