Merge "Generalize guidance against embedding generated IDL code in APIs." into main
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.
