兄弟，我太懂你这种折腾半天踩坑的滋味了！咱们来把这个问题拆明白，一步步解决：

核心问题根源：权限的专属绑定 #

你碰到的情况本质是私有/签名绑定权限在搞鬼：有些权限（尤其是系统或厂商定制的）会和特定应用的包名、签名硬绑定，不是随便在AndroidManifest.xml里加一句就能用的。

先理清你遇到的两个现象： #

• 未加权限时自研应用崩溃：说明你的代码确实触发了目标Activity的权限检查，系统发现你没有权限直接抛出异常。
• 添加权限后无法安装：系统检测到这个权限是“专属权限”，只能由特定包名/签名的应用申请，你的自研应用不符合条件，PackageManager直接拒绝安装。
• ADB启动失败：如果目标Activity要求的是signature或signatureOrSystem级别的权限，普通ADB（非root/非系统签名）根本拿不到权限，自然启动失败。

具体排查与解决步骤 #

1. 先搞清楚目标权限的属性 #

首先得确认目标Activity要求的权限是什么，以及这个权限的保护级别：

• 用aapt解析目标应用的Manifest（需要先拿到目标APK）：

  aapt dump xmltree com.target.package AndroidManifest.xml | grep -A 3 "android:permission"
  

  找到类似android:permission="com.target.permission.LAUNCH_SECRET_ACTIVITY"的字段，这就是需要的权限。
• 再查这个权限的保护级别：

  adb shell dumpsys package permissions | grep -B 2 -A 2 "com.target.permission.LAUNCH_SECRET_ACTIVITY"
  

  重点看protectionLevel字段，常见值：
  • normal/dangerous：普通权限，处理成本低；
  • signature：必须和目标应用同签名才能使用；
  • signatureOrSystem：同签名或系统应用才能使用；
  • privileged：厂商专属特权权限。

2. 针对不同权限级别的解决方案 #

情况一：权限是normal/dangerous级别

• ADB启动：直接执行启动命令即可，若为危险权限，可尝试指定用户参数：

  adb shell am start -n com.target.package/com.target.package.SecretActivity --user 0
  

  自研应用端：危险权限需要动态申请，申请通过后再调用startActivity即可。

情况二：权限是signature级别

这是最常见的限制场景，只有两个可行方向：

• 给你的自研应用使用和目标应用完全相同的签名文件打包（前提是你能拿到这个签名，一般只有应用开发者或厂商能做到），这样系统会认为你的应用是“可信关联应用”，就能正常申请权限并启动Activity。
• 用root权限绕过检查（仅限测试场景）：
  直接用root后的ADB执行启动命令：

  adb shell su -c am start -n com.target.package/com.target.package.SecretActivity
  

  或者在自研应用里，通过root权限执行启动命令，跳过系统权限检查。

情况三：权限是signatureOrSystem级别

除了上面的签名方案，还可以把你的自研应用放到系统分区（需要root）：

# 先创建系统应用目录
adb shell mkdir /system/app/MyLauncher
# 推送APK到系统目录
adb push my-app.apk /system/app/MyLauncher/
# 修改权限
adb shell chmod 644 /system/app/MyLauncher/my-app.apk
# 重启设备
adb shell reboot

重启后你的应用会被识别为系统应用，就能申请到这个权限了。

情况四：厂商专属privileged权限

这种情况基本没辙，除非你能拿到厂商的签名授权，或者使用厂商提供的开放API来间接启动目标Activity。

最后提醒 #

如果是面向生产环境的应用，尽量不要依赖这种私有权限的玩法，兼容性和合规风险太高；如果只是测试用，root或签名方案足够解决问题。

内容的提问来源于stack exchange，提问作者lgtkbz