ipcthreadstate物件維護了2個變數
pid_t mcallingpid;
uid_t mcallinguid;
從變數名稱來看，這2個變數儲存了程序的pid和uid，並且由於這兩個變數由ipcthreadstate物件維護，可見它們是與ipc相關的。具體它們儲存的是ipc傳送方的pid和uid還是當前程序的ipd和uid，視情況而定。
在ipc呼叫過程中，被呼叫方需要知道呼叫方的uid和pid，以便被呼叫方用於許可權檢測；所以需要一種方式來提供呼叫方的uid和pid，因此上述2個變數的主要作用就是用於許可權檢測。
那麼我們想象一下，下面描述的情況下，mcallingpid和mcallinguid又應該儲存誰的uid和pid？假如有2個程序process a和process b，我們站在process b的角度來分析，process a ipc呼叫process b， 而process b 又呼叫同樣處於process b的service的介面(儘管此時實際上不是遠端呼叫，並且開發者是知道的，但是對於binder呼叫機制來說，它本身並不知道當前的呼叫是否為遠端呼叫，前幾篇文章中有分析系統如何確定是否為遠端呼叫，這個過程是在binder driver中實現的)，那麼此時mcallingpid和mcallinguid是不是應該儲存process b的uid和pid？
1. process b在被process a ipc呼叫時, process b需知道process a的uid和pid，來檢查process a的訪問許可權，此時mcallinguid和mcallingpid儲存的是process a的uid和pid。
2. 在ipc遠端呼叫process b的過程中，process b的方法呼叫了同程序中的service的介面，process b既是呼叫方也是被呼叫方，雖然這個過程比較無聊，但是鑑於ipc過程的不透明性，因此process b仍然需要進行許可權檢測。
前面的文章中分析過，binder driver會判斷當前的binder呼叫是否為遠端呼叫，如果是同程序呼叫的話，bd就不會再向應用提供程序的pid和uid。因此在process b中需要顯示的設定當前的pid和uid。
為實現以上case， android提供了一組函式
public static final native long clearcallingidentity();
public static final native void restorecallingidentity(long token);
process b的方法呼叫了同程序中的service的界面前，clearcallingidentity()方法會清除process a的uid和pid，重置為process b的uid和pid。
process b的方法呼叫了同程序中的service的介面後，此時仍然處在process a遠端呼叫process b方法的過程中，此時需要restore process a的uid和pid。
android IPC通訊方式簡述
andoid ipc方式主要有以下幾種 1.bundle 簡單易用 但是只能傳輸bundle支援的物件 常用於四大元件間程序間通訊 2.檔案共享 簡單易用 但不適合在高併發的情況下 並且讀取檔案需要時間 不能即時通訊 常用於併發程度不高 並且實時性要求不高的情況 3.aidl 功能強大 支援一對多併...
android ipc程序間通訊（概述）
介紹一些ipc的基礎概念。為後面介紹程序間通訊例項打鋪墊。介紹一些程序間通訊的方式，各個優缺點。一些常用的ipc方式 程序和執行緒 執行緒 程序可以包含多個執行緒。序列化介面 parcelable 怎麼在乙個應用裡建立多個程序？在四大元件裡指定 配置 建立私有程序 android process p...
通訊中的backhaul
backhaul 可以翻譯成回程,也叫回程線路 在現有的無線通訊中,backhaul指的是基站和基站控制器之間的鏈結 一般使用者先接入基站,基站再與基站控制器通訊,然後進入核心網 在無線技術中，回程 backhaul 指的是從信元站點向交換機傳送語音和資料流量的功能。在衛星通訊中，回程是指衛星向自身...