fix(ci): Run the app module unit tests

[Dev-next-gen]

Fixes #2100

The last step of .github/workflows/android.yml runs:

- name: Run unit tests
  run: ./gradlew testDebugUnitTest --stacktrace

:app declares a distribution flavor dimension, so it has no task with that name:

$ ./gradlew :app:testDebugUnitTest --dry-run
Cannot locate tasks that match ':app:testDebugUnitTest' as task 'testDebugUnitTest'
is ambiguous in project ':app'. Candidates are: 'testFdroidDebugUnitTest',
'testPreprodDebugUnitTest', 'testStandardDebugUnitTest'.

Invoked from the root, the name is matched against every project of the build, and the only one that declares it is :Core:Legacy — which has no src/test directory at all. So the step currently does this:

$ ./gradlew testDebugUnitTest --stacktrace
> Task :Core:Legacy:testDebugUnitTest NO-SOURCE
BUILD SUCCESSFUL in 3m 37s

$ ls app/build/test-results
ls: cannot access 'app/build/test-results': No such file or directory

Zero tests executed, job green, no report produced. DeeplinkParserTest and RootFileTreeCategoryTest are never run by the PR check, and a unit test in app/ can break without the pipeline noticing.

With testStandardDebugUnitTest, same tree, same submodule commit:

$ ./gradlew testStandardDebugUnitTest --stacktrace
> Task :app:testStandardDebugUnitTest
RootFileTreeCategoryTest > checkOrdinalsAreStable() PASSED
DeeplinkParserTest > parse deeplink Collaborate() PASSED
DeeplinkParserTest > parse deeplink Office() PASSED
DeeplinkParserTest > parse deeplink Drive Favorites() PASSED
[... 16 DeeplinkParserTest cases, all PASSED ...]
BUILD SUCCESSFUL in 9m 20s

$ ls app/build/test-results/testStandardDebugUnitTest
TEST-com.infomaniak.drive.RootFileTreeCategoryTest.xml
TEST-com.infomaniak.drive.data.models.deeplink.DeeplinkParserTest.xml

17 tests run, all green, so this does not turn the pipeline red.

I picked standard because it is the flavor marked isDefault and because buildStandardDebug in the previous step already compiles that variant, so the extra CI time is mostly the test task itself. ./gradlew test — the command documented in AGENTS.md — would also work, but it additionally compiles the fdroid and preprod unit-test variants.

.github/copilot-instructions.md documents the same command as the one CI runs, so I updated it too.

Measured on Gradle 9.7.1 / JDK 21, Core at the submodule commit pinned on main.

Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.

Nothing this pipeline produces is submitted without human approval. The entire pull request — the code change, the documentation updates and this description — was reviewed by a human before the pipeline was allowed to submit it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Dev-next-gen]

The three red checks here do not come from this diff. In instrumentation-tests the step that fails is Build app, which the PR does not touch, and the only step it does change never ran at all:

$ gh api repos/Infomaniak/android-kDrive/actions/jobs/112806437992 --jq '.steps[]|"\(.name)\t\(.conclusion)"'
...
Clean gradle cache	success
Build app	failure
Run unit tests	skipped

Build app fails because a fork run receives no secrets: the job log prints SENTRY_AUTH_TOKEN: with an empty value, so Create test env writes sentryAuthToken= and ./gradlew buildFdroidRelease trips the guard at app/build.gradle.kts:132 — "The sentryAuthToken property in env.properties must be specified". assign-author and check (Dependent Issues) both stop on Resource not accessible by integration, and the same job log's GITHUB_TOKEN Permissions group lists Issues: read and PullRequests: read. I can't change any of those three from a fork. I could not show you the same job red on main for comparison, because android.yml triggers on pull_request only, so there is no base-branch run of it to link.

What I can add is that the defect is visible in your own CI, not just in the local run I quoted in the description. Run 37455922715 (fake-block-store, in-repo, 2026-10-06, green) ends its Run unit tests step with > Task :Core:Legacy:testDebugUnitTest NO-SOURCE then BUILD SUCCESSFUL in 3s, and grepping that job's full log for :app:test[A-Za-z]*UnitTest returns 0 matches — so no app unit test has been executed by that step on a passing run either.

Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.