Why?

Cause - Why, why, why this is needed?

• Developers will build all abis for an imported qt project by default. A better default would be that only teh ABI for the current target device will be built.
•  

Customer - who wants this?

• Anyone who wants to get up and running quickly for Qt Quick for Android.

Cruft - Why this would not be needed?

• Targeting one ABI would speed up build times, especially in large projects.
•  

What?

Definition - what is this?

Study also AGP providing this

Below is the ADB way

I added this to my app build.gradle.kts file 
val androidSdkPath = System.getenv("ANDROID_SDK_ROOT") ?: System.getenv("ANDROID_HOME")
?: throw GradleException("ANDROID_SDK_ROOT or ANDROID_HOME environment variable not set.")

val adbPath = "$androidSdkPath/platform-tools/adb"

val detectedAbi: String by lazy {
try {
val process = ProcessBuilder(adbPath, "shell", "getprop", "ro.product.cpu.abi")
.redirectErrorStream(true)
.start()

val abi = process.inputStream.bufferedReader().readText().trim()
if (abi.isEmpty())

{ throw GradleException("Failed to detect ABI from device.") }

when (abi)

{ "arm64-v8a" -> "arm64_v8a" "armeabi-v7a" -> "armv7" "x86" -> "x86" "x86_64" -> "x86_64" else -> throw GradleException("Unsupported ABI: '$abi'") }

} catch (e: Exception) {
throw GradleException("Error detecting ABI: ${e.message}", e)
}
}

val autoTargetDirPath = "D:/Qt/6.10.0/android_$detectedAbi"
val autoTargetABI = file(autoTargetDirPath)

if (!autoTargetABI.exists())

{ throw GradleException("Qt Kit directory not found for ABI '$detectedAbi' at $autoTargetDirPath") }

and then modified the Qt build block like so

QtBuild

{ //set qtPath to your installed Qt Kit Location //for example for the Qt 6.9.1 release : //on windows "C:/Qt/6.9.1" //on linux "/home/username/Qt/6.9.1" qtPath = file("D:/Qt/6.10.0") projectPath = file("../../Robo") qtKitDir = file(autoTargetDirPath) }

 
you need to clean build and resync before switching kit dirs, but that exists anyway.
not sure I like using the kit variable, and there is unused code in there, and the root qt location is hardcoded, but yeh. 

Demarcation - what this is not?

 

Dependencies - what does this need?

• This work needs to cover QTTA-262 - if not then the bug needs to be re-opened and done for QtGP 1.4
• Does this depends on QTTA-108 ? Like QTTA-297 does.
•