一. 序
当我们在 Android Studio 中，直接 Run 一个项目时，AS 会自动打一个 Debug 的 Apk，并通过 ADB 命令，将 App 安装到我们连接的设备上。
这个 Run 出来的 Apk，在工程的 build/ 目录可以找到。如果你还想把这个 Apk 分享出去，抢先体验功能，不好意思，正常情况下，这个 Apk 是无法安装的。
接下来看看，是什么导致 Run 出来的 APK 无法安装。
二. Run 的 Apk
2.1 testOnly 属性
我们知道，AS Run 起来的 Apk，会使用 Debug 签名进行签名，不过安装不上，并不是签名的问题。
而是因为，Run 出来的 APK，会在 AndroidManifest.xml 文件中，增加 android:testOnly 属性，正是因为这个属性，阻止了我们使用正常方式安装 APK。
android:testOnly 对应的是 ApplicationInfo 中的 FLAG_TEST_ONLY，这个 Flag 最早在 Api Level 4 就已经存在，使用它不会有任何低版本兼容的问题。
当你使用 adb install 安装 android:testOnly="true" 的包时，输出的错误信息，明确的标记了无法安装一个 TEST_ONLY 的包。
代码语言：txt复制Failed to install app-debug.apk: Failure [INSTALL_FAILED_TEST_ONLY: installPackageLI]对于多年 Android 经验的开发者来说，如果曾经将 Run 出来的 Debug.apk 分享给别人时，早年间是可以正常安装的，那 testOnly 属性是在什么时候被加在 Debug.apk 上的呢？
虽然 FLAG_TEST_ONLY 属性最早可以追溯到 APK Level 4，但是它其实是在 Android Studio 3.0 上才被默认加入到 APK 中的。只有 AS 3.0 的 IDE 上，Run 出来的 APK，才会默认带上 testOnly 属性，这将阻止你使用正常的方式安装。
简单小结一下：
我们无法通过正常安装方式，安装一个带有 android:testOnly="true" 的 Apk。
这个属性，是在 AS 3.0 中加入的。
这就是为什么你无法安装 Run 出来的 Debug.apk。
2.2 为什么要这么设计？
这个问题，对于大多数开发者来说，基本上不是问题。
因为我们只要保证正常的提测、发布流程，基本上是很难将一个 Run 出来的 Apk 分享给别人的。
testOnly 只是一个标记，标记了它是一个测试的版本，其实并没有任何实质性的东西。如果因为流程上的失误，将其分享出去，这也是很容易就可以发现的，因为这个包正常流程无法安装。
2.3 是不是真的无法安装？
如果我们非要安装一个带有 testOnly 的 Apk，其实也是有办法的，否则 AS 又是如何将 Run 起来的包，安装到设备上的呢？
解决方法也很简单，只需要在 adb install 上，增加 -t 即可。
代码语言：txt复制adb install -t debug.apk如果想要阻止 AS 在 Run 时，构建的 APK 中增加 android:testOnly 标记，也是有办法的。
可以在 gradle.properties 文件中，增加 android.injected.testOnly=false 即可。
代码语言：txt复制# gradle.properties
android.injected.testOnly=false然后这个 android:testOnly 属性就会消失。
三. 小结时刻
AS Run 出来的 Apk，之所以无法安装，是因为其携带了 FLAG_TEST_ONLY 这个 Flag，它会阻止我们使用正常的方式安装。想要安装，可以通过 adb install -t 来解决。
虽然这个 Flag 初始于 API Level 4，但是它在 AS 3.0 中，才被默认加入。想要去掉可以通过增加 android.injected.testOnly=false 来实现。
这个问题当个小知识点了解一下即可，正常我们也不会遇到这样的问题，毕竟谁会把一个 Run 出来的包出去呢。
