移动开发中的访问权限与隐私：概述、机制与配置方法

iOS 和 Android 的权限模型

权限模型在 iOS 和 Android 上有一个共同的概念：用户必须同意访问敏感数据（相机、麦克风、地理位置、通讯录）。然而，实现方式大不相同。Android 在使用时（runtime）请求权限，iOS 需要在 Info.plist 中描述目的并在首次访问时请求。在移动应用中正确实现访问权限是安全和信任的基础。

在 Android 6.0（API 23）之前，所有权限都在安装时请求 —— 用户要么全部接受，要么不安装应用。随着 Android 6.0 的推出，Runtime Permissions 出现了：应用在首次需要时请求权限，用户可以拒绝。iOS 从 iOS 8.0 开始使用类似的方法。了解移动开发中访问权限的演变有助于设计直观的用户体验。

在 IT Sectr，我们遵循「最小权限」原则：只请求真正需要的权限，并且只在必要时请求。这增加了用户的信任：根据 Google（2025）的数据，首次启动时请求超过 5 个权限的应用，注册转化率低 30%。移动应用中的这种访问权限模式已被我们的实践所证实。

表 4. iOS 和 Android 权限模型对比。主要区别：iOS 需要在 Info.plist 中明确描述每个权限的使用目的。Android 提供 shouldShowRequestPermissionRationale 来向用户解释为什么需要权限。了解平台之间访问权限的差异有助于选择正确的模型。

权限类型（Normal、Dangerous、Runtime）

Normal Permissions —— 不构成用户隐私威胁的权限。它们在安装时自动授予：INTERNET、ACCESS_NETWORK_STATE、VIBRATE、BLUETOOTH。开发者无需在代码中请求它们。这种访问权限分类对应于隐私风险级别。

Dangerous Permissions —— 需要访问个人数据的权限：CAMERA、RECORD_AUDIO、ACCESS_FINE_LOCATION、READ_CONTACTS、READ_CALENDAR、READ_EXTERNAL_STORAGE。它们需要运行时请求。Permission Group —— 相关权限的组：如果用户允许了 CAMERA，录制视频的权限（RECORD_AUDIO？不，那是单独的组）—— 不，CAMERA 和 RECORD_AUDIO 在不同的组中。

Runtime Permission —— 在 Android 上调用 ActivityCompat.requestPermissions() 或在 iOS 上通过 CLLocationManager.requestWhenInUseAuthorization() 请求。用户可以响应：Grant（允许）、Deny（拒绝）或「不再询问」（在 Android 上两次拒绝后）。在移动应用中配置访问权限需要考虑用户行为。

Runtime Permission

Runtime Permission 在 Android 上要求每次使用前检查当前状态。shouldShowRequestPermissionRationale() 方法在用户已拒绝时返回 true —— 这是显示带有解释的对话框的信号。在 iOS 上，等效方法是状态检查：.notDetermined、.denied、.authorized、.restricted。移动应用隐私需要持续监控权限状态。

// Kotlin —— 请求相机运行时权限
class CameraActivity : AppCompatActivity() {

    companion object {
        private const val CAMERA_PERMISSION_CODE = 100
    }

    private fun requestCameraPermission() {
        when {
            ContextCompat.checkSelfPermission(
                this, Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED -> {
                openCamera()
            }
            shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {
                showRationaleDialog("扫描二维码需要相机访问权限")
            }
            else -> {
                requestPermissions(
                    arrayOf(Manifest.permission.CAMERA),
                    CAMERA_PERMISSION_CODE
                )
            }
        }
    }

    override fun onRequestPermissionsResult(
        requestCode: Int,
        permissions: Array<String>,
        grantResults: IntArray
    ) {
        if (requestCode == CAMERA_PERMISSION_CODE &&
            grantResults.firstOrNull() == PackageManager.PERMISSION_GRANTED
        ) {
            openCamera()
        }
    }
}

这段代码展示了正确的模式：检查状态 → 显示解释（如果需要）→ 请求权限 → 处理结果。shouldShowRequestPermissionRationale 是一个重要的方法：如果用户已拒绝，显示一个对话框解释为什么需要该权限。否则，用户可能会永久拒绝访问。

隐私（ATT、Privacy Manifest、IDFA）

ATT（App Tracking Transparency）—— 一个 Apple 框架（iOS 14.5+），要求用户明确同意追踪。未经同意，IDFA（广告商标识符）返回零。根据 Flurry（2025）的数据，ATT 接受率因地区和应用程序类型而异，为 15–25%。在移动应用中管理访问权限始于选择合适的框架。

Privacy Manifest —— 一个强制文件（2024 年起适用于新应用，2025 年起适用于更新），开发者在此声明应用收集的数据类型及其目的。Apple 在审核期间检查 Privacy Manifest 与应用实际行为的一致性。移动应用中的隐私必须记录在案。

App Tracking Transparency（ATT）

ATT 要求添加 Info.plist 键 NSUserTrackingUsageDescription，说明需要追踪的原因，并调用 ATTrackingManager.requestTrackingAuthorization()。重要提示：是否应在显示 GDPR 同意之前请求 ATT？不，ATT 是 Apple 的单独请求。在欧盟，先显示 GDPR 横幅，再显示 ATT。在 iOS 上的移动应用中访问权限需要强制配置 ATT。

IDFA 用于广告归因和个性化。在 Android 上，其等效是 GAID（Google Advertising ID）或 AAID（Amazon Advertising ID）。从 Android 13+ 开始，有一个用于访问 GAID 的运行时权限（com.google.android.gms.permission.AD_ID）。移动应用隐私需要控制广告标识符。

GDPR 与用户同意

GDPR（通用数据保护条例）—— 自 2018 年 5 月起生效的欧盟条例。要求：明确同意收集个人数据、管理访问权限的权利、删除数据的权利（被遗忘权）、数据泄露通知以及大公司指定 DPO（数据保护官）。该条例还定义了移动应用中透明的访问权限模型。

对于移动应用，GDPR 意味着：在首次启动时显示同意横幅（清楚说明收集哪些数据以及用于何种目的）、拒绝非必要权限的能力以及设置中的「删除帐户」按钮。流行的 GDPR 工具：OneTrust、Google 的同意管理平台（CMP）、Usercentrics。确保移动应用中的隐私需要 CMP 集成。

在 IT Sectr，我们在引导阶段实施 GDPR 同意：用户看到清晰的描述，选择允许收集哪些数据，并可以在设置中更改其选择。这不仅是法律要求，也是信任因素：透明的应用留存率提高 20%（IT Sectr 数据，2024 年）。移动应用隐私和访问权限管理是用户留存的关键因素。

GDPR 与用户同意

同意 必须是：自愿的（不意味着不）、具体的（不能收集「所有内容」的同意）、知情的（用户知道他们同意什么）和明确的（需要主动操作 —— 复选框、按钮）。预先选中的复选框被 GDPR 禁止。违规罚款 —— 高达全球营业额的 4% 或 2000 万欧元。在移动应用中正确配置访问权限有助于避免罚款。

实用建议

基于 IT Sectr 的经验 —— 关于处理权限和隐私的几条实用建议。在上下文中请求权限：在系统对话框之前显示一个屏幕，解释为什么需要该权限。例如，在请求相机之前显示：「我们需要相机访问权限来扫描二维码」—— 这可以将同意可能性提高 40%。移动应用中的访问权限应在使用上下文中请求。

不要在首次启动时请求所有权限。上下文权限请求（在使用时请求）比在引导期间请求的转化率高 60%。优雅地处理拒绝：如果用户拒绝，不要阻止功能，而是提供替代方案（例如，手动输入地址代替地理位置）。移动应用隐私受益于这种方法。

对于 iOS，务必添加 Privacy Manifest（自 2025 年起对所有应用强制要求）。对于 Android，在 Google Play Console 中指定数据安全部分。本地存储所有权限的状态并与系统设置同步。定期检查合规性 —— 法律法规变化迅速。移动应用的访问权限模型和隐私需要持续审计。