getCallingPid: document when to use it

Generally for debugging only, not for security reasons.
Needed to be documented for a long time.

Fixes: 383169393
Test: N/A
Change-Id: Ic688fb153975dde5bf27b113f0a9a679f71631d6

Author: Steven Moreland

libs/binder/include/binder/IPCThreadState.h

@@ -64,7 +64,10 @@ class IPCThreadState {
      * Returns the PID of the process which has made the current binder
      * call. If not in a binder call, this will return getpid.
      *
-     * Warning: oneway transactions do not receive PID. Even if you expect
+     * Warning do not use this as a security identifier! PID is unreliable
+     * as it may be re-used. This should mostly be used for debugging.
+     *
+     * oneway transactions do not receive PID. Even if you expect
      * a transaction to be synchronous, a misbehaving client could send it
      * as an asynchronous call and result in a 0 PID here. Additionally, if
      * there is a race and the calling process dies, the PID may still be

libs/binder/ndk/include_ndk/android/binder_ibinder.h

@@ -419,6 +419,9 @@ binder_status_t AIBinder_unlinkToDeath(AIBinder* binder, AIBinder_DeathRecipient
  * This can be used with higher-level system services to determine the caller's identity and check
  * permissions.
  *
+ * Warning do not use this as a security identifier! PID is unreliable as it may be re-used. This
+ * should mostly be used for debugging.
+ *
  * Available since API level 29.
  *
  * \return calling uid or the current process's UID if this thread isn't processing a transaction.

libs/binder/rust/src/state.rs

@@ -101,7 +101,10 @@ impl ThreadState {
     /// dies and is replaced with another process with elevated permissions and
     /// the same PID.
     ///
-    /// Warning: oneway transactions do not receive PID. Even if you expect
+    /// Warning: do not use this as a security identifier! PID is unreliable
+    /// as it may be re-used. This should mostly be used for debugging.
+    ///
+    /// oneway transactions do not receive PID. Even if you expect
     /// a transaction to be synchronous, a misbehaving client could send it
     /// as a synchronous call and result in a 0 PID here. Additionally, if
     /// there is a race and the calling process dies, the PID may still be