【導(dǎo)讀】nearfuture.ing,receiving,andsoforth)intoitaswell.ause.

　　

【正文】 但是，運(yùn)行器選擇的特殊的 activity 實(shí)在 manifest 中標(biāo)記為元信息的。 FriendTracker 應(yīng)用包含了這四種組件。 FriendTracker 的 service 輪詢一個(gè)外部的 service 來發(fā)現(xiàn)朋友的位置。在我們的示例代碼中，我們隨機(jī)的產(chǎn)生位置，但是將組件延伸到網(wǎng)頁服務(wù)的接口上是簡單明了的。 FriendProvider 的content provider 保存了朋友的最新地理位置坐標(biāo)， FriendTracker Control activity為開始和停止追蹤功能定義了一個(gè)用戶接口，而 BootReceiver broadcast receiver包含了一個(gè)在系統(tǒng)啟動(dòng)的時(shí)候發(fā)送的通知（應(yīng)用通過它來自動(dòng)啟動(dòng)程序）。 FriendViewer 應(yīng)用首要功能是展示關(guān)于朋友位置的信息。 FriendViewer 的activity 列出了所有的朋友和他們的地理位置坐標(biāo)， FriendMap activity 將他們展示在地圖上。 FriendReceiver broadcast receiver 等待指示了手機(jī)本身臨近某個(gè)特定的朋友的信息，并在這種情況下將信息展示 給用戶。盡管我們需要將這些組件放置在 FriendTracker 應(yīng)用中，我們創(chuàng)建了一個(gè)分開的應(yīng)用來證明跨應(yīng)用的通信。此外，通過將追蹤和用戶接口邏輯分離，我們可以創(chuàng)建有著不同展示和特點(diǎn)的交替式接口 —— 也就是說，許多應(yīng)用可以重新使用 FriendTracker 中用到的邏輯。 組件的交互 對于組件交互的基礎(chǔ)體制是 intent，即包含了目的組件的地址和數(shù)據(jù)的消息對象。 Android 的 API 定義了接收 intent 并使用其信息來開始一個(gè) activity 的方法 開始一個(gè) service 的方法 (startService(Intent)) ，和開始一 個(gè)廣播消息broadcast messages 的方法 (sendBroadcast(Intent))。這些函數(shù)的調(diào)用告訴 android架構(gòu)開始執(zhí)行目標(biāo)應(yīng)用中的代碼。這個(gè)內(nèi)部組件的通信被稱作 action。簡單來說，一個(gè) intent 對象定義了“ intent”來執(zhí)行“ action”。 Android 的一個(gè)最為強(qiáng)大的特點(diǎn)就是由 intentaddressing 機(jī)制帶來的靈活性。盡管開發(fā)者可以通過使用應(yīng)用的命名空間來為特定的目標(biāo)組件尋址，但是他們也可以使用一個(gè)暗示的名稱。在后面的案例中，系統(tǒng)通過考慮一系列的已安裝應(yīng)用和用戶選擇來為一個(gè) action 決定最好的組件。隱式的名字會調(diào)用一個(gè) action 串，因?yàn)樗?guī)定了所需 action 的類型 —— 舉例來說，如果一個(gè)帶有指向了圖片文件數(shù)據(jù)的 intent 規(guī)定了“ VIEW” action 串的時(shí)候，系統(tǒng)會直接優(yōu)先跳轉(zhuǎn)到圖片 viewer。開發(fā)者也使 用 action 串來向一組 broadcast receivers 廣播消息。在接收端，開發(fā)者使用一個(gè) intent filter 來允許一個(gè)特定的 action 串。 Android 有額外的目的地判斷規(guī)則，但是帶有可選擇的數(shù)據(jù)類型的 action 串是最為常見的。 應(yīng)用 FriendTracker 和 FriendViewer 的組件之間的交互作用，和帶有組件的應(yīng)用被定義為基礎(chǔ) android 分配的一部分。在每個(gè)案例中，一個(gè)組件啟動(dòng)與另一個(gè)的通信。簡單來說，我們調(diào)用這個(gè)內(nèi)部組件通信（ ICC）。在許多時(shí)候，在 Unix基礎(chǔ)系統(tǒng)中， ICC 是類似于內(nèi)部進(jìn)程通信（ IPC）的。對開發(fā)者而言， ICC 的功能除了安全規(guī)則以外，同樣的是不考慮目標(biāo)是否在同一個(gè)應(yīng)用或者是不同的應(yīng)用中。 可用的 ICCaction 取決于目標(biāo)組件。每個(gè)類型的組件只特定支持他的類型的交互 —— 舉個(gè)例子，當(dāng) FriendViewer 啟動(dòng)了 FriendMap 時(shí)， activity FriendMap 會出 現(xiàn) 在 屏 幕 上 。 Service 組 件 支 持 開 始 ， 停 止 和 綁 定 action ，所以FriendTrackerControl activity，舉例來說，可以開始或停止在后臺運(yùn)行的FriendTracker service。綁定 action為組件之間建立聯(lián)系，允許創(chuàng)始人執(zhí)行由 service定義的 RPCs。在我們的例子中， FriendTracker 與系統(tǒng) service 的位置管理器相綁定。一旦綁定， FriendTracker 調(diào)用函數(shù)來登記一個(gè)提供手機(jī)位置更新的回調(diào)。需要注意的是，如果一個(gè) service 現(xiàn)在是綁定的，那么一個(gè)明確的“停止”指令也不會結(jié)束 service，直到綁定的連接被釋放為止。 Broadcast receiver 和 content provider 組件有獨(dú)特的交互形式。 ICC 把 intent發(fā)送形式 的 broadcast receiver 作為目標(biāo)， intent 可以發(fā)送到一個(gè)組件，或者更為常見的，發(fā)送到一個(gè)組件同意的 action 串。舉個(gè)例子， FriendReceiver 連接到開發(fā)者定義的“ FRIEND_NEAR” action 串。 FriendTracker 在發(fā)現(xiàn)手機(jī)正臨近一個(gè)朋友的時(shí)候，廣播一個(gè) intent 到這個(gè) action 串；接下來，系統(tǒng)啟動(dòng) FriendReceiver并為用戶顯示一條信息。 Content providers 不使用 intent，取而代之的是，他們通過嵌入在特殊授權(quán)串來尋址。這里的 table指示了 content provider 中的標(biāo)簽， id隨意的確定了在這個(gè)標(biāo)簽中的一個(gè)記錄。組件使用這個(gè) URI 在 content provider 中執(zhí)行一個(gè) SQL 數(shù)據(jù)庫的訪問，通過查詢 API 獲得位置條件。 安全機(jī)制強(qiáng)制執(zhí)行 如圖表 3 所示， android 通過兩個(gè)強(qiáng)制機(jī)制的共同工作來保護(hù)應(yīng)用和數(shù)據(jù)，一個(gè)是在系統(tǒng)層面上，另一個(gè)在 ICC 層面上。 ICC 的仲裁定義了核心安全架構(gòu)，這也是這篇文章的核心，但是他依賴于下層的 Linux 系統(tǒng)提供的保障。 一般情況下，每個(gè)應(yīng)用都作為一個(gè)獨(dú)特的用戶標(biāo)識來運(yùn)行，這使得 android限制了程序缺陷帶來的潛在傷害。舉個(gè)例子，在 TMobile G1 手機(jī)被釋放后所發(fā)現(xiàn) 的 網(wǎng) 頁 瀏 覽 器 的 脆 弱 性 只 影 響 網(wǎng) 頁 瀏 覽 器 自 己(的選擇，開發(fā)不會影響其他應(yīng)用或者是系統(tǒng)。一個(gè)蘋果手機(jī)中的類似脆弱性敗給了“越獄”技術(shù)，他可以運(yùn)行用戶更換一些下層系統(tǒng)的內(nèi)容，也會是基于網(wǎng)絡(luò)的開 發(fā) 對 手 利 用 這 個(gè) 瑕 疵( valuators . /content/casestudies/iphone/)。 ICC 是不被用戶和進(jìn)程邊界限制的。事實(shí)上，所有的 ICC 通過一個(gè)特殊的設(shè)備節(jié)點(diǎn)的 I / O 控制命令， / dev /binder 發(fā)生。因?yàn)槲募仨毷菍φ_的操作可讀且可寫的， Linux 系統(tǒng)沒有調(diào)解 ICC 的方法。雖然用戶分離是非常簡單且容易理解的，控制 ICC 是非常微妙，且需要認(rèn)真考慮的。 作為安全性強(qiáng)制執(zhí)行規(guī)則的中心點(diǎn)，在 Android 中間層，通過推理分配給應(yīng)用程序和組件的標(biāo)簽來調(diào)解所有 ICC 的建立。一個(gè)的參考監(jiān)視器 1 提供了 關(guān)于應(yīng)用程序如何訪問組件的強(qiáng)制訪問控制 MAC 辦法。最簡單的形式是，通過分配訪問權(quán)限的標(biāo)簽來限制對每個(gè)組件的訪問；這個(gè)文本字符串不必是唯一的。開發(fā)者分配許可標(biāo)簽的應(yīng)用集合。當(dāng)一個(gè)組件啟動(dòng) ICC 時(shí)，參考監(jiān)視器檢查分配給他包含的應(yīng)用的的許可標(biāo)簽 —— 并且如果目標(biāo)組件的訪問權(quán)限在這個(gè)集合中 —— 并且允許 ICC 的創(chuàng)建執(zhí)行。如果標(biāo)簽不是在集合里，即使在同一應(yīng)用程序的組件，建立也會被拒絕。圖 4 描述了這種邏輯。 開發(fā)人員通過伴隨著每一個(gè)應(yīng)用程序包的 XML manifest 文件來分配權(quán)限標(biāo)簽。這樣做，使開發(fā)人員定義應(yīng)用程序的安 全政策，也就是說，分配一個(gè)標(biāo)簽給指定了保護(hù)域的程序，反之，分配權(quán)限給指定一個(gè)準(zhǔn)入政策來保護(hù)它的資源的應(yīng)用程序中的組件。由于 Android 政策執(zhí)行是強(qiáng)制性的，與自由決定完全相反，所有的許可標(biāo)簽都是在安裝時(shí)設(shè)定的并且不能改變，直到重新安裝應(yīng)用程序。然而，不考慮它的 MAC 性能， Android 的許可標(biāo)簽?zāi)Ｊ街幌拗圃L問組件而暫時(shí)不提供信息流的保證，如域類型的強(qiáng)制執(zhí)行。 安全性精煉 Android 的安全架構(gòu)是基于以標(biāo)簽為導(dǎo)向的 ICC 調(diào)解描述，但我們的描述是不完整的。 排出部分的必要性，并部分為方便起見，谷歌設(shè)計(jì) Android 的開發(fā)人員將其納入幾個(gè)精煉基本的安全模型，其中有一些微妙的副作用，使得其整體安全性很難理解。 公共與私有組件 應(yīng)用程序通常包含不能被其他應(yīng)用訪問的組件，例如，一個(gè)設(shè)計(jì)用來返回用戶輸入的密碼的 activity 可能被啟動(dòng)惡意。不用定義訪問權(quán)限，開發(fā)者可以在manifest 文件設(shè)置出口屬性為 false 來，或讓 Android 的通知，如果該組件應(yīng)該從其 manifest 定義的其他屬性中指定為私人的，來使一個(gè)組件私有。 私有組件簡化了安全規(guī)范。通過把一個(gè)組件私有化，開發(fā)人員不需要擔(dān)心分配哪個(gè)許可標(biāo)簽給他或 者另一個(gè)應(yīng)用程序該如何獲得該標(biāo)簽。任何應(yīng)用程序可以訪問未明確分配訪問權(quán)限的組件，所以私人組件和推理規(guī)則的添加（ SDK的發(fā)布， 2021 年 8 月推出）顯著減少了許多應(yīng)用程序的攻擊面。然而，開發(fā)者在允許 Android 來確定一個(gè)組件為私人的時(shí)候，一定要慎重。有安全意識的開發(fā)者應(yīng)該明確定義打算設(shè)置為私有的組件的出口屬性。 隱式開放組件 開發(fā)人員經(jīng)常在 activity 上定義 intent filters，以表明它們可以處理某些類型的動(dòng)作 /數(shù)據(jù)組合?；叵胍幌庐?dāng)一個(gè) intent 確定了 VIEW action 且 一個(gè)圖像引用被傳遞到“啟動(dòng)活動(dòng)”的 API 時(shí)，系統(tǒng)是如何找到一個(gè)圖像瀏覽器的例子。在這種情況下，調(diào)用者不能事先知道需要什么樣的訪問權(quán)限（在開發(fā)時(shí)少得多）。開發(fā)目標(biāo) activity 的開發(fā)者，可以通過不分配訪問權(quán)限允許這樣的功能，也就是說，如果一個(gè)公共的組件不明確的在其清單定義中列出的訪問權(quán)限， Android 就允許任何應(yīng)用程序訪問它。 雖然這個(gè)預(yù)設(shè)的政策規(guī)范實(shí)現(xiàn)了功能且易于開發(fā)，它也可能導(dǎo)致安全性差的做法而且他與 Saltzer 和 Schroeder 的默認(rèn)故障安全原則相悖?；氐轿覀兊睦覨riendViewer 應(yīng)用 上，如果的 FriendReceiver 廣播接收機(jī)未分配一個(gè)訪問權(quán)限，任何非特權(quán)安裝的應(yīng)用程序可以偽造 FRIEND_NEAR 消息，這意味著一個(gè)重要的安全性問題，關(guān)于英語程序基于通過 intent 傳遞的信息的決策。作為一個(gè)一般的做法，有安全意識的開發(fā)者應(yīng)始終為公共組件分配訪問權(quán)限，事實(shí)上，他們應(yīng)該有一個(gè)對于不分配的明確的理由。在這些條件下，應(yīng)仔細(xì)檢查所有的輸入。