📚 课程目录第1章课程导入

1. 课程导入

在Android应用开发中，权限与系统服务是连接“应用功能”与“系统能力”的两条主干通道。应用想要读取联系人、访问相机、获取位置、连接蓝牙、扫描Wi‑Fi、绑定无障碍服务、调用通知与前台服务，背后都离不开权限声明、运行时授权、AppOps校验、系统服务Binder调用与进程间通信。很多开发者能写出界面与业务逻辑，却在遇到SecurityException、Permission Denial、后台启动限制、前台服务类型缺失、系统服务返回空值或超时等问题时无从下手。本课程的目标，就是把这条链路从“会调用API”提升到“理解系统如何授权、如何跨进程提供能力、如何排障与合规设计”。

一、学习目标：从API调用者到系统集成者

本课程围绕四个层次展开。第一层是权限模型：理解普通权限、危险权限、签名权限、特殊权限、运行时权限与一次性授权、自动重置、后台位置、精确/大致位置等差异。第二层是系统服务调用：掌握通过Context.getSystemService()获取服务、Binder代理、AIDL接口、系统服务注册与查询的基本机制。第三层是集成与适配：覆盖Android 6.0到Android 14+的分区存储、后台限制、前台服务类型、通知权限、包可见性、动态广播接收器导出等变化。第四层是工程化与排障：能通过日志、dumpsys、AppOps、权限回调与异常堆栈定位问题，并给出可落地的兼容方案。

学习完成后，你应能独立完成：声明并动态申请权限；判断权限是否被永久拒绝；为前台服务声明正确类型；通过系统服务完成跨进程能力调用；识别权限与系统服务集成中的常见安全与合规风险。

二、核心概念：权限、系统服务与Binder三角关系

Android的安全模型可以概括为“沙箱 + 权限 + 系统服务”。每个应用运行在独立UID沙箱中，默认只能访问自己的文件和有限系统资源。当应用需要访问受保护资源时，必须声明权限；系统在安装时或运行时进行授权；最终由系统服务在Binder调用入口处执行校验。也就是说，权限不是应用自己“拥有”的能力，而是系统服务在收到请求时，根据调用方UID、PID、包名、AppOps状态和权限授予结果做出的判断。

系统服务是系统能力的提供者，例如ActivityManagerService、PackageManagerService、LocationManagerService、CameraService、NotificationManagerService、ConnectivityService等。应用侧拿到的通常是Binder代理对象，通过transact()或AIDL接口把请求发送到system_server或独立native服务。权限校验往往发生在服务端，而不是客户端。因此，客户端“以为有权限”并不等于服务端会放行。

三、方法流程：一次权限化系统服务调用的完整路径

以“获取当前位置”为例，典型路径如下：应用在AndroidManifest.xml中声明ACCESS_FINE_LOCATION；运行时调用requestPermissions()；用户授权后，应用通过LocationManager请求位置；LocationManagerService在服务端检查调用方UID是否拥有该权限、AppOps是否允许、前台/后台状态是否满足；校验通过后返回位置，否则抛出SecurityException或返回空结果。这个路径说明：权限申请只是第一步，系统服务端校验才是最终关口。

// 典型权限申请与系统服务调用骨架
if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION)
        != PackageManager.PERMISSION_GRANTED) {
    requestPermissions(new String[]{
        Manifest.permission.ACCESS_FINE_LOCATION
    }, REQ_LOCATION);
} else {
    LocationManager lm = (LocationManager)
        getSystemService(Context.LOCATION_SERVICE);
    // 继续调用系统服务
}

四、案例与场景：权限与系统服务集成的典型战场

场景一：后台定位。Android 10起，后台访问位置需要ACCESS_BACKGROUND_LOCATION，且申请方式与前台位置不同，用户可能只授予“仅在使用时允许”。场景二：前台服务。Android 14要求前台服务声明具体类型，如camera、location、microphone，并满足对应权限与启动条件，否则抛出MissingForegroundServiceTypeException。场景三：包可见性。Android 11起，查询其他应用需要<queries>或QUERY_ALL_PACKAGES，否则PackageManager返回过滤后的结果。场景四：通知权限。Android 13起POST_NOTIFICATIONS成为运行时权限，未授权时通知不会展示。

集成对象	关键权限/配置	高频问题	排查入口
定位服务	ACCESS_FINE_LOCATION / ACCESS_BACKGROUND_LOCATION	后台定位被拒、仅前台授权	AppOps、权限回调、dumpsys location
相机服务	CAMERA、前台服务类型 camera	SecurityException、服务类型缺失	Logcat、dumpsys activity services
通知服务	POST_NOTIFICATIONS、通知渠道	通知不展示、渠道被关闭	NotificationManager、系统设置
包管理服务	<queries>、QUERY_ALL_PACKAGES	查询不到目标应用	PackageManager、包可见性日志

五、误区与复盘：不要只盯着“申请权限”

常见误区一：只在Manifest声明权限，忽略运行时申请。误区二：认为用户授权后系统服务一定放行，忽略AppOps、后台限制与前台服务类型。误区三：把系统服务当普通本地对象，忽略Binder跨进程异常、DeadObjectException与超时。误区四：为了省事申请QUERY_ALL_PACKAGES或后台位置，导致上架合规风险。

复盘时应建立“声明—申请—校验—调用—回调—异常”的完整链路视角。遇到问题时，先确认权限是否声明、是否动态申请、用户是否授予、AppOps是否允许、服务端是否因前台状态拒绝，再检查系统服务调用参数与版本差异。只有把权限模型与系统服务调用放在同一条链路上理解，才能真正完成Android系统能力集成。

六、实战路线图

第1阶段：掌握权限分类、Manifest声明、运行时申请与回调处理。
第2阶段：理解Binder、系统服务获取方式、AIDL与Manager封装。
第3阶段：逐项攻克定位、相机、通知、蓝牙、存储、包管理等高频服务。
第4阶段：完成Android 6.0到14+的行为变更适配与前台服务类型配置。
第5阶段：使用dumpsys、AppOps、Logcat与异常堆栈进行系统级排障。
第6阶段：以最小权限、用户告知、合规上架为目标完成工程化收尾。