Generalize guidance against embedding generated IDL code in APIs.
The text was already about AIDL, but it is more generally applicable to
other APIs that have their own generation mechanisms.
This text will be cited in some of my other work, so this adjustment makes
it more relevant in those other locations.
There is a recent discussion about adding protobuf APIs, and I realized this section focuses mostly on AIDL, but discussions about it are more general.
PiperOrigin-RevId: 712941460
Change-Id: I61655f9368b3e098fce375d54d3d0c9b84ff56b2
diff --git a/api-guidelines/classes.md b/api-guidelines/classes.md
index cd99bd1..8ccd314 100644
--- a/api-guidelines/classes.md
+++ b/api-guidelines/classes.md
@@ -85,12 +85,15 @@
`View` and calling several methods on the `View` to install the backport,
`TooltipHelper` would be an acceptable class name.
-### Do not expose AIDL-generated code as public APIs directly <a name="classes-wrap-aidl"></a>
+### Do not expose IDL-generated code as public APIs directly <a name="classes-wrap-aidl"></a>
-Keep AIDL-generated code as implementation details. Generated AIDL classes do
-not meet the API style guide requirements (for example, they cannot use
-overloading) and are not guaranteed to maintain language API compatibility, so
-we can't embed them in a public API.
+Keep IDL-generated code as implementation details. This includes protobuf,
+sockets, FlatBuffers, or any other non-Java, non-NDK API surface. However, most
+IDL in Android is in AIDL, so we focus on AIDL here.
+
+Generated AIDL classes do not meet the API style guide requirements (for
+example, they cannot use overloading) and are not guaranteed to maintain
+language API compatibility, so we can't embed them in a public API.
Instead, add a public API layer on top of the AIDL interface, even if it
initially is a shallow wrapper.
