Repository navigation
fix(android): fehlende DeviceRegistryDao-Overrides in den drei Test-Fakes nachziehen - #828
Merged
ryanbr merged 1 commit intoJul 26, 2026
Conversation
…ree fake test doubles A prior PR added the ryanbr#771 adopt-serial re-key methods plus pairedDevice(id) and deletePairedDeviceRow(id) to DeviceRegistryDao but never updated the three in-memory fakes (DeviceRegistryTest, SourceCoordinatorAdoptionTest, RegistryDayOwnerSourceTest), leaving them non-abstract classes with unimplemented abstract members. Since Kotlin compiles a source set as one unit, this broke compileFullDebugUnitTestKotlin for the whole app module, blocking every Android unit test locally regardless of what's being worked on. reKeyDayOwnership actually re-keys the fake's owners map (the one table these fakes model with real state); the other reKey* methods are no-ops, matching the existing delete*For no-op pattern for tables these fakes don't model.
ryanbr
approved these changes
Jul 26, 2026
ryanbr
left a comment
ryanbr
left a comment
Owner
There was a problem hiding this comment.
Verified independently rather than taking the build claim: DeviceRegistryDao declares 64 suspend funs, and after this PR all three fakes override all 64, none missing. The test source set compiles as a unit, so this genuinely unblocks the whole Android suite — several PRs today have been unable to run Android tests.
reKeyDayOwnership is the only non-no-op and its semantics are right. I checked whether the fake diverges from the real UPDATE OR IGNORE ... SET deviceId: dayOwnership's PK is day alone, so the update can never hit a key collision and OR IGNORE is a no-op safeguard there. The fake's LinkedHashMap<day, row> models the table exactly. Replacing a value for an existing key during iteration is also safe — no structural modification, no CME.
Test-only, no production logic. Approving.
Note for the maintainer: this supersedes #725, which implements setModel — already present in all three fakes on main, so that PR is now a no-op. Worth closing with a pointer here.
ryanbr
marked this pull request as ready for review
July 26, 2026 22:33
This was referenced Jul 26, 2026
ryanbr
pushed a commit
that referenced
this pull request
Jul 27, 2026
…on passes off-Linux (#854) com.android.tools.build:aapt2 is published as one jar per host OS, and Gradle resolves only the variant matching the machine it runs on, so --write-verification-metadata can only ever record the host it ran on. verification-metadata.xml (#683) was generated on the Linux CI runner, so it pinned -linux.jar and nothing else and every macOS build died at :app:processFullDebugResources. That blocked the Android module outright on a Mac: compileFullDebugKotlin and testFullDebugUnitTest both failed before running, so the Kotlin half of the parity contract could not be verified locally at all. android.yml is disabled by default, so nothing caught it and the error pointed at a Gradle troubleshooting page rather than the cause. Adds the -osx variant additively; the -linux pin is untouched (0 deletions). aapt2 is the only platform-classified artifact in the file, so this is the complete fix rather than the first of several. Placed between -linux.jar and .pom, Gradle own sort order, so a later regeneration will not churn the diff. Checksum verified independently before merge, which matters for a trust file: Google published sha256 for aapt2-8.5.2-11315950-osx.jar is fbcece1a...ff212f, matching the value added here. The control is what makes that trustworthy — the same procedure against -linux.jar returns d8cfecdc...021edb, byte-identical to the pin already committed in this repo, so the method reproduces a value the project already trusts. Deliberately NOT taken from Gradle failure report: that value is precisely what verification is challenging. -windows is left out on purpose. It could not be tested, and pinning an unverified checksum into a trust file would undercut the point of the file. The README subsection earns its place: without it this reads as a violation of the existing "never hand-edit verification-metadata.xml" rule, when it is in fact the one case where hand-editing is correct — the checksum is still verified from the publisher first. Cannot affect Linux CI: a Linux runner never requests the -osx classifier. Together with #828 (the missing DeviceRegistryDao fake overrides, merged earlier today) this restores local Android testing on macOS. Those were the two independent causes.
4 of 5 tasks
simoncad7
pushed a commit
to simoncad7/noop
that referenced
this pull request
Aug 17, 2026
…e test fakes (ryanbr#828) The Android test source set did not compile. DeviceRegistryDao declares the reKey* family (ryanbr#771 adopt-serial), pairedDevice(id) and deletePairedDeviceRow(id), but three standalone in-memory fakes were never updated: DeviceRegistryTest.FakeRegistryDao SourceCoordinatorAdoptionTest.FakeRegistryDao RegistryDayOwnerSourceTest.FakeDao Kotlin compiles a source set as one unit, so this blocked the ENTIRE Android unit-test tree, not just these three classes — no Android test could run locally at all, whatever it covered. Several PRs open today could not tick their Android-test box because of it. Verified independently rather than on the build claim, and re-verified at the merged head: DeviceRegistryDao declares 64 suspend funs and all three fakes override all 64, none missing. reKeyDayOwnership is the only non-no-op and its semantics are correct. dayOwnership's primary key is `day` alone, so UPDATE OR IGNORE ... SET deviceId can never hit a key collision and the OR IGNORE is a no-op safeguard there; the fake's LinkedHashMap<day, row> models the table exactly. Replacing a value for an existing key mid-iteration is safe — value replacement is not a structural modification. The remaining reKey* overrides are no-ops, matching the existing delete*For pattern for tables these fakes do not model. Test-only, pure additions, no production logic touched. Supersedes ryanbr#725, which implements setModel — already present in all three fakes on main.
simoncad7
pushed a commit
to simoncad7/noop
that referenced
this pull request
Aug 17, 2026
…on passes off-Linux (ryanbr#854) com.android.tools.build:aapt2 is published as one jar per host OS, and Gradle resolves only the variant matching the machine it runs on, so --write-verification-metadata can only ever record the host it ran on. verification-metadata.xml (ryanbr#683) was generated on the Linux CI runner, so it pinned -linux.jar and nothing else and every macOS build died at :app:processFullDebugResources. That blocked the Android module outright on a Mac: compileFullDebugKotlin and testFullDebugUnitTest both failed before running, so the Kotlin half of the parity contract could not be verified locally at all. android.yml is disabled by default, so nothing caught it and the error pointed at a Gradle troubleshooting page rather than the cause. Adds the -osx variant additively; the -linux pin is untouched (0 deletions). aapt2 is the only platform-classified artifact in the file, so this is the complete fix rather than the first of several. Placed between -linux.jar and .pom, Gradle own sort order, so a later regeneration will not churn the diff. Checksum verified independently before merge, which matters for a trust file: Google published sha256 for aapt2-8.5.2-11315950-osx.jar is fbcece1a...ff212f, matching the value added here. The control is what makes that trustworthy — the same procedure against -linux.jar returns d8cfecdc...021edb, byte-identical to the pin already committed in this repo, so the method reproduces a value the project already trusts. Deliberately NOT taken from Gradle failure report: that value is precisely what verification is challenging. -windows is left out on purpose. It could not be tested, and pinning an unverified checksum into a trust file would undercut the point of the file. The README subsection earns its place: without it this reads as a violation of the existing "never hand-edit verification-metadata.xml" rule, when it is in fact the one case where hand-editing is correct — the checksum is still verified from the publisher first. Cannot affect Linux CI: a Linux runner never requests the -osx classifier. Together with ryanbr#828 (the missing DeviceRegistryDao fake overrides, merged earlier today) this restores local Android testing on macOS. Those were the two independent causes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Zusammenfassung
./gradlew testFullDebugUnitTest(bzw.compileFullDebugUnitTestKotlin) schlägt aktuell unabhängigvon jeder Feature-Arbeit fehl — reiner Compile-Fehler im Test-Source-Set.
DeviceRegistryDaodeklariert die komplette
reKey*-Familie (#771 adopt-serial),pairedDevice(id)unddeletePairedDeviceRow(id), aber drei eigenständige In-Memory-Fakes wurden nie nachgezogen:android/app/src/test/java/com/noop/data/DeviceRegistryTest.kt(FakeRegistryDao)android/app/src/test/java/com/noop/ble/SourceCoordinatorAdoptionTest.kt(FakeRegistryDao)android/app/src/test/java/com/noop/analytics/RegistryDayOwnerSourceTest.kt(FakeDao)Da Kotlin ein Source-Set als eine Einheit kompiliert, hat das den gesamten Testbaum blockiert —
lokal ließ sich kein einziger Android-Unit-Test mehr ausführen, unabhängig vom Thema.
Änderung
Alle drei Fakes um die fehlenden Overrides ergänzt:
reKeyDayOwnershipre-keyed tatsächlich dieowners-Map (die einzige Tabelle, die diese Fakes mitechtem State abbilden) — Parität zum echten DAO-Semantik
UPDATE ... SET deviceId = :to WHERE deviceId = :from.reKey*-Methoden sind No-Ops, analog zum bestehenden Muster derdelete*For-No-Ops fürTabellen, die diese Fakes nicht modellieren.
pairedDevice(id)liest aus der bestehendendevices-Map.deletePairedDeviceRow(id)entfernt ausdevices;deleteDeviceRow(id)ist ein No-Op (keineseparate
device-Tabelle in den Fakes modelliert).Reiner Test-Code, keine Produktionslogik geändert.
Test plan
cd android && ./gradlew compileFullDebugUnitTestKotlin— kompiliert jetzt sauber(
--dependency-verification=lenientwegen einer separaten, unabhängigen aapt2-osx-Checksummen-Lückeauf macOS ARM in
gradle/verification-metadata.xml, nicht Teil dieses PRs)cd android && ./gradlew testFullDebugUnitTest— BUILD SUCCESSFUL