2

在 Google I/O 主题演讲和关于 Android M 功能的连续讨论之后不久，我开始尝试新的 SDK 功能，例如运行时权限。为此，有必要设置thecompileSdkVersion和targetSdkVersionto android-mnc。在安装了 Android M Developer Preview 的 Nexus 5 上运行项目时，Android Studio 会安装该应用程序，并且它可以在设备上正常运行。

如果我将其设置minSdkVersion为例如 10 以在 2.3.6 设备上测试它或设置为 21 以在 5.0 设备上测试它，它仍然适用于 M-Nexus5，但不适用于上述具有低于 M API 的设备版本。

apply plugin: 'com.android.application'

android {
    buildToolsVersion "22.0.1"
    compileSdkVersion 'android-MNC'

    defaultConfig {
        applicationId "de.FOOBAR.permtestproject"
        minSdkVersion 10
        targetSdkVersion 21
        versionCode 23
        versionName "1.0"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:design:22.2.0'
    compile 'com.android.support:appcompat-v7:22.2.0'
}

正如您在以下屏幕截图中看到的那样，即使我将 minSdkVersion 设置为 10 而不是声称的 22 级别，我的 21 级设备仍显示为不兼容。

前台可用设备对话，后台gradle构建文件

降低targetSdkVersionto21并没有什么不同。更改compileSdkVersion不是一个选项，因为权限请求调用在 M(NC) 之前的 SDK 中不可用。

尝试在 pre-M 设备上运行应用程序总是失败并显示错误INSTALL_FAILED_OLDER_SDK。

INSTALL_FAILED_OLDER_SDK

4

1 回答 1

4

引用我自己的话：

在 M Developer Preview 的情况下，compileSdkVersion值android-MNC会导致构建过程将 MNC 作为minSdkVersion和targetSdkVersion放入生成的清单中。

幸运的是，清单是文本文件。

因此，这是一个 android 闭包，它可以构建一个针对 MNC 编译但将在 API 级别 15+ 设备上运行的应用程序模块：

android {
    compileSdkVersion 'android-MNC'
    buildToolsVersion "23.0.0 rc1"

    defaultConfig {
        minSdkVersion 15
        targetSdkVersion 15
    }

    // based on http://stackoverflow.com/a/27372806/115145

    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.processManifest.doLast {
                def manifestOutFile = output.processManifest.manifestOutputFile
                def newFileContents = manifestOutFile.getText('UTF-8').replace("MNC", "15")
                manifestOutFile.write(newFileContents, 'UTF-8')
            }
        }
    }
}

这对问题采取了一种非常“穴居人”的方法，读入生成的清单，用 替换所有出现的MNC地方15，然后将调整后的清单写回。这将在具有MNC其他地方的项目上失败，例如活动的类名。它还将minSdkVersion和设置targetSdkVersion为相同的值。一个更复杂的脚本将替换那些单独的属性——这一点的证明留给读者作为练习。同样，更强大的脚本会从defaultConfig并应用它们。而且，具有安全意识的版本仅将其应用于可调试的变体，从而有助于减少流口水的白痴试图发布执行此覆盖的发布版本的影响。这只是一个概念证明，并没有实现所有可能的花里胡哨。

同样，这样做并将结果发布到 Play 商店或其他地方是非常愚蠢的。仅将其用于测试。

于 2015-06-09T14:19:04.593 回答