JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

ConversionForegroundType's API 33 and 34 arms are cold, and the legs that would cover them are the ones #122 wedges #167

New Issue
Closed
opened 2026-09-02 02:14:44 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-09-02 02:14:44 +00:00 (Migrated from github.com)
Copy Link
Copy Source

The two regimes only the emulator can currently answer for

ConversionForegroundType.current() (app/src/main/java/org/libremediaconverter/work/ConversionForegroundType.kt:32-40)
has three arms, one per API regime. JaCoCo on main at d354f64: 3 lines missed, 3 of 4
branches missed.

The cause is structural, not an oversight. app/src/test/resources/robolectric.properties pins the
whole JVM suite to sdk=36, and grep -rn '@Config' app/src/test returns nothing but a comment in
that same properties file. So every Robolectric test that builds a ForegroundInfo takes the
MEDIA_PROCESSING arm and no other.

Why the instrumented test is not enough

ConversionWorkerTest.foregroundTypeMatchesTheRunningApiLevel
(app/src/androidTest/java/org/libremediaconverter/work/ConversionWorkerTest.kt:63-72) asserts
against whatever API the leg happens to be — one arm per leg, never the other two. And the legs
that would cover 33 and 34 are the ones #122 wedges: docs/coverage-read-findings.md records a run
where the API 33 leg reported received: 60 but failed: unknown, so it could not have reported a
failure if there had been one.

docs/coverage-read-findings.md already recommends exactly this test, in its "Not covered here"
section: "A @Config(sdk = 33) / @Config(sdk = 34) JVM test would pin all three arms
deterministically in one run for about three lines. Small, and worth doing the next time this file
is opened." This is that.

The work

New file app/src/test/java/org/libremediaconverter/work/ForegroundTypeRegimeTest.kt — three
classes (or one outer with three @Config-annotated nested runners) at @Config(sdk = 33),
@Config(sdk = 34) and @Config(sdk = 36), asserting 0, FOREGROUND_SERVICE_TYPE_DATA_SYNC and
FOREGROUND_SERVICE_TYPE_MEDIA_PROCESSING respectively.

minSdk is 33, so all three are live production paths, not dead code.

Acceptance: the mutation that must go red

Change >= Build.VERSION_CODES.VANILLA_ICE_CREAM to >, or swap the DATA_SYNC and
MEDIA_PROCESSING results. Either must fail. Restore, confirm green.

## The two regimes only the emulator can currently answer for `ConversionForegroundType.current()` (`app/src/main/java/org/libremediaconverter/work/ConversionForegroundType.kt:32-40`) has three arms, one per API regime. JaCoCo on `main` at `d354f64`: **3 lines missed, 3 of 4 branches missed**. The cause is structural, not an oversight. `app/src/test/resources/robolectric.properties` pins the whole JVM suite to `sdk=36`, and `grep -rn '@Config' app/src/test` returns nothing but a comment in that same properties file. So every Robolectric test that builds a `ForegroundInfo` takes the `MEDIA_PROCESSING` arm and no other. ## Why the instrumented test is not enough `ConversionWorkerTest.foregroundTypeMatchesTheRunningApiLevel` (`app/src/androidTest/java/org/libremediaconverter/work/ConversionWorkerTest.kt:63-72`) asserts against whatever API the leg happens to be — one arm per leg, never the other two. And the legs that would cover 33 and 34 are the ones #122 wedges: `docs/coverage-read-findings.md` records a run where the API 33 leg reported `received: 60` but `failed: unknown`, so it could not have reported a failure if there had been one. `docs/coverage-read-findings.md` already recommends exactly this test, in its "Not covered here" section: *"A `@Config(sdk = 33)` / `@Config(sdk = 34)` JVM test would pin all three arms deterministically in one run for about three lines. Small, and worth doing the next time this file is opened."* This is that. ## The work New file `app/src/test/java/org/libremediaconverter/work/ForegroundTypeRegimeTest.kt` — three classes (or one outer with three `@Config`-annotated nested runners) at `@Config(sdk = 33)`, `@Config(sdk = 34)` and `@Config(sdk = 36)`, asserting `0`, `FOREGROUND_SERVICE_TYPE_DATA_SYNC` and `FOREGROUND_SERVICE_TYPE_MEDIA_PROCESSING` respectively. `minSdk` is 33, so all three are live production paths, not dead code. ## Acceptance: the mutation that must go red Change `>= Build.VERSION_CODES.VANILLA_ICE_CREAM` to `>`, **or** swap the `DATA_SYNC` and `MEDIA_PROCESSING` results. Either must fail. Restore, confirm green.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#167