最近，有网友更新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频繁唤醒、关联启动，甚至呈现“滥用”迹象的背后，除了为满足推送等业务需求外，是否会有其他利益驱动，或者引入安全风险呢？

三、从个人信息保护角度进行的分析

首先，之所以自启动、关联启动等唤醒方式如此普遍，其本质上还是因为“保活”是实现企业核心商业利益的关键点。众所周知，日活率是一款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个人信息举报微信公众号