简介在Android 7.0引入Scoped Installers安全特性后普通应用无法像旧版本那样直接触发系统安装器完成APK安装。这份资源提供了一套基于PackageInstaller API的完整示例工程面向需要实现下载后自动安装、应用内更新或静默安装场景的Android开发者。工程详细演示了从清单声明INSTALL_PACKAGES权限、运行时动态请求用户授权到创建安装会话、以流方式写入APK文件、提交会话并借助BroadcastReceiver监听安装成功或失败状态的全流程并附带InstallAPKDemo可直接运行与调试的源码。压缩包内共862个文件约66MB主要包含XML布局与配置、Java业务逻辑、JSON资源文件、PNG图片素材及Gradle构建脚本也包含编译好的APK和依赖JAR包目录结构清晰便于按模块研读。目前已有13349人学习下载适合从事Android系统适配、应用分发或企业设备管理的开发者参考。1. 7.0这道坎为什么file://突然就不能用了做Android的老开发应该都对7.0那次改动印象深刻。2016年Android 7.0Nougat发布之后很多App在“下载APK - 点击通知 - 跳转安装”这条链路上突然大面积崩溃日志无一例外都指向同一个异常FileUriExposedException。我当时排查的第一个线上问题就是这个用户一升级系统应用商店下载的APK装不上了反馈像雪片一样飞过来。这个崩溃的根本原因是系统对“App对外暴露文件URI”这件事的态度变了。Android 7.0之前你拿到一个file:///storage/emulated/0/Download/xxx.apk路径直接扔给Intent就能唤起系统安装器。但从7.0开始系统强制禁止一个App通过file://URI向另一个App共享文件因为这种URI暴露的是文件在文件系统中的绝对路径任何拿到路径的进程都能直接访问既没法做细粒度的权限控制也不安全。等于说原本“把家门钥匙直接递给别人”的做法被系统彻底叫停了。替代方案是FileProvider一种基于content://URI的共享机制。content://不暴露真实路径只暴露一个抽象的URI由系统通过ContentProvider的机制来授权访问。App在创建URI时可以对目标应用临时授予读写权限FLAG_GRANT_READ_URI_PERMISSION权限会在接收方任务栈结束后自动回收这种“临时授权”的设计从源头解决了路径泄漏问题。很多没经历过那个时期的Android开发者现在看FileProvider已经是标配了但你要知道这套适配是在7.0那次被“强制”出来的。而且它影响的绝不仅仅是“下载安装”这一个场景凡是涉及App之间共享文件的比如唤起相机拍照ACTION_IMAGE_CAPTURE、打开附件、分享文件全部都要走这套机制。2. FileProvider配置与路径映射从崩溃到跑通解决7.0的崩溃第一步就是在AndroidManifest.xml里注册FileProvider。application provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /provider /application这里有三个关键点。第一authorities由${applicationId}动态拼接保证不同App之间不会撞车在自己代码里取的时候也要用同一个规则拼。第二exportedfalse是必须的FileProvider本身的导出要关掉它的开放能力是通过grantUriPermissionsIntent临时授权来体现的。第三meta-data指向一个XML文件用来声明“我可以暴露哪些目录给外部”。接下来是res/xml/file_paths.xml的配置?xml version1.0 encodingutf-8? paths external-path nameexternal_storage path. / external-files-path nameexternal_files pathDownload / /paths我把external-path配成了.意思是整个外置存储卡根目录都允许暴露。实际生产环境出于安全考虑不建议这样全量开放最好是精确到目录。但这里有个容易踩的坑如果你用DownloadManager下载后文件最终落在/storage/emulated/0/Download/而你在file_paths.xml里配的external-files-path对应的是/storage/emulated/0/Android/data/包名/files/两边对不上Uri.fromFile和FileProvider.getUriForFile的映射就会失败导致IllegalArgumentException: Failed to find configured root。做FileProvider映射脑子里始终要绷着一根弦代码里传的File路径必须落在file_paths.xml某个配置项声明的根目录下。我自己比较根治的做法是APK下载不一定非要用系统DownloadManager关于这个我后面会详细说而是自己指定App专属目录比如context.getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS)然后配置对应的external-files-path目录是自己创建的永远可控不用去猜系统下载目录的路径。不过很多产品和运营的诉求是APK要出现在“下载”文件夹里用户找得到那你就得和DownloadManager的目录做好映射这个心情我能理解所以后面两章我把两条路都走一遍。3. 从DownloadManager到安装器一条完整的下载安装链路先说“下载”这个环节。Android里下载APK最正统的姿势是DownloadManager系统级服务不需要自己维护下载任务线程自带断点续传和通知栏进度展示。核心思路是发起下载请求、注册广播接收下载完成通知、把下载好的文件通过FileProvider转成content URI唤起安装。3.1 发起下载任务val request DownloadManager.Request(Uri.parse(downloadUrl)) request.setTitle(应用更新) request.setDescription(正在下载最新版本) request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED) request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, app_update_v$versionCode.apk) val manager getSystemService(Context.DOWNLOAD_SERVICE) as DownloadManager val downloadId manager.enqueue(request)setDestinationInExternalPublicDir搭配Environment.DIRECTORY_DOWNLOADS文件会落在/storage/emulated/0/Download/下。这里有个操作细节如果同名文件已经存在DownloadManager会直接把新下载的任务标记为失败STATUS_FAILEDreason是ERROR_FILE_ALREADY_EXISTS所以要么下载前先删旧文件要么给文件名加上时间戳或版本号。我在代码里偏好用“包名版本号时间戳”拼文件名从根源上避免冲突。3.2 监听下载完成DownloadManager完成通知是个广播动态注册即可private val receiver object : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { val id intent.getLongExtra(DownloadManager.EXTRA_DOWNLOAD_ID, -1) if (id ! downloadId) return val query DownloadManager.Query().setFilterById(id) val cursor manager.query(query) if (cursor.moveToFirst()) { val status cursor.getInt(cursor.getColumnIndex(DownloadManager.COLUMN_STATUS)) if (status DownloadManager.STATUS_SUCCESSFUL) { val uri manager.getUriForDownloadedFile(id) openInstaller(uri) } else { val reason cursor.getInt(cursor.getColumnIndex(DownloadManager.COLUMN_REASON)) // 处理失败 } } cursor.close() } }getUriForDownloadedFile从DownloadManager返回的默认就是content://URI听起来好像可以直接跳过FileProvider的步骤了这里有一个非常隐蔽的坑后面专门说。3.3 唤起安装器这是“自动安装”的核心Android 7.0下的标准做法fun openInstaller(uri: Uri) { val intent Intent(Intent.ACTION_VIEW).apply { setDataAndType(uri, application/vnd.android.package-archive) addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION) } startActivity(intent) }FLAG_GRANT_READ_URI_PERMISSION意图非常明确把读权限临时共享给系统安装器安装器在它自己的任务结束之后这个授权就自动失效了。这个Flag在这一步是绝对不能漏掉的漏了就会报Permission Denial: opening provider。但这里要特别强调getUriForDownloadedFile和FileProvider两条路线之间的差异。对同一份APK文件用manager.getUriForDownloadedFile(id)拿到的URI是DownloadManager内部自己定的一个content URI由系统DownloadManager的机制来处理授权。看起来能用但实测在部分厂商ROM上有兼容性问题。用FileProvider.getUriForFile(context, 包名.fileprovider, File)拿到的是你自己Provider的content URI配合FLAG_GRANT_READ_URI_PERMISSION是官方推荐、兼容性最稳的做法。我在开发中始终选择后者。做法是拿到DownloadManager的下载路径之后从COLUMN_LOCAL_URI里解析出真实File路径再丢给FileProvider重新生成URI。4. 安装环节Intent构建、未知来源权限与7.0/8.0边界严格说“未知来源安装”这个开关是Android 8.0O才大改的但因为很多7.0时代的App后来升级targetSdk会连着踩这个雷我干脆放在一起讲清楚。4.1 Android 7.0到8.0之间发生了什么Android 7.0时用户安装未知来源APK时系统会弹一个“允许安装未知来源应用”的全局总开关开关一开所有应用都可以装APK。到了Android 8.0这个“一刀切”的总开关被废除了改成按应用维度授权哪个App要装APK用户得单独给这个App开权限。做法是在你的安装入口之前检查Settings.canDrawOverlays那种类型的权限这里对应的是Settings.ACTION_MANAGE_UNKNOWN_APP_SOURCES。所以如果你处理的场景是“targetSdkVersion 26同时在8.0设备上”需要在唤起安装器前加上权限判断fun installApk(context: Context, uri: Uri) { if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { val canInstall context.packageManager.canRequestPackageInstalls() if (!canInstall) { // 跳转到本应用的未知来源安装授权页 val intent Intent( Settings.ACTION_MANAGE_UNKNOWN_APP_SOURCES, Uri.parse(package:${context.packageName}) ) context.startActivity(intent) return } } // 7.0及以上的标准安装Intent val intent Intent(Intent.ACTION_VIEW).apply { setDataAndType(uri, application/vnd.android.package-archive) addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION) } context.startActivity(intent) }需要注意canRequestPackageInstalls()返回false不代表安装被永久禁止你跳到授权页让用户打开开关从授权页返回后要再走一遍安装逻辑。比较常见的做法是在onResume或onActivityResult里重新检查权限并触发安装。4.2 安装Intent的目标系统行为ACTION_VIEW加application/vnd.android.package-archiveMIME类型系统会把APK交给PackageInstaller也就是用户看到的那个带“安装”“取消”按钮的界面。这一步没法做到真正意义上的“静默安装”除非你是设备所有者Device Owner或者有系统签名普通App走到这里必须经过用户确认。所以标题里说的“自动安装”业内共识是“下载完成后自动唤起安装界面并带好所有授权”更精确地说叫“下载后自动引导安装”。我在实际项目里会把“点击通知栏”这一步也弱化掉下载完成后广播里直接唤起安装界面用户看到安装弹窗时手指只需要点一下“安装”就行。这个体验比“下载完 - 用户再点通知 - 再点安装”少了两跳对移动端转化率是有直接帮助的。4.3 从7.0到6.0的兼容写法如果App还在兼容Android 6.0及以下判断逻辑不能按7.0一刀切fun getInstallIntent(file: File): Intent { val intent Intent(Intent.ACTION_VIEW) intent.setDataAndType( if (Build.VERSION.SDK_INT Build.VERSION_CODES.N) { FileProvider.getUriForFile(context, $packageName.fileprovider, file) } else { Uri.fromFile(file) }, application/vnd.android.package-archive ) if (Build.VERSION.SDK_INT Build.VERSION_CODES.N) { intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION) } return intent }5.0、6.0还可以用file://7.0开始必须切到FileProvider。如果targetSdk设得高而系统版本低系统会有弹窗提示“为旧版系统打造可能无法正常运行”这种属于厂商兼容策略不用慌。5. 实测最容易翻车的几个坑与排查清单这一章全部来自真实踩坑记录。有些问题只在特定ROM上出现有些是所有机型通吃我按频率排个序。5.1 权限声明不全很多人只记得写WRITE_EXTERNAL_STORAGE和REQUEST_INSTALL_PACKAGES漏掉了最关键的uses-permission android:nameandroid.permission.DOWNLOAD_WITHOUT_NOTIFICATION /这个权限负责“不弹通知也能下载”。如果你的下载任务设置了VISIBILITY_HIDDEN但没声明这个权限任务一发起就直接SecurityException。另外运行时权限的申请顺序也很重要Android 6.0在发起DownloadManager之前必须已经把存储读写权限拿到手否则下载会失败而且失败后的错误信息藏在COLUMN_REASON里不看日志很难定位。5.2 DownloadManager拿到的URI直接扔给Intent报FileUriExposedException前面说过getUriForDownloadedFile理论上返回的是content URI不会崩。但如果你自己拼File路径有的项目里会用COLUMN_LOCAL_URI拿到文件地址后重新new File再通过Uri.fromFile转成File URI扔给Intent那在7.0上直接撞FileUriExposedException。这类崩溃线上量往往还不小因为很多开发不知道DownloadManager返回的路径还要再走一道FileProvider映射。5.3 FileProvider的authorities与代码不一致FileProvider.getUriForFile(context, 你的applicationId.fileprovider, file)这里第二个参数是字符串如果和Manifest里android:authorities拼的不一致崩溃信息会提示Unable to find specified provider。如果你用了applicationId后缀方式但模块混淆或buildTypes里配置了applicationIdSuffix比如.debug、.dev这段字符串就会对不上。最稳的写法是先在代码里动态取一次或直接用BuildConfig.APPLICATION_ID .fileprovider拼出来不要把字符串写死在上百个地方。5.4 下载目录被清理/不可写部分国产ROM对/storage/emulated/0/Download/的写入限制比较任性尤其当App没有用户可见的下载行为时系统可能把下载目录清掉或者DownloadManager写不了这个目录。我实测过的最严重的一次某品牌手机在用户清理垃圾时把Download目录里的APK连同下载任务记录一起干掉了但用户侧看到的反馈只是“下载完了点通知没反应”。后来我把下载目录迁到getExternalFilesDir下App私有外部目录即便用户清垃圾系统也不会动自己私有的数据目录问题才消停。代价是用户去文件管理器看不到下载的APK但更新完成率比“看得到”重要得多。5.5 厂商ROM对“8.0未知来源安装”的魔改Google原生8.0是“首次唤起安装器时弹权限申请”但不少国产ROM把“允许安装未知应用”这个开关默认设成了“询问”或“禁止”而且藏在设置的很深处用户根本找不到。这种情况下你能做的就是引导页做得足够清晰告诉用户点“去授权”跳转到ACTION_MANAGE_UNKNOWN_APP_SOURCES后用户开了再回来。实测中拿不到这个权限时就算startActivity抛异常前你做了try-catch用户也只会看到一个“无法打开安装界面”的Toast体验很糟。所以我会在进安装页之前先检查权限没权限就先引导不要等用户点了下载完了再引导。5.6 下载ID丢失downloadId最好直接SharedPreferences持久化。不然App进程被杀重建之后广播里的EXTRA_DOWNLOAD_ID和内存里的ID对不上下载完成的广播怎么等都等不到。有些国产ROM后台清理非常激进App在下载过程中被杀掉然后系统把下载任务挂在后台完成了广播发出来却被系统连带着一起干掉了用户看到通知栏100%但点击后无反应。折中方案是启动时把DownloadManager里未完成的任务全量查一遍找到目标文件直接判断是否已下载完成若已完成就补一次安装引导。5.7 覆盖安装时版本号判断下载前一定要校验服务器返回的versionCode大于当前versionCode否则用户下载完安装时系统告诉你“已安装相同版本”体验极其尴尬。更细一点因为APK可能在多个市场渠道分发我建议把下载接口返回的versionCode同时写在本地下载任务的文件名里更新检测时先比版本再比文件大小能少走很多坑。6. 关于“下载器”选型的一个个人建议最后展开说一个我反复提到的东西——很多项目不一定要用DownloadManager。如果你要精细控制下载过程比如断点续传、进度条回调到UI、多任务并发、加密/校验APK完整性DownloadManager的封装其实并不方便。它的DownloadManager.Query只能轮询进度粒度是bytes返回状态偶尔还会抽风部分ROM上任务明明完成了状态还是STATUS_RUNNING。我自己后期做的更新模块下载这块是直接用OkHttp 协程自己拉的下载到App私有目录算好MD5再用同一个FileProvider URI去安装。优点是全程逻辑在自己手里权限、异常、进度都能兜住缺点是断点续传得自己实现Range头 RandomAccessFile展示通知栏要自己发通知。两套方案没有绝对的优劣如果产品对下载过程没有强要求用DownloadManager省心如果下载是本App的高频核心路径尤其是需要上报下载状态、失败重试策略的建议自己写。这句话我也送给刚开始做这块的人不要让“自动安装”变成“装不上之后用户只能卸载重装”下载路径、FileProvider映射、权限引导这三件事上线前挨个在7.0、8.0、10.0、13.0各找一台真机过一遍比看任何文章都管用。本文还有配套的精品资源点击获取
