Skip to content

chore: [ANDROAPP-7745] drop redundant testOptions.targetSdk from library modules - #5028

Draft
andresmr wants to merge 1 commit into
developfrom
chore/remove-library-testoptions-targetsdk
Draft

andresmr wants to merge 1 commit into
developfrom
chore/remove-library-testoptions-targetsdk

Conversation

@andresmr

@andresmr andresmr commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Jira: ANDROAPP-7745

Why

Six library modules set testOptions.targetSdk inside their defaultConfig block:

defaultConfig {
    minSdk = libs.versions.minSdk.get().toInt()
    testOptions.targetSdk = libs.versions.sdk.get().toInt()   // not a defaultConfig property

Two problems with that.

It isn't a defaultConfig property. It resolves to android.testOptions.targetSdk through the enclosing android { } scope, so the code reads as though library modules have a defaultConfig targetSdk. They don't — AGP removed it because the consuming app's targetSdk governs. Confirmed: the library merged manifests carry only android:minSdkVersion="23", no targetSdkVersion at all. It dates from 1f5681b35 ("Update gradle and kotlin version"), so it looks like a mechanical fix when AGP deprecated defaultConfig.targetSdk for libraries.

It's redundant and inconsistent. The property only ever reaches instrumented-test manifests — across the whole build output it materialises in exactly one file, form/build/intermediates/packaged_manifests/debugAndroidTest/.../AndroidManifest.xml. Nothing shipped is affected. And six other Android modules already omit it entirely and build and test fine: aggregates, commonskmm, dhis2-mobile-program-rules, login, sync, tracker.

Behaviour

Removing the property lets the value fall back to AGP's default, which follows compileSdk.

On develop that is a genuine no-op, because compileSdk and targetSdk are both 36 — verified by rebuilding and re-reading the manifest, which still resolves to targetSdkVersion="36".

Note

This stops being a no-op once #5019 lands. That PR splits compileSdk (37) from targetSdk (36), so instrumented-test targetSdk would then follow compileSdk and read 37 rather than 36. Only form and commons have instrumented tests, so the blast radius is small — but it's a real consequence and reviewers should decide whether they're happy with instrumented tests running at the compile level. If not, the alternative is to keep the property and merely move it out of defaultConfig into a proper testOptions { } block.

Verification

  • ./gradlew ktlintCheck
  • ./gradlew testDebugUnitTest testDhis2DebugUnitTest testAndroidHostTest
  • ./gradlew :app:assembleDhis2Debug :app:assembleDhis2DebugAndroidTest :form:assembleAndroidTest ✅ — the build-test-apks task list, included deliberately because this change affects androidTest manifests
  • form's debugAndroidTest manifest still resolves to targetSdkVersion="36"

6 files, 6 deletions, one line each.

…ary modules

Library modules have no production targetSdk - AGP removed it because the
consuming app's targetSdk governs - and their merged manifests carry only
minSdkVersion. These six lines therefore only ever affected instrumented-test
manifests, and six other Android modules (aggregates, commonskmm,
dhis2-mobile-program-rules, login, sync, tracker) already omit the property,
so the codebase was inconsistent.

They were also written inside defaultConfig { } while actually setting
android.testOptions.targetSdk through the enclosing android { } scope, which
read as though library modules had a defaultConfig targetSdk.

Removing them lets the value fall back to AGP's default, which follows
compileSdk. Verified behaviour-neutral here: form's debugAndroidTest manifest
still resolves to targetSdkVersion=36.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@andresmr
andresmr force-pushed the chore/remove-library-testoptions-targetsdk branch from f844088 to 01b7740 Compare August 7, 2026 14:23
@andresmr andresmr changed the title chore: drop redundant testOptions.targetSdk from library modules chore: [ANDROAPP-7745] drop redundant testOptions.targetSdk from library modules Aug 7, 2026
@sonarqubecloud

sonarqubecloud Bot commented Aug 7, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant