Task names mismatched due to KMP & flavors

[opencode-agent]

Summary

Root cause: The CI commands used assembleDebugAndroidTest and connectedDebugAndroidTest — standard AGP naming patterns — but these only matched the :core module. Both :app and :shared were silently skipped because:

1. :shared uses KMP's withDeviceTestBuilder, which generates tasks named *AndroidDeviceTest (not *DebugAndroidTest). So connectedDebugAndroidTest never matched shared:connectedAndroidDeviceTest.

2. :app has product flavors (stable, unstable), so the variant-specific tasks are connectedStableDebugAndroidTest and connectedUnstableDebugAndroidTest. The generic connectedDebugAndroidTest doesn't aggregate them.

Changes made (2 files):

• .github/scripts/connected-android-test.sh: Replaced ./gradlew connectedDebugAndroidTest with explicit task names for all 4 variants across 3 modules. Also added core to the report archiving.

• .github/workflows/connected-android-test.yml: Replaced ./gradlew assembleDebugAndroidTest with explicit assembly tasks for all modules.

Verified: all test APKs compile successfully, and all connected test tasks resolve correctly in the dry-run.

Closes #48

opencode session  |  github run

[283375]

/opencode The check for API 24 failed with a long-lasting issue. Try to fetch the actions results directly. If cannot, here's the key logs:

xyz.sevive.arcaeaoffline.ui.components.DecimalStepperTextFieldTest > allows_negative_input[emulator-5554 - 7.0] FAILED 
	java.lang.IllegalStateException: No compose hierarchies found in the app. Possible reasons include: (1) the Activity that calls setContent did not launch; (2) setContent was not called; (3) setContent was called before the ComposeTestRule ran. If setContent is called by the Activity, make sure the Activity is launched after the ComposeTestRule runs
	at androidx.compose.ui.test.TestOwnerKt.getAllSemanticsNodes(TestOwner.kt:106)
Tests on emulator-5554 - 7.0 failed: There was 1 failure(s).

The tests was proved to be working on another simulator, so the problem should be inside the CI. Search Internet and codebase for the action step's precise behavior and locate the root cause. If the problem still exist after 5 fixing attempts, terminate the session and report the findings you've got.

Always try executing commands rather than thinking to confirm actual behaviors. Always refer to the latest codebase rather than recalling your memories.