Google Play’s pre-launch report flagged the app: “Your app uses deprecated APIs or parameters for edge-to-edge” against release 1101 (1.0.1298).
MainActivity already called enableEdgeToEdge() (the correct,
modern androidx.activity API, added in fe94407db) with a
safeDrawingPadding() Box wrapping App() — the Compose-side
implementation was already correct. The flag traced instead to
androidApp’s dependency graph: the android version-catalog bundle
in gradle/libs.versions.toml pulled in com.google.android.material:material
and androidx.constraintlayout:constraintlayout — legacy XML View-system
libraries with zero call sites anywhere in androidApp/ or
composeApp/ (the app is 100% Compose; grep for
AppCompatActivity/com.google.android.material/
androidx.constraintlayout across both modules’ source and resources
returned nothing). dexdump on a built androidApp-debug.apk
confirmed real class references (Lcom/google/android/material/...,
Landroidx/constraintlayout/...) were present in classes.dex purely
because those libraries were declared, not because anything used them
— those libraries’ own compiled code calls the deprecated
Window#setStatusBarColor / Window#setNavigationBarColor /
Window#setDecorFitsSystemWindows APIs, which is exactly what Play’s
static scan flags. git log -S shows both entries have been in the
catalog since the earliest restructuring commit in this repo’s
history (aa7711e6e) — leftover from Android Studio’s default
“Empty Compose Activity” template, not a specific regression.
androidx.appcompat remains in the compiled APK as a legitimate
transitive dependency of koin-android (declared in that library’s
own POM) and is already at the latest stable release (1.7.1 — 1.8.0
is alpha-only). This is a widely reported upstream limitation, not
something fixable from this app (see dotnet/android#10304,
flutter/flutter#183372, dotnet/maui#26788) — Play’s scanner flags
library-internal deprecated calls even when the app never invokes
them directly.
androidx-material and androidx-constraintlayout (and
the now-fully-unused androidx-appcompat alias, since it’s no
longer declared directly and arrives transitively anyway) from the
android bundle and their [versions]/[libraries] entries in
gradle/libs.versions.toml.androidApp had no useJUnitPlatform() wired, so @Test methods
from org.junit.jupiter.api.Test were silently never discovered by
testDebugUnitTest (confirmed by a scratch probe test that failed
intentionally and produced “No tests found”). Added
testOptions.unitTests.all { it.useJUnitPlatform() } plus
testRuntimeOnly(libs.junit.launcher) /
testRuntimeOnly(libs.jupiter.engine) to
androidApp/build.gradle.kts so the regression test below (and any
future Jupiter test in this module) actually runs.androidApp/src/test/kotlin/krill/zone/EdgeToEdgeDependencyGuardTest.kt.dexdump (from $ANDROID_HOME/build-tools/<ver>/) on a built debug
APK is the fast way to confirm whether a suspected-unused Android
dependency actually contributes real class references to the
compiled output, versus a strings/grep false positive (Compose
Material3’s own icon classes contain substrings like
materialIcon/materialPath that collide with a naive text search
for “material”).testOptions.unitTests.all { it.useJUnitPlatform() }
wired up front, matching server/composeApp — otherwise
libs.bundles.test (Jupiter) silently no-ops.EdgeToEdgeDependencyGuardTest guards against re-adding either
legacy library and against the modern androidx.activity.EdgeToEdge
API disappearing from the classpath.