安卓App通過“自啟動/關聯啟動”喚醒會造成用戶個人信息泄露嗎？

　　最近，有網友更新MIUI 12系統后，在其提供的功能中發現，單獨啟用一款App后，短時間內該App喚醒了十余款其他App應用，這種“關聯啟動”或“鏈式啟動”的現象在安卓用戶群體中引發熱烈討論,很多網友表示“不解”“后怕”。事實上，App自啟動、關聯啟動等后臺喚醒問題，在國內的安卓生態下已經存在了很多年了，很多手機廠商在操作系統層面也都會對類似的行為進行監控和記錄，筆者在EMUI 9.1系統下也可以查看到App自啟動和被關聯喚醒的啟動記錄。如下圖1所示。

 

　　網友之所以感到“后怕”，主要對幾個問題產生了疑問：為什么自己沒有操作的情況下App就能自啟動?運行一個App時，為什么要關聯喚醒其他App，是有合作?在App自啟動或關聯喚醒時，是否可能過度收集個人信息?本文將圍繞這幾個問題，逐一分析，答疑解惑，給出建議。

　　一、安卓系統的App運行機制分析

　　為回答上面的問題，我們先簡單了解一下安卓的組件和進程的分類和特性，能幫助我們弄清楚App為什么能夠被喚醒并在后臺“悄悄運行”，喚醒后到底能做點什么。

　　1、安卓App實現喚醒的基礎——安卓的四大組件

　　除了用戶主動打開App這種大家周知的方式，在安卓系統下，提供了活動(Activity)、服務(Service)、廣播(Broadcast)、內容提供(ContentProvider)四大組件，Activity和Service兩個組件經常被用來實現跨應用的喚醒，Broadcast可用于通過監聽廣播事件實現自啟動，ContentProvider組件較少應用在喚醒的場景。

　　? 活動組件(Activity)

　　活動組件(Activity)用于顯示用戶界面，用戶可以通過Activity交互完成啟動其他應用的操作。使用Activity啟動其他應用時，絕大部分情況用戶可以明確感知。如應用A可通過某個Activity調用本身的四大組件提供的方法，實現應用B中相應組件的啟動。如下圖2所示。

 

　　? 服務組件(Service)

　　通過服務(Service)也可以實現應用間的喚醒功能，一般情況喚醒其他應用的服務用戶是無感知的。如應用A可通過某個Service調用本身的四大組件提供的方法，實現應用B中相應組件的啟動。如下圖3所示。

 

　　? 事件廣播(Broadcast)

　　事件廣播(Broadcast)是用于安卓應用與系統、應用與應用之間進行通信的方式。App應用通過系統提供的廣播接收器服務(BroadcastReceiver)接收想要監聽的廣播，比如：當網絡狀態改變時，系統會產生一條廣播，應用就能夠接收到這條廣播并被后臺喚醒。大量的應用都是通過安卓的廣播監聽機制在后臺啟動運行。下圖4為應用A發出廣播事件，并被應用B接收后而觸發啟動的過程。

 

　　? 內容提供組件(Content Provider)

　　內容提供組件(Content Provider)本質上是一個標準化的數據管道，以標準化的方式在Android 應用間共享數據。用戶可以靈活實現ContentProvider 所封裝的數據存儲以及增刪改查等，應用間較少采用該組件主動調用其他應用實現喚醒。

　　2、App運行時的前臺進程、后臺進程和服務進程的區別

　　安卓App都是在獨立虛擬機中運行的，也就是每開一個應用就會打開一個獨立的虛擬機，每個App都有自己的進程，每個進程都有自己的內存空間，這樣可以保證各個App之間的都能獨立穩定的運行。一個應用在安卓系統中運行著多個進程，這里我們主要關心這幾種類型的進程：前臺進程、后臺進程和服務進程。

　　? 前臺進程：指正在與用戶交互的進程，通俗來講就是你當前使用App的進程。這個進程就是用戶主動開啟應用時運行的我們能看見的交互界面。這就是我們一般說的應用前臺運行。

　　? 后臺進程：與App前臺運行狀態不同，在用戶啟動了某App后，點擊home鍵返回到桌面，或切換到其他App，而此時App并未徹底關閉，而是出于后臺掛起的狀態，但是，后臺掛起并不意味著暫停服務，部分導航、語音識別等功能在后臺運行時，依賴運行的后臺相關進程也在不間斷提供服務。

　　? 服務進程：就是我們常說的Services，通常也是運行在后臺，但是與后臺運行狀態不同的是，App既沒有前臺運行，也沒有后臺掛起。比如應用接收服務端的推送消息就是通過啟動Services進程來實現的，App自啟動、關聯喚醒啟動，指的就是服務進程在運行的狀態，服務進程運行時不會影響用戶的其他操作，服務進程運行時用戶在前臺界面是無感的。在我們未操作手機的時候，手機內很多App的服務進程依然在不停的忙碌著。

　　事實上，不管是前臺進程、后臺進程、服務進程，進程究竟能夠做什么，是否可能收集個人信息，均由App開發者自行根據業務功能需要定義。因此，那些用戶最不容易發現的“服務進程”到底在做什么，理當受到關注。

　　二、安卓App之間的關聯啟動目的何在?

　　安卓App的關聯啟動就如文章開始圖中所示，打開一個App的時候會啟動、喚醒其他App。當手機中的App越多，關聯關系復雜，甚至打開幾個App，最后導致手機中幾十個、上百個App都被關聯喚醒了(如下圖5)。

 

　　在探討關聯喚醒目的何在這個問題時，我們要先了解下“消息推送”和“進程?；睢边@兩個概念。無論是iOS系統還是安卓系統，App從服務器向App客戶端推送消息是常見的行為。iOS的消息推送由蘋果的系統和服務器統一管理，這套信息推送機制名為蘋果推送通知服務APNs(Apple Push Notification service)。用戶的iPhone手機與蘋果提供的APNs服務器保持長連接，應用需要推送消息時，先將這條信息的提醒推送到蘋果的服務器端，再由蘋果的服務器轉發到目標用戶手機。于是，用戶的手機上就會彈出信息通知。APNs的好處是只要本地開啟了推送權限，應用在未喚醒的條件下無需后臺運行就能實現消息推送。因此，iOS應用不需要常駐后臺，也不用隨時保持網絡長連接。

　　但是，目前國內安卓生態下沒有類似iPhone的統一消息推送機制，信息推送主要通過三種方式方式實現：第一種是App自身單獨建立推送服務，如微信、支付寶等用戶長時間使用的超級應用，會自己搭建推送服務器，通過后臺駐留服務實現實時的信息推送。第二種就是手機廠商搭建的消息推送服務，如華為推送HMS、小米推送 MiPush等。應用開發者需要為適配不同的手機終端加入不同手機廠商的推送SDK。第三種是第三方信息推送服務，對于大多數未自建推送服務器進行消息推送的應用開發者，會選擇集成這類第三方信息推送SDK，實現信息推送功能。為了保證應用進程被系統清理之后依然能收到推送，有的第三方推送SDK采用了聯合喚醒的機制，只要使用了同一家的SDK，啟動其中一個App 的時候就會喚醒其它所有集成了該家SDK的App推送進程，以保證所有App消息推送的送達率。

　　鑒于以上原因，App為了滿足及時向客戶端手機推送信息的需求，就要盡可能與消息推送服務器保持長連接。如果App沒有服務進程，一旦用戶選擇不主動打開App，就無法與用戶進行任何通信，久而久之用戶就會棄之不用甚至卸載，因而App會想方設法的讓自己在系統中“?；睢?。如果App開發者選擇了采用第三方推送SDK提供的聯合喚醒的機制或者其他類似喚醒機制來“?；睢?，這就可能導致了大量的服務進程在后臺被喚醒、駐留，從而造成了應用的交叉喚醒、關聯啟動的現象。

 

　　不管是自啟動、關聯啟動事實上是“開源型”的安卓操作系統給開發者留下的可以自行定義使用的空間。除了“消息推送”和“進程?；睢?，為了適應一些語音識別等智能化場景、與其他App業務功能的交互等，這些機制均能被開發者靈活使用。但是，在App頻繁喚醒、關聯啟動，甚至呈現“濫用”跡象的背后，除了為滿足推送等業務需求外，是否會有其他利益驅動，或者引入安全風險呢?

　　三、從個人信息保護角度進行的分析

　　首先，之所以自啟動、關聯啟動等喚醒方式如此普遍，其本質上還是因為“?；睢笔菍崿F企業核心商業利益的關鍵點。眾所周知，日活率是一款App的核心績效指標，日活量不僅反應了應用的受歡迎程度，同時反應了產品的變現能力，進而直接影響盈利能力和企業估值。為了搶占市場，誰都不會放過任何一個可以提高應用日活的方法。

　　其次，在用戶安裝、首次打開App、使用App等過程中，會根據需要授予電話/設備信息、存儲、位置等權限，這些權限一旦授予，App則隨時可以通過權限收集相關的信息。即使App通過自啟動、關聯啟動方式被喚醒，被喚醒的App服務進程也可以調用用戶已開啟的權限。相當于App、SDK等只要有服務進程存活，也就具備了隨時可收集如IMEI等設備唯一識別符、位置信息、公共存儲區的數據等的能力，而這些信息被廣泛用于用戶畫像、行為標簽等方面。

　　顯然，這種機制下，超出用戶預期的收集使用個人信息的情形是有可能發生的。我們不禁要問，既然用戶沒有主動開啟App，如果此時App等通過喚醒的服務進程收集個人信息，是否為服務用戶所必需?是否在隱私政策等規則中有著合理的解釋?

　　《App違法違規收集使用個人信息行為認定方法》第四條第3點指出，收集個人信息的頻度等超出業務功能實際需要，可認定為“違反必要原則，收集與其提供的服務無關的個人信息”;

　　GB/T 35273-2020《信息安全技術 個人信息安全規范》標準中指出，收集個人信息需滿足最小必要原則，自動收集個人信息的頻率應是實現產品或服務的業務功能所必需的最低頻率。

　　基于上述技術規范內容分析，App通過自啟動、關聯啟動等方式喚醒后，如果存在通過權限等機制收集個人信息的行為，且并未在隱私政策等規則中明確指出具體的目的的，其收集個人信息的頻度則涉嫌超出了業務功能實際需要。

　　四、思考與建議

　　自啟動、關聯啟動的泛濫，除了對個人信息保護帶來隱患外，還會導致占用過多的系統CPU和內存資源，造成系統卡頓、電池耗費過快;還可能引入一些包含“惡意代碼”的進程被隱蔽啟動，避開了殺毒軟件等的查殺，有可能威脅到用戶通信秘密、財產安全。目前，多家國產手機廠商已經意識到這種機制帶來的隱患，在其安卓操作系統中增加了對應用行為進行監控和記錄的功能，讓用戶可以查看、或者控制App的自啟動、關聯啟動機制。

　　App通過自啟動、關聯啟動喚醒的方式，是涉及安卓操作系統的一個復雜生態問題。該問題已經得到有關部門關注，2017年，由工信部指導成立的包含了主流手機廠商和用戶基數大的App開發商組成的“安卓統一推送聯盟”，旨在推動各應用運營者能夠通過的統一推送服務的完成消息推送，各應用無需自己考慮消息推送的問題，把這個問題交由安卓系統層面去解決，從而避免自啟動、關聯啟動方式的濫用。

　　除了逐步推動“推送”等方面技術和標準上的統一化，立足于現實情況，還可從技術規范等層面細化App、SDK收集使用個人信息的要求，不斷加強對過度收集個人信息行為的檢測評估、曝光處罰，推動自啟動、關聯啟動行為規范化。無論現有移動生態現狀如何、技術條件是否成熟，App、SDK等均可以從個人信息保護角度，公開、透明收集使用個人信息規則，并嚴格做到言行一致。如能如此，才能避免自啟動、關聯啟動給用戶帶來的“擔憂”。

　　五、結語

　　“開放”的安卓操作系統，給應用開發者帶來豐富的資源、靈活的機制的同時，日積月累塑造了龐大生態。即使如此，并不代表著在安卓操作系統生態下，收集使用個人信息方面有了更多的操作空間，有了更多“隱蔽”的方式，合法合規收集個人信息始終是基本遵循。相信，個人信息保護作為用戶的基本需求，作為重點監管要求，將成為不斷推動安卓操作系統生態優化完善、健康發展的源源動力。

　　(作者：公安部安全與警用電子產品質量檢測中心 韓煜)

　　聲明：本文來自App個人信息舉報，版權歸作者所有。文章內容僅代表作者獨立觀點，不代表萬方安全立場，轉載目的在于傳遞更多信息。如有侵權，請聯系刪除。