1. 项目概述Android 14/15 安全收紧的必然趋势如果你最近在适配 Android 14 或正在为 Android 15 的预览版做准备大概率已经遇到了两个让人头疼的新限制一个是针对媒体文件访问的Granular Media Permissions细化媒体权限另一个是针对前台服务的Foreground Service Types前台服务类型强制声明。这可不是简单的 API 版本号升级而是 Google 在用户隐私保护和系统资源管理上又一次“重拳出击”。我经历过从READ_EXTERNAL_STORAGE一权通吃到需要分门别类申请权限的时代也见证过前台服务从“保活神器”到被严格约束的历程。这次 Android 14/15 的新规可以看作是这两个趋势的深化和精细化。简单来说Google 的目标很明确最小权限原则和透明化原则。应用不能因为要播放音乐就要求获得访问用户所有照片和视频的权力也不能用一个模糊的“后台任务”理由就长期占用系统前台资源。对于开发者而言这意味着我们过去一些“图省事”的粗放式开发模式必须改变。适配这些新特性不仅仅是添加几行声明那么简单它涉及到应用架构的审视、数据流的重设计以及对用户体验的更深层次考量。接下来我将结合实际的代码和场景拆解这两大安全特性的核心逻辑、适配方案以及那些官方文档里不会写的“坑”。2. 核心安全特性深度解析2.1 Granular Media Permissions告别“全盘扫描”时代在 Android 13 之前我们申请READ_EXTERNAL_STORAGE权限用户一旦授权应用就能访问整个共享存储空间即/storage/emulated/0下的所有媒体文件。这就像拿到了用户家所有房间的万能钥匙显然过度了。Android 14 引入的细化媒体权限将媒体访问权从“一整块”切分成了“三小块”READ_MEDIA_IMAGES仅访问图片和截图。READ_MEDIA_VIDEO仅访问视频。READ_MEDIA_AUDIO仅访问音频文件。1.1.1 权限申请策略的转变最直接的影响是权限申请逻辑。你不能一上来就请求READ_EXTERNAL_STORAGE它在 Android 14 上已被标记为deprecated而应该按需申请。// 错误做法Android 14 if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { // 不要再使用这个了 // requestPermissions(arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE), REQUEST_CODE) } // 正确做法Android 14 if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // 如果你的应用只需要选择图片 requestPermissions(arrayOf(Manifest.permission.READ_MEDIA_IMAGES), REQUEST_CODE_IMAGES) // 或者如果需要图片和视频 val permissionsToRequest mutableListOfString() permissionsToRequest.add(Manifest.permission.READ_MEDIA_IMAGES) permissionsToRequest.add(Manifest.permission.READ_MEDIA_VIDEO) requestPermissions(permissionsToRequest.toTypedArray(), REQUEST_CODE_MEDIA) }注意对于 Android 13API 33它引入的是READ_MEDIA_IMAGES和READ_MEDIA_VIDEO。READ_MEDIA_AUDIO是在 Android 14API 34才加入的。所以你的兼容代码需要分层处理。1.1.2 对“文件选择器”和“媒体库”功能的冲击这对那些集成系统文件选择器Intent.ACTION_GET_CONTENT或Intent.ACTION_OPEN_DOCUMENT的应用影响相对较小因为系统选择器本身会处理权限。但如果你是自己遍历MediaStore来构建应用内的媒体库那就必须重构。例如一个音乐播放器应用现在应该只申请READ_MEDIA_AUDIO权限。当查询MediaStore.Audio.Media.EXTERNAL_CONTENT_URI时系统会自动过滤只返回你有权限访问的音频文件。你无法再通过MediaStore查询到图片或视频的信息即使它们物理上存在于存储中。1.1.3 Partial Media Access 的妙用Android 14 还强化了“部分媒体访问”特性。即使用户拒绝了完整的READ_MEDIA_*权限你仍然可以通过ActivityResultContracts.PickVisualMedia()或ActivityResultContracts.GetContent()契约让用户单次选择特定的图片或视频文件给你。系统会授予你的应用对该文件的临时访问权限。这对于“上传头像”、“发送图片”等一次性操作非常友好是实现“无需授权即可使用”功能的关键。// 使用 Photo Picker (推荐需要 Google Play 服务) val pickMedia registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri - uri?.let { // 处理用户选择的单个媒体文件URI } } pickMedia.launch(PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly)) // 或者使用通用选择器 val getContent registerForActivityResult(ActivityResultContracts.GetContent()) { uri - uri?.let { // 处理文件URI } } getContent.launch(“image/*”)2.2 Foreground Service 类型限制给“前台”一个明确的理由前台服务Foreground Service是应用在后台执行用户可感知任务的重要组件但它一直被滥用导致通知栏泛滥、电量消耗过快。Android 14 要求所有前台服务必须声明其符合的具体类型并在启动时提供该类型。1.2.1 强制声明的服务类型你需要在AndroidManifest.xml中为每个service声明android:foregroundServiceType属性并在代码中启动服务时通过Service.startForeground()的变体方法传入对应的类型。主要的类型包括camera用于相机操作。connectedDevice与配件或设备交互。dataSync数据同步。health健康相关。location获取位置信息。mediaPlayback媒体播放。mediaProjection屏幕投射或录制。microphone使用麦克风。phoneCall通话相关。remoteMessaging接收远程消息如FCM。shortService/specialUse短期或特殊任务。1.2.2 声明与启动的代码示例首先在清单文件中声明service android:name“.MyMusicPlaybackService” android:enabled“true” android:exported“false” android:foregroundServiceType“mediaPlayback” /然后在启动服务的代码中// 对于 Android 14 (API 34) 及以上 if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { val notification createMediaStyleNotification() // 创建对应的通知 startForeground(NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK) } else { // 旧版本方式 startForeground(NOTIFICATION_ID, notification) }1.2.3 类型不匹配的严重后果这里有一个大坑你在startForeground中传入的类型必须是你声明的android:foregroundServiceType的子集或完全匹配。系统会进行校验。例如你的服务声明了foregroundServiceType“mediaPlayback|dataSync”那么启动时你可以传入FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK或FOREGROUND_SERVICE_TYPE_DATA_SYNC或者两者的组合。但如果你声明的是mediaPlayback却试图以dataSync类型启动在 Android 14 设备上会抛出ForegroundServiceStartNotAllowedException异常。实操心得在适配初期最容易出错的地方就是遗漏了类型声明或者声明与启动类型不一致。务必在测试阶段在 Android 14 及以上版本的设备或模拟器上对所有使用前台服务的场景进行全覆盖测试。异常可能不会在开发时立即抛出而是在特定系统状态下触发。3. 适配实战从旧模式到新规范的迁移路径3.1 媒体权限适配的渐进式策略面对从 Android 10 (Scoped Storage) 到 Android 14 (Granular Media) 这一连串的存储权限变革一个健壮的适配策略必须是渐进式和条件化的。2.1.1 权限检查与申请的逻辑重构首先你需要一个统一的权限检查工具方法它能根据不同的 SDK 版本返回所需的权限数组。fun getRequiredStoragePermissions(context: Context, requestImage: Boolean, requestVideo: Boolean, requestAudio: Boolean): ArrayString { val permissions mutableListOfString() if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // Android 14 if (requestImage) permissions.add(Manifest.permission.READ_MEDIA_IMAGES) if (requestVideo) permissions.add(Manifest.permission.READ_MEDIA_VIDEO) if (requestAudio) permissions.add(Manifest.permission.READ_MEDIA_AUDIO) // 注意在 Android 14WRITE_MEDIA_IMAGES/VIDEO/AUDIO 用于写入特定媒体库而非通用写入。 } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { // Android 13 if (requestImage) permissions.add(Manifest.permission.READ_MEDIA_IMAGES) if (requestVideo) permissions.add(Manifest.permission.READ_MEDIA_VIDEO) if (requestAudio) { // Android 13 没有 READ_MEDIA_AUDIO音频访问仍需要旧权限或使用 MediaStore API // 更佳实践是引导用户使用文件选择器选择音频文件或申请 MANAGE_EXTERNAL_STORAGE上架审核严格 } } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.Q) { // Android 10-12在分区存储下应用私有目录和 MediaStore 无需权限。 // 但如果要访问其他应用创建的非媒体文件可能需要申请所有文件访问权限MANAGE_EXTERNAL_STORAGE。 // 通常对于媒体文件我们使用 MediaStore API不需要 READ_EXTERNAL_STORAGE。 } else { // Android 9 及以下 permissions.add(Manifest.permission.READ_EXTERNAL_STORAGE) // 可能还需要 WRITE_EXTERNAL_STORAGE } return permissions.toTypedArray() }2.1.2 使用 MediaStore API 进行安全查询无论权限如何变化访问共享媒体文件的正确方式始终是通过MediaStoreAPI。它提供了基于内容提供者的安全访问模型。fun queryAudioFiles(context: Context): ListAudio { val audioList mutableListOfAudio() val projection arrayOf( MediaStore.Audio.Media._ID, MediaStore.Audio.Media.DISPLAY_NAME, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.DATA // 谨慎使用在 Android Q 可能为空或需要不同方式访问 ) val selection “${MediaStore.Audio.Media.IS_MUSIC} ! 0” val sortOrder “${MediaStore.Audio.Media.DATE_ADDED} DESC” context.contentResolver.query( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, projection, selection, null, sortOrder )?.use { cursor - val idColumn cursor.getColumnIndexOrThrow(MediaStore.Audio.Media._ID) val nameColumn cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DISPLAY_NAME) while (cursor.moveToNext()) { val id cursor.getLong(idColumn) val name cursor.getString(nameColumn) val contentUri ContentUris.withAppendedId( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, id ) // 使用 contentUri 来访问文件而不是直接使用 DATA 路径 audioList.add(Audio(id, name, contentUri)) } } return audioList }关键技巧从 Android Q 开始MediaStore.MediaColumns.DATA字段即文件绝对路径可能已废弃或不可靠。始终优先使用_ID生成的ContentUri(如content://media/external/audio/media/123) 来通过ContentResolver.openInputStream(uri)访问文件内容。这是保证未来兼容性的关键。3.2 前台服务类型化改造的详细步骤对现有前台服务的改造需要从设计、声明到启动进行全链路检查。2.2.1 服务类型的合理选择与组合首先审视你的每一个前台服务明确其核心目的。一个服务可能符合多种类型吗官方允许组合使用通过位或运算符|但必须合理。案例一个音乐播放器服务它显然属于mediaPlayback。如果它还负责在播放时下载下一首歌曲的封面或歌词那么dataSync可能也是合理的。但你需要评估下载任务是否必须在前台进行能否交给WorkManager在后台处理前台服务类型越多对用户的通知干扰可能越大也越容易在审核时被质疑。案例一个健身追踪应用的服务它持续使用 GPS 记录轨迹 (location)同时可能通过蓝牙连接心率带 (connectedDevice)。那么它的类型就应该是location | connectedDevice。2.2.2 清单文件与启动代码的同步更新这是一个必须严格执行的 checklist更新AndroidManifest.xml为每个service标签添加android:foregroundServiceType属性。如果服务有多种前台运行模式可以声明多个类型。!-- 音乐播放服务 -- service android:name“.PlaybackService” android:foregroundServiceType“mediaPlayback” / !-- 文件上传服务 -- service android:name“.UploadService” android:foregroundServiceType“dataSync” / !-- 语音录制服务 -- service android:name“.RecordingService” android:foregroundServiceType“microphone” /更新启动服务的代码找到所有调用startForeground()的地方通常是Service类的onStartCommand或某个启动服务的方法中。class MyForegroundService : Service() { override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { // ... 服务逻辑准备 ... val notification buildNotification() if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // Android 14 必须指定类型 startForeground( NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_DATA_SYNC // 必须与清单声明匹配 ) } else { // 旧版本 startForeground(NOTIFICATION_ID, notification) } return START_STICKY } }处理PendingIntent的兼容性如果你的前台服务通知中包含PendingIntent比如播放/暂停按钮并且目标 Activity 或 BroadcastReceiver 对安全性有要求在 Android 14 你可能需要为其设置FLAG_IMMUTABLE或FLAG_MUTABLE。虽然这不直接关联服务类型但常在同一时期适配需要注意。2.2.3 后台启动限制的应对之策Android 14 还加强了对“后台启动前台服务”的限制。当应用处于后台状态时例如没有可见的 Activity也没有其他前台服务在运行尝试启动一个需要用户感知的前台服务会受到严格限制。应对策略使用高优先级通知对于某些紧急类型如phoneCall系统可能允许。使用startForegroundService()的兼容性在 Android 8.0 引入的startForegroundService()仍然有效但它会创建一个时间窗口你必须在这个窗口内约几秒钟调用startForeground()否则应用会 ANR。在 Android 14这个规则依然有效且类型必须匹配。考虑替代方案对于非即时性的任务如数据备份、日志上传优先考虑使用WorkManager来调度任务。WorkManager能更好地处理系统约束如电量、网络并且不需要前台服务。4. 常见问题排查与避坑指南在实际适配过程中我遇到了不少预料之外的问题。这里把它们整理出来希望能帮你节省时间。4.1 媒体权限相关的疑难杂症3.1.1 权限已授予但查询 MediaStore 返回空列表可能原因你的应用目标版本 (targetSdkVersion) 已经 29 (Android 10)但你没有正确适配分区存储。在 Android 10即使有READ_EXTERNAL_STORAGE权限默认也无法直接通过文件路径访问其他应用创建的媒体文件必须通过MediaStoreAPI。排查步骤检查AndroidManifest.xml中是否设置了requestLegacyExternalStorage”true”这只在targetSdkVersion29时有效且 Android 11 会忽略此标志。这不是长久之计。确认你使用的是MediaStoreAPI 进行查询并且Uri正确例如MediaStore.Images.Media.EXTERNAL_CONTENT_URI。在 Android 14确认你申请并获得了正确的细化权限READ_MEDIA_IMAGES等并且查询的MediaStore类别与权限匹配。使用adb shell dumpsys package your.package.name命令查看应用实际被授予的权限列表。3.1.2 通过文件选择器Photo Picker/GET_CONTENT获取的 Uri 无法长期使用问题描述用户通过Intent选择一张图片你拿到了content://开头的 Uri。当时可以读取但应用重启或过一段时间后再读取该 Uri 会报FileNotFoundException。原因与解决这是系统授予的临时权限。要长期访问该文件你有两个选择立即将文件内容复制到应用的私有目录这是最可靠的方式。val inputStream contentResolver.openInputStream(selectedImageUri) val outputFile File(context.filesDir, “persisted_image.jpg”) inputStream?.use { input - FileOutputStream(outputFile).use { output - input.copyTo(output) } } // 之后使用 outputFile 的路径获取持久化权限调用takePersistableUriPermission()。但这通常只对Intent.ACTION_OPEN_DOCUMENT返回的 Uri 有效且用户必须在选择器里勾选了“允许访问所有文件”之类的选项系统决定不可控性高。4.2 前台服务类型化引发的崩溃与异常3.2.1ForegroundServiceStartNotAllowedException这是适配过程中最常见的崩溃。错误信息示例ForegroundServiceStartNotAllowedException: service ... does not have a foreground service type of ...根本原因在startForeground()调用中传入的foregroundServiceType与清单文件中该服务声明的android:foregroundServiceType不匹配或者清单文件中根本没有声明。排查流程检查清单声明确保出问题的 Service 在AndroidManifest.xml中明确定义了android:foregroundServiceType。检查类型值确认代码中startForeground()的第三个参数类型常量是清单中声明的类型的子集。例如清单声明了mediaPlayback|dataSync代码中传入FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK是合法的但如果清单只声明了mediaPlayback代码传入FOREGROUND_SERVICE_TYPE_DATA_SYNC就会崩溃。检查版本判断确保类型参数只在 Android 14 (API 34) 及以上版本传入。在旧版本传入这个参数会导致IllegalArgumentException。3.2.2 通知栏不显示或服务被系统快速停止可能原因通知渠道重要性不足从 Android 8.0 开始通知必须属于一个渠道。如果你的渠道重要性 (importance) 设置为IMPORTANCE_NONE或IMPORTANCE_MIN在 Android 14 的严格管理下它可能不足以支撑一个前台服务。前台服务通知的渠道重要性至少应为IMPORTANCE_LOW推荐IMPORTANCE_DEFAULT。通知内容不符合类型要求某些前台服务类型对通知内容有隐含要求。例如mediaPlayback类型最好使用MediaStyle通知并显示播放控制按钮。虽然不强制但符合用户预期和系统规范。后台启动限制如前所述在应用处于后台时启动前台服务受到限制。如果启动后通知一闪而过服务就被停止很可能是触发了这个限制。查看 Logcat 中是否有BackgroundServiceStartNotAllowedException相关的日志。4.3 兼容性处理与降级方案3.3.1 如何优雅地处理多版本兼容核心思想是运行时判断 SDK 版本执行不同的逻辑分支。fun startMyForegroundService(context: Context) { val intent Intent(context, MyService::class.java) if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { // Android 8.0 需要使用 startForegroundService context.startForegroundService(intent) } else { // 旧版本直接 startService context.startService(intent) } } // 在 Service 的 onStartCommand 中 override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { val notification buildNotification() if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // Android 14 startForeground(NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_SPECIFIC_TYPE) } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { // Android 8.0 - 13 startForeground(NOTIFICATION_ID, notification) } else { // Android 7.1 及以下启动服务并显示通知但不用 startForeground startService(Intent(this, this.javaClass)) (getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager).notify(NOTIFICATION_ID, notification) } // ... 其他逻辑 return START_STICKY }3.3.2 针对低版本用户的权限申请回退对于媒体权限在向用户展示时需要根据版本给出合理的解释。fun explainMediaPermissionRationale(activity: Activity, requestCode: Int) { val message if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { “为了给您提供音乐播放功能需要访问设备上的音频文件。” } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { “为了给您提供音乐播放功能需要访问设备上的音频文件。在 Android 13 上系统可能仍会请求访问媒体文件的通用权限” } else { “为了给您提供音乐播放功能需要访问设备的存储空间。” } AlertDialog.Builder(activity) .setTitle(“权限说明”) .setMessage(message) .setPositiveButton(“去授权”) { _, _ - requestPermissions(activity, requestCode) } .setNegativeButton(“取消”, null) .show() }5. 对应用架构的深远影响与未来展望Android 14/15 的这两项安全特性看似只是增加了几个权限常量和服务类型实则推动着 Android 应用开发向更规范、更安全、更以用户为中心的方向演进。它们迫使开发者重新思考应用的数据边界和后台行为。对架构的影响职责分离一个“大而全”的服务可能需要被拆分为多个职责单一的服务并声明不同的前台服务类型。例如一个既负责下载又负责播放的服务可以考虑拆分为DownloadService(dataSync) 和PlaybackService(mediaPlayback)。数据访问层抽象访问媒体文件的逻辑需要被很好地封装起来内部处理版本差异和权限检查。推荐使用Repository模式对外提供统一的getImages()、getVideos()接口内部根据 SDK 版本决定是使用细化权限查询、文件选择器还是旧版方式。后台任务现代化Foreground Service不再是后台任务的“万金油”。对于可延迟的、非用户即时感知的任务WorkManager成为了更标准、更省电的选择。它自动处理兼容性、网络条件和重试逻辑。未来展望 Google 对隐私和安全的重视只会增强。我们可以预见权限进一步细化也许未来会对“文档”类文件进行更细化的权限控制。前台服务管理更智能系统可能会根据前台服务类型、电量状况和用户使用习惯更积极地管理或限制服务运行。用户控制力提升设置中可能会提供更详细的前台服务运行历史和应用媒体访问记录让用户拥有更大的知情权和控制权。作为开发者主动拥抱这些变化提前进行适配和架构优化不仅能避免应用在新系统上崩溃更能提升应用在商店的口碑和用户信任度。毕竟一个尊重用户隐私和系统资源的应用才是可持续发展的应用。在适配过程中最深的体会是永远不要和系统的发展趋势对抗而是要学会利用系统提供的新工具和新范式来构建更好的应用体验。把这次适配看作是一次代码和架构的“体检”你会发现很多历史债务可以借此机会清理掉。
Android 14/15 安全适配：细化媒体权限与前台服务类型化实战指南
发布时间：2026/7/28 17:41:49
1. 项目概述Android 14/15 安全收紧的必然趋势如果你最近在适配 Android 14 或正在为 Android 15 的预览版做准备大概率已经遇到了两个让人头疼的新限制一个是针对媒体文件访问的Granular Media Permissions细化媒体权限另一个是针对前台服务的Foreground Service Types前台服务类型强制声明。这可不是简单的 API 版本号升级而是 Google 在用户隐私保护和系统资源管理上又一次“重拳出击”。我经历过从READ_EXTERNAL_STORAGE一权通吃到需要分门别类申请权限的时代也见证过前台服务从“保活神器”到被严格约束的历程。这次 Android 14/15 的新规可以看作是这两个趋势的深化和精细化。简单来说Google 的目标很明确最小权限原则和透明化原则。应用不能因为要播放音乐就要求获得访问用户所有照片和视频的权力也不能用一个模糊的“后台任务”理由就长期占用系统前台资源。对于开发者而言这意味着我们过去一些“图省事”的粗放式开发模式必须改变。适配这些新特性不仅仅是添加几行声明那么简单它涉及到应用架构的审视、数据流的重设计以及对用户体验的更深层次考量。接下来我将结合实际的代码和场景拆解这两大安全特性的核心逻辑、适配方案以及那些官方文档里不会写的“坑”。2. 核心安全特性深度解析2.1 Granular Media Permissions告别“全盘扫描”时代在 Android 13 之前我们申请READ_EXTERNAL_STORAGE权限用户一旦授权应用就能访问整个共享存储空间即/storage/emulated/0下的所有媒体文件。这就像拿到了用户家所有房间的万能钥匙显然过度了。Android 14 引入的细化媒体权限将媒体访问权从“一整块”切分成了“三小块”READ_MEDIA_IMAGES仅访问图片和截图。READ_MEDIA_VIDEO仅访问视频。READ_MEDIA_AUDIO仅访问音频文件。1.1.1 权限申请策略的转变最直接的影响是权限申请逻辑。你不能一上来就请求READ_EXTERNAL_STORAGE它在 Android 14 上已被标记为deprecated而应该按需申请。// 错误做法Android 14 if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { // 不要再使用这个了 // requestPermissions(arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE), REQUEST_CODE) } // 正确做法Android 14 if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // 如果你的应用只需要选择图片 requestPermissions(arrayOf(Manifest.permission.READ_MEDIA_IMAGES), REQUEST_CODE_IMAGES) // 或者如果需要图片和视频 val permissionsToRequest mutableListOfString() permissionsToRequest.add(Manifest.permission.READ_MEDIA_IMAGES) permissionsToRequest.add(Manifest.permission.READ_MEDIA_VIDEO) requestPermissions(permissionsToRequest.toTypedArray(), REQUEST_CODE_MEDIA) }注意对于 Android 13API 33它引入的是READ_MEDIA_IMAGES和READ_MEDIA_VIDEO。READ_MEDIA_AUDIO是在 Android 14API 34才加入的。所以你的兼容代码需要分层处理。1.1.2 对“文件选择器”和“媒体库”功能的冲击这对那些集成系统文件选择器Intent.ACTION_GET_CONTENT或Intent.ACTION_OPEN_DOCUMENT的应用影响相对较小因为系统选择器本身会处理权限。但如果你是自己遍历MediaStore来构建应用内的媒体库那就必须重构。例如一个音乐播放器应用现在应该只申请READ_MEDIA_AUDIO权限。当查询MediaStore.Audio.Media.EXTERNAL_CONTENT_URI时系统会自动过滤只返回你有权限访问的音频文件。你无法再通过MediaStore查询到图片或视频的信息即使它们物理上存在于存储中。1.1.3 Partial Media Access 的妙用Android 14 还强化了“部分媒体访问”特性。即使用户拒绝了完整的READ_MEDIA_*权限你仍然可以通过ActivityResultContracts.PickVisualMedia()或ActivityResultContracts.GetContent()契约让用户单次选择特定的图片或视频文件给你。系统会授予你的应用对该文件的临时访问权限。这对于“上传头像”、“发送图片”等一次性操作非常友好是实现“无需授权即可使用”功能的关键。// 使用 Photo Picker (推荐需要 Google Play 服务) val pickMedia registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri - uri?.let { // 处理用户选择的单个媒体文件URI } } pickMedia.launch(PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly)) // 或者使用通用选择器 val getContent registerForActivityResult(ActivityResultContracts.GetContent()) { uri - uri?.let { // 处理文件URI } } getContent.launch(“image/*”)2.2 Foreground Service 类型限制给“前台”一个明确的理由前台服务Foreground Service是应用在后台执行用户可感知任务的重要组件但它一直被滥用导致通知栏泛滥、电量消耗过快。Android 14 要求所有前台服务必须声明其符合的具体类型并在启动时提供该类型。1.2.1 强制声明的服务类型你需要在AndroidManifest.xml中为每个service声明android:foregroundServiceType属性并在代码中启动服务时通过Service.startForeground()的变体方法传入对应的类型。主要的类型包括camera用于相机操作。connectedDevice与配件或设备交互。dataSync数据同步。health健康相关。location获取位置信息。mediaPlayback媒体播放。mediaProjection屏幕投射或录制。microphone使用麦克风。phoneCall通话相关。remoteMessaging接收远程消息如FCM。shortService/specialUse短期或特殊任务。1.2.2 声明与启动的代码示例首先在清单文件中声明service android:name“.MyMusicPlaybackService” android:enabled“true” android:exported“false” android:foregroundServiceType“mediaPlayback” /然后在启动服务的代码中// 对于 Android 14 (API 34) 及以上 if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { val notification createMediaStyleNotification() // 创建对应的通知 startForeground(NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK) } else { // 旧版本方式 startForeground(NOTIFICATION_ID, notification) }1.2.3 类型不匹配的严重后果这里有一个大坑你在startForeground中传入的类型必须是你声明的android:foregroundServiceType的子集或完全匹配。系统会进行校验。例如你的服务声明了foregroundServiceType“mediaPlayback|dataSync”那么启动时你可以传入FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK或FOREGROUND_SERVICE_TYPE_DATA_SYNC或者两者的组合。但如果你声明的是mediaPlayback却试图以dataSync类型启动在 Android 14 设备上会抛出ForegroundServiceStartNotAllowedException异常。实操心得在适配初期最容易出错的地方就是遗漏了类型声明或者声明与启动类型不一致。务必在测试阶段在 Android 14 及以上版本的设备或模拟器上对所有使用前台服务的场景进行全覆盖测试。异常可能不会在开发时立即抛出而是在特定系统状态下触发。3. 适配实战从旧模式到新规范的迁移路径3.1 媒体权限适配的渐进式策略面对从 Android 10 (Scoped Storage) 到 Android 14 (Granular Media) 这一连串的存储权限变革一个健壮的适配策略必须是渐进式和条件化的。2.1.1 权限检查与申请的逻辑重构首先你需要一个统一的权限检查工具方法它能根据不同的 SDK 版本返回所需的权限数组。fun getRequiredStoragePermissions(context: Context, requestImage: Boolean, requestVideo: Boolean, requestAudio: Boolean): ArrayString { val permissions mutableListOfString() if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // Android 14 if (requestImage) permissions.add(Manifest.permission.READ_MEDIA_IMAGES) if (requestVideo) permissions.add(Manifest.permission.READ_MEDIA_VIDEO) if (requestAudio) permissions.add(Manifest.permission.READ_MEDIA_AUDIO) // 注意在 Android 14WRITE_MEDIA_IMAGES/VIDEO/AUDIO 用于写入特定媒体库而非通用写入。 } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { // Android 13 if (requestImage) permissions.add(Manifest.permission.READ_MEDIA_IMAGES) if (requestVideo) permissions.add(Manifest.permission.READ_MEDIA_VIDEO) if (requestAudio) { // Android 13 没有 READ_MEDIA_AUDIO音频访问仍需要旧权限或使用 MediaStore API // 更佳实践是引导用户使用文件选择器选择音频文件或申请 MANAGE_EXTERNAL_STORAGE上架审核严格 } } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.Q) { // Android 10-12在分区存储下应用私有目录和 MediaStore 无需权限。 // 但如果要访问其他应用创建的非媒体文件可能需要申请所有文件访问权限MANAGE_EXTERNAL_STORAGE。 // 通常对于媒体文件我们使用 MediaStore API不需要 READ_EXTERNAL_STORAGE。 } else { // Android 9 及以下 permissions.add(Manifest.permission.READ_EXTERNAL_STORAGE) // 可能还需要 WRITE_EXTERNAL_STORAGE } return permissions.toTypedArray() }2.1.2 使用 MediaStore API 进行安全查询无论权限如何变化访问共享媒体文件的正确方式始终是通过MediaStoreAPI。它提供了基于内容提供者的安全访问模型。fun queryAudioFiles(context: Context): ListAudio { val audioList mutableListOfAudio() val projection arrayOf( MediaStore.Audio.Media._ID, MediaStore.Audio.Media.DISPLAY_NAME, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.DATA // 谨慎使用在 Android Q 可能为空或需要不同方式访问 ) val selection “${MediaStore.Audio.Media.IS_MUSIC} ! 0” val sortOrder “${MediaStore.Audio.Media.DATE_ADDED} DESC” context.contentResolver.query( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, projection, selection, null, sortOrder )?.use { cursor - val idColumn cursor.getColumnIndexOrThrow(MediaStore.Audio.Media._ID) val nameColumn cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DISPLAY_NAME) while (cursor.moveToNext()) { val id cursor.getLong(idColumn) val name cursor.getString(nameColumn) val contentUri ContentUris.withAppendedId( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, id ) // 使用 contentUri 来访问文件而不是直接使用 DATA 路径 audioList.add(Audio(id, name, contentUri)) } } return audioList }关键技巧从 Android Q 开始MediaStore.MediaColumns.DATA字段即文件绝对路径可能已废弃或不可靠。始终优先使用_ID生成的ContentUri(如content://media/external/audio/media/123) 来通过ContentResolver.openInputStream(uri)访问文件内容。这是保证未来兼容性的关键。3.2 前台服务类型化改造的详细步骤对现有前台服务的改造需要从设计、声明到启动进行全链路检查。2.2.1 服务类型的合理选择与组合首先审视你的每一个前台服务明确其核心目的。一个服务可能符合多种类型吗官方允许组合使用通过位或运算符|但必须合理。案例一个音乐播放器服务它显然属于mediaPlayback。如果它还负责在播放时下载下一首歌曲的封面或歌词那么dataSync可能也是合理的。但你需要评估下载任务是否必须在前台进行能否交给WorkManager在后台处理前台服务类型越多对用户的通知干扰可能越大也越容易在审核时被质疑。案例一个健身追踪应用的服务它持续使用 GPS 记录轨迹 (location)同时可能通过蓝牙连接心率带 (connectedDevice)。那么它的类型就应该是location | connectedDevice。2.2.2 清单文件与启动代码的同步更新这是一个必须严格执行的 checklist更新AndroidManifest.xml为每个service标签添加android:foregroundServiceType属性。如果服务有多种前台运行模式可以声明多个类型。!-- 音乐播放服务 -- service android:name“.PlaybackService” android:foregroundServiceType“mediaPlayback” / !-- 文件上传服务 -- service android:name“.UploadService” android:foregroundServiceType“dataSync” / !-- 语音录制服务 -- service android:name“.RecordingService” android:foregroundServiceType“microphone” /更新启动服务的代码找到所有调用startForeground()的地方通常是Service类的onStartCommand或某个启动服务的方法中。class MyForegroundService : Service() { override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { // ... 服务逻辑准备 ... val notification buildNotification() if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // Android 14 必须指定类型 startForeground( NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_DATA_SYNC // 必须与清单声明匹配 ) } else { // 旧版本 startForeground(NOTIFICATION_ID, notification) } return START_STICKY } }处理PendingIntent的兼容性如果你的前台服务通知中包含PendingIntent比如播放/暂停按钮并且目标 Activity 或 BroadcastReceiver 对安全性有要求在 Android 14 你可能需要为其设置FLAG_IMMUTABLE或FLAG_MUTABLE。虽然这不直接关联服务类型但常在同一时期适配需要注意。2.2.3 后台启动限制的应对之策Android 14 还加强了对“后台启动前台服务”的限制。当应用处于后台状态时例如没有可见的 Activity也没有其他前台服务在运行尝试启动一个需要用户感知的前台服务会受到严格限制。应对策略使用高优先级通知对于某些紧急类型如phoneCall系统可能允许。使用startForegroundService()的兼容性在 Android 8.0 引入的startForegroundService()仍然有效但它会创建一个时间窗口你必须在这个窗口内约几秒钟调用startForeground()否则应用会 ANR。在 Android 14这个规则依然有效且类型必须匹配。考虑替代方案对于非即时性的任务如数据备份、日志上传优先考虑使用WorkManager来调度任务。WorkManager能更好地处理系统约束如电量、网络并且不需要前台服务。4. 常见问题排查与避坑指南在实际适配过程中我遇到了不少预料之外的问题。这里把它们整理出来希望能帮你节省时间。4.1 媒体权限相关的疑难杂症3.1.1 权限已授予但查询 MediaStore 返回空列表可能原因你的应用目标版本 (targetSdkVersion) 已经 29 (Android 10)但你没有正确适配分区存储。在 Android 10即使有READ_EXTERNAL_STORAGE权限默认也无法直接通过文件路径访问其他应用创建的媒体文件必须通过MediaStoreAPI。排查步骤检查AndroidManifest.xml中是否设置了requestLegacyExternalStorage”true”这只在targetSdkVersion29时有效且 Android 11 会忽略此标志。这不是长久之计。确认你使用的是MediaStoreAPI 进行查询并且Uri正确例如MediaStore.Images.Media.EXTERNAL_CONTENT_URI。在 Android 14确认你申请并获得了正确的细化权限READ_MEDIA_IMAGES等并且查询的MediaStore类别与权限匹配。使用adb shell dumpsys package your.package.name命令查看应用实际被授予的权限列表。3.1.2 通过文件选择器Photo Picker/GET_CONTENT获取的 Uri 无法长期使用问题描述用户通过Intent选择一张图片你拿到了content://开头的 Uri。当时可以读取但应用重启或过一段时间后再读取该 Uri 会报FileNotFoundException。原因与解决这是系统授予的临时权限。要长期访问该文件你有两个选择立即将文件内容复制到应用的私有目录这是最可靠的方式。val inputStream contentResolver.openInputStream(selectedImageUri) val outputFile File(context.filesDir, “persisted_image.jpg”) inputStream?.use { input - FileOutputStream(outputFile).use { output - input.copyTo(output) } } // 之后使用 outputFile 的路径获取持久化权限调用takePersistableUriPermission()。但这通常只对Intent.ACTION_OPEN_DOCUMENT返回的 Uri 有效且用户必须在选择器里勾选了“允许访问所有文件”之类的选项系统决定不可控性高。4.2 前台服务类型化引发的崩溃与异常3.2.1ForegroundServiceStartNotAllowedException这是适配过程中最常见的崩溃。错误信息示例ForegroundServiceStartNotAllowedException: service ... does not have a foreground service type of ...根本原因在startForeground()调用中传入的foregroundServiceType与清单文件中该服务声明的android:foregroundServiceType不匹配或者清单文件中根本没有声明。排查流程检查清单声明确保出问题的 Service 在AndroidManifest.xml中明确定义了android:foregroundServiceType。检查类型值确认代码中startForeground()的第三个参数类型常量是清单中声明的类型的子集。例如清单声明了mediaPlayback|dataSync代码中传入FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK是合法的但如果清单只声明了mediaPlayback代码传入FOREGROUND_SERVICE_TYPE_DATA_SYNC就会崩溃。检查版本判断确保类型参数只在 Android 14 (API 34) 及以上版本传入。在旧版本传入这个参数会导致IllegalArgumentException。3.2.2 通知栏不显示或服务被系统快速停止可能原因通知渠道重要性不足从 Android 8.0 开始通知必须属于一个渠道。如果你的渠道重要性 (importance) 设置为IMPORTANCE_NONE或IMPORTANCE_MIN在 Android 14 的严格管理下它可能不足以支撑一个前台服务。前台服务通知的渠道重要性至少应为IMPORTANCE_LOW推荐IMPORTANCE_DEFAULT。通知内容不符合类型要求某些前台服务类型对通知内容有隐含要求。例如mediaPlayback类型最好使用MediaStyle通知并显示播放控制按钮。虽然不强制但符合用户预期和系统规范。后台启动限制如前所述在应用处于后台时启动前台服务受到限制。如果启动后通知一闪而过服务就被停止很可能是触发了这个限制。查看 Logcat 中是否有BackgroundServiceStartNotAllowedException相关的日志。4.3 兼容性处理与降级方案3.3.1 如何优雅地处理多版本兼容核心思想是运行时判断 SDK 版本执行不同的逻辑分支。fun startMyForegroundService(context: Context) { val intent Intent(context, MyService::class.java) if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { // Android 8.0 需要使用 startForegroundService context.startForegroundService(intent) } else { // 旧版本直接 startService context.startService(intent) } } // 在 Service 的 onStartCommand 中 override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { val notification buildNotification() if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { // Android 14 startForeground(NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_SPECIFIC_TYPE) } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { // Android 8.0 - 13 startForeground(NOTIFICATION_ID, notification) } else { // Android 7.1 及以下启动服务并显示通知但不用 startForeground startService(Intent(this, this.javaClass)) (getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager).notify(NOTIFICATION_ID, notification) } // ... 其他逻辑 return START_STICKY }3.3.2 针对低版本用户的权限申请回退对于媒体权限在向用户展示时需要根据版本给出合理的解释。fun explainMediaPermissionRationale(activity: Activity, requestCode: Int) { val message if (Build.VERSION.SDK_INT Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { “为了给您提供音乐播放功能需要访问设备上的音频文件。” } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.TIRAMISU) { “为了给您提供音乐播放功能需要访问设备上的音频文件。在 Android 13 上系统可能仍会请求访问媒体文件的通用权限” } else { “为了给您提供音乐播放功能需要访问设备的存储空间。” } AlertDialog.Builder(activity) .setTitle(“权限说明”) .setMessage(message) .setPositiveButton(“去授权”) { _, _ - requestPermissions(activity, requestCode) } .setNegativeButton(“取消”, null) .show() }5. 对应用架构的深远影响与未来展望Android 14/15 的这两项安全特性看似只是增加了几个权限常量和服务类型实则推动着 Android 应用开发向更规范、更安全、更以用户为中心的方向演进。它们迫使开发者重新思考应用的数据边界和后台行为。对架构的影响职责分离一个“大而全”的服务可能需要被拆分为多个职责单一的服务并声明不同的前台服务类型。例如一个既负责下载又负责播放的服务可以考虑拆分为DownloadService(dataSync) 和PlaybackService(mediaPlayback)。数据访问层抽象访问媒体文件的逻辑需要被很好地封装起来内部处理版本差异和权限检查。推荐使用Repository模式对外提供统一的getImages()、getVideos()接口内部根据 SDK 版本决定是使用细化权限查询、文件选择器还是旧版方式。后台任务现代化Foreground Service不再是后台任务的“万金油”。对于可延迟的、非用户即时感知的任务WorkManager成为了更标准、更省电的选择。它自动处理兼容性、网络条件和重试逻辑。未来展望 Google 对隐私和安全的重视只会增强。我们可以预见权限进一步细化也许未来会对“文档”类文件进行更细化的权限控制。前台服务管理更智能系统可能会根据前台服务类型、电量状况和用户使用习惯更积极地管理或限制服务运行。用户控制力提升设置中可能会提供更详细的前台服务运行历史和应用媒体访问记录让用户拥有更大的知情权和控制权。作为开发者主动拥抱这些变化提前进行适配和架构优化不仅能避免应用在新系统上崩溃更能提升应用在商店的口碑和用户信任度。毕竟一个尊重用户隐私和系统资源的应用才是可持续发展的应用。在适配过程中最深的体会是永远不要和系统的发展趋势对抗而是要学会利用系统提供的新工具和新范式来构建更好的应用体验。把这次适配看作是一次代码和架构的“体检”你会发现很多历史债务可以借此机会清理掉。
![[codeforces23C]Oranges and Apples](http://pic.xiahunao.cn/yaotu/[codeforces23C]Oranges and Apples)
