Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
5.4.1
-
None
-
cordova-android 6.4.0
Description
As specified in https://cordova.apache.org/docs/en/latest/config_ref/
android-targetSdkVersion(integer) can be used to configure the target SDK. This means that after you generate the project, it will build with this targetSDK.
However, this is not the case.
As a result, the ability to override the gradle files via either
gradle.properties
cdvCompileSdkVersion=23
cdvBuildToolsVersion="23.0.3"
build-extras.gradle
ext.cdvCompileSdkVersion = 23
ext.cdvBuildToolsVersion = "23.0.3"
does not work. It will always try to use the hard coded target which is android-25 to build the project. It will try to download the SDK and then build it.
Details
-----------------
In the CordovaLib/project.properties it hardcodes a target target=android-25. As a result, in CordovaLib/cordova.gradle
String doGetProjectTarget() {
def props = new Properties()
file('project.properties').withReader
return doEnsureValueExists('project.properties', props, 'target')
}
will always return android-25.
What this means is that in the CordovaLib/build.gradle
ext {
apply from: 'cordova.gradle'
cdvCompileSdkVersion = privateHelpers.getProjectTarget()
cdvBuildToolsVersion = privateHelpers.findLatestInstalledBuildTools()
}
The target will always be 25.
You can see this if you add the gradle task to the file
task cdvPrintPropsSubTest << {
println('buildsdk=' + privateHelpers.findLatestInstalledBuildTools())
println('target=' + privateHelpers.getProjectTarget())
println('cdvCompileSdkVersion=' + cdvCompileSdkVersion)
println('cdvBuildToolsVersion=' + cdvBuildToolsVersion)
println('cdvVersionCode=' + cdvVersionCode)
println('cdvMinSdkVersion=' + cdvMinSdkVersion)
println('cdvBuildMultipleApks=' + cdvBuildMultipleApks)
println('cdvReleaseSigningPropertiesFile=' + cdvReleaseSigningPropertiesFile)
println('cdvDebugSigningPropertiesFile=' + cdvDebugSigningPropertiesFile)
println('cdvBuildArch=' + cdvBuildArch)
println('computedVersionCode=' + android.defaultConfig.versionCode)
android.productFlavors.each
}
The workaround is to modify the generated files, but this defeats the purpose of being able to regenerate the code without having to worry about custom modifications to it.