转自https://android.googlesource.com/platform/system/tools/aidl/+/brillo-m10-dev/docs/aidl-cpp.md。
Background
“aidl” refers to several related but distinct concepts:
- the AIDL interface definition language
- .aidl files (which contain AIDL)
- the aidl generator which transforms AIDL into client/server IPC interfaces
The aidl generator is a command line tool that generates client and server stubs for Binder interfaces from a specification in a file with the .aidl extension. For Java interfaces, the executable is called aidl while for C++ the binary is called aidl-cpp. In this document, we’ll use AIDL to describe the language of .aidl files and aidl generator to refer to the code generation tool that takes an .aidl file, parses the AIDL, and outputs code.
Previously, the aidl generator only generated Java interface/stub/proxy objects. C++ Binder interfaces were handcrafted with various degrees of compatibility with the Java equivalents. The Brillo project added support for generating C++ with the aidl generator. This generated C++ is cross-language compatible (e.g. Java clients are tested to interoperate with native services).
Overview
This document describes how C++ generation works with attention to:
- build interface
- cross-language type mapping
- implementing a generated interface
- C++ parcelables
- cross-language error reporting
- cross-language null reference handling
- cross-language integer constants
Detailed Design
Build Interface
Write AIDL in .aidl files and add them to LOCAL_SRC_FILES in your Android.mk. If your build target is a binary (e.g. you include $(BUILD_SHARED_LIBRARY)), then the generated code will be C++, not Java.
AIDL definitions should be hosted from the same repository as the implementation. Any system that needs the definition will also need the implementation (for both parcelables and interface). If there are multiple implementations (i.e. one in Java and one in C++), keep the definition with the native implementation. Android now has systems that run the native components of the system without the Java.
If you use an import statement in your AIDL, even from the same package, you need to add a path to LOCAL_AIDL_INCLUDES. This path should be relative to the root of the Android tree. For instance, a file IFoo.aidl defining com.example.IFoo might sit in a folder hierarchy something/something-else/com/example/IFoo.aidl. Then we would write:
LOCAL_AIDL_INCLUDES := something/something-else
Generated C++ ends up in nested namespaces corresponding to the interface’s package. The generated header also corresponds to the interface package. So com.example.IFoo becomes ::com::example::IFoo in header “com/example/IFoo.h”.
Similar