Merge "s/NDK/native/ for the cases that apply to other domains." into main

1 files changed, 10 insertions, 11 deletions

diff --git a/api-guidelines/ndk.md b/api-guidelines/ndk.md
index 00f7815..66fb6e0 100644
--- a/api-guidelines/ndk.md
+++ b/api-guidelines/ndk.md
@@ -1,6 +1,6 @@
-# Android NDK API Guidelines
+# Android NDK/Native API Guidelines
 
-Warning: NDK APIs do not support feature flagging.
+Warning: Native APIs do not support feature flagging.
 
 [TOC]
 
@@ -68,7 +68,7 @@ Jetpack C++ APIs are exempt from this rule. See go/jetpack-cpp-guidelines
     ```
 
     This C++ feature is provided for C as a Clang extension, so this should be
-    be used even for NDK headers that must otherwise be C.
+    be used even for headers that must otherwise be C.
 
     A rare exception to this rule will be made for interfaces defined by third-
     parties (e.g. Vulkan or ICU) if upstream is not willing to depend on the
@@ -511,13 +511,13 @@ following exceptions:
 
 ## JNI <a name="jni"></a>
 
-### JNI interop methods should exclusively be in the NDK <a name="jni-ndk"></a>
+### JNI interop methods should exclusively be native APIs <a name="jni-ndk"></a>
 
-As in, always do `AObject_fromJava(JNIEnv, jobject)` in the NDK rather
-than having a `long Object#getNativePointer()` in the SDK.
+As in, always add `AObject_fromJava(JNIEnv, jobject)` to the native API surface
+rather than having a `long Object#getNativePointer()` in the SDK.
 
-Similarly do instead `jobject AObject_toJava(JNIEnv, AObject*)` in the
-NDK rather than `new Object(long nativePtr);` in the SDK.
+Similarly add `jobject AObject_toJava(JNIEnv, AObject*)` to the native API
+surface rather than `new Object(long nativePtr);` in the SDK.
 
 If the native and Java types have the same name, the suffix should be just
 `_fromJava` or `toJava`. If the type names differ, the Java type name should
@@ -539,9 +539,8 @@ Java object’s lifecycle should not be relevant to the native handle.
 Similarly, if a Java object is created from a native object the native
 object should not need to out-live the Java one.
 
-
-Typically this means both the NDK & Java types should sit on a ref-count system
-to handle this if the underlying instance is shared.
+Typically this means both the native & Java types should sit on a ref-count
+system to handle this if the underlying instance is shared.
 
 If the interop just does a copy of the data (such as for a trivial type),
 then nothing special needs to happen.