Evidence levels
| Level | Meaning |
|---|---|
| Officially verified | Upstream documentation/source confirms a requirement or behavior; not a vehicle certification |
| Maintainer tested | Upstream maintainer explicitly reports a physical test, with stated scope |
| Community verified | Contributor provides an explicit test/build/feature result; final APK may differ |
| Community reported | An owner describes a result; not independently reproduced |
| Partial / known issues | A setup has partial behavior or a documented limitation |
| Untested | No reliable report for the requested combination |
| Unsupported | Outside upstream support policy or released APK minimum |
How the checker avoids guessing
Every supplied field must match to count as exact evidence. Null source values cannot confirm a specified year, Android, iPhone, iOS or firmware. OS patches, DiLink subversions and builds are not silently merged.
A confirmation requires sufficiently specified versions and successful explicit test evidence. Single user success remains limited evidence; failure stays a report for that combination. Conflicting success/failure results are shown together.
Related model or generation reports are separate and can guide testing only. Compatibility is not inferred from a chipset, brand, installation success or Bluetooth pairing.
What gets published
Only reviewed normalized records enter the public data. API synchronization writes candidates for human review and never turns issue bodies into articles. Sources/notes preserve test-build versus release-artifact limits.
A model page needs at least three independent identifiable reporters plus useful successful version/transport evidence. Multiple issues from one reporter are not multiple independent tests.