Dashboard: Offer the metadata-only device report only where it names something - #44
Merged
Conversation
…something The unsupported-device card's "Just send device info" button opens a prefilled public issue carrying non-privileged device metadata, needing no Shizuku. It is the right path when the metadata identifies a family: for a Samsung on an unverified One UI it states the skin, the ROM version and which keys are present, which is exactly what widening a gate needs. On a device where every probe came back empty it names nothing. The report then says only that none of the known families matched, which is not actionable, and a public issue is the most expensive place to learn it. The wizard's own delivery already refuses reports carrying no setting, but that gate never covered this second, unprivileged path. The button is now gated on the metadata carrying a lead. That is wider than "an adapter matched", because the family matchers are manufacturer lists and property checks: a rebranded Oplus device or a LineageOS derivative shipping the settings provider without the Lineage property reaches the registry's catch-all while still carrying a real signal, so a ROM marker or a present protection key counts on its own. Without a lead the card keeps the wizard, which can still discover a key Amply does not know, and email, where a dead end costs one reply instead of a public issue. adapterMatched is derived from the selected adapter rather than mirrored onto the state: the registry returns an adapter exactly when a probe matched, so a second field could only drift.
d4rken
added
bug
d4rken
added a commit
that referenced
this pull request
Aug 3, 2026
#44 landed on the same three files with a related change: the metadata-only report is now gated on ChargingState.hasSupportLead. The two interact. #44's fallback without a lead is "the card keeps the wizard", and this branch withholds the wizard on LineageOS — together those could have left that card with no contribution path at all. They do not: hasSupportLead includes adapterMatched (the Lineage lab adapter matches once detection works) and hasLineageSettingsProvider (verified present on oriole), so the metadata path stays offered while the wizard is withheld. Documented on the parameter, with a preview for that combination since neither existing preview rendered it. Also corrected hasSupportLead itself: it counted `device.lineageOsVersion != null` as a lead, which is dead on every real LineageOS build for exactly the reason this branch exists. Now isLineageOs.
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
1 participant
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.
What changed
The unsupported-device card offered two ways to contribute: the guided wizard, and a "Just send device info" button that opens a prefilled public issue with the device's non-privileged details and needs no Shizuku.
That second button is now shown only when those details actually name something — a known manufacturer family, a ROM marker, or a battery-protection setting the app could see. On a phone where none of that is present, the report would say nothing beyond "this isn't one of the families I know", which can't be acted on, so the card offers the guided wizard (which can still discover a setting the app doesn't know yet) and email instead.
Closes the gap behind #42.
Technical Context
Why this path was open. #36 gated the wizard's delivery on a report carrying at least one setting. Issue #42 came from the other entry point —
UnsupportedDeviceCard's secondary button →DeviceSupportReporter→ prefilledissues/newURL — which is metadata-only by design and had no such gate.AdapterRegistry.select()'s catch-all setscontributionWanted = truefor any unmatched device, so the card appears identically for a Samsung on an unverified One UI (report is actionable) and for stock-Android hardware with no protection feature at all (report is not).Why the predicate is wider than
matched. The first cut gated on the adapter having matched. That both under- and over-shoots: lab adapters match on manufacturer or a single ROM property, so a rebranded Oplus device withoplusRomVersionset, or a LineageOS derivative that ships thelineagesettingsprovider withoutro.lineage.build.version, lands in the catch-all while still carrying a real lead.ChargingState.hasSupportLeadtherefore ORs the matched adapter with the marker/key probes themselves. Its truth table is pinned inChargingStateSupportLeadTest.No new state field.
adapterMatchedis a computedadapterId != nullrather than a value mirrored fromAdapterSupport.matched— the registry returns an adapter exactly when a probe matched and its catch-all is the only null-adapter selection, so a carried flag could only drift. The unsupported dashboard preview gains theadapterIdthat itscontributionWanted = truealways implied.Unchanged: the report format and
DeviceSupportReporteritself, the wizard, the email path (a non-actionable report there costs one private reply, not a permanent public issue), and per-row disclosure.Review guidance: the interesting file is
ChargingRepository.kt(the predicate + its rationale); the Compose change is a visibility gate on the button and its dialog.Verification
testFossDebugUnitTest(797 pass, incl. 10 new across the two suites),assembleGplayDebug,lintVitalFossRelease— all green locally. Reviewed by Codex; its findings on the predicate's width, the ungated dialog, the redundant state field, and an overclaiming KDoc are folded into this commit. Not device-tested: the change is UI visibility driven by pure state, covered by the Robolectric card tests.