Charging: Detect LineageOS via the system feature, not a denied property

[d4rken]

What changed

Amply could not recognise LineageOS at all, so LineageOS phones were treated as if they were running their manufacturer's stock software. On a LineageOS Pixel that meant being told the 80% limit is "supported on Pixel 6a and newer phones", being sent to Battery Saver instead of the Battery screen that actually holds LineageOS's own Charging control, and never being offered the "help add support" card. Amply now recognises LineageOS and says the right things: it points at LineageOS's own charging control, and describes the device as a LineageOS device rather than a Google one.

For people who want to help add support, the LineageOS path is reworked. The guided step-by-step wizard is no longer offered there — on LineageOS it could never finish, because the settings it watches are not the ones LineageOS uses, so it always ended with nothing to send after several minutes of work. Instead the "send device info" report now includes which charge-control method the ROM uses, which is the useful part. Connecting Shizuku is offered directly on the card so that detail can be included; without it everything still works, the report just says "unknown".

No change for any other device. This does not make LineageOS charge control work — no LineageOS device is enabled by it.

Technical Context

Root cause. Every ro.lineage.* property is SELinux-labelled custom_version_prop, which untrusted_app cannot read, and SystemProperties.get returns an empty string on denial instead of throwing. So SystemPropertyReader's runCatching never fired, nothing was logged, LineageOsDetector.detect() returned null, and both Lineage adapters skipped their probe. getprop over adb had always masked this because it runs as the shell UID. Confirmed by avc: denied { read } … tcontext=u:object_r:custom_version_prop:s0 … app=eu.darken.amply.

Detection now keys on the org.lineageos.android system feature — app-readable with no <queries> entry and no permission, and declared upstream from LineageOS 15.1 through 23.2. lineageOsVersion stays as an OR-input (derivatives that relabel the property) and for diagnostics. Fingerprint sniffing is not an alternative: LineageOS spoofs Build.FINGERPRINT to stock (google/oriole/oriole:16/…/release-keys).

Why CI never caught it. AdapterRegistrySelectionTest injected lineageOsVersion straight into DeviceInfo, so every gate looked correct while the real read returned nothing. DeviceInfoLineageDetectionTest now drives DeviceInfo.current(context) against a real PackageManager through the registry.

The probe is an observation, not a verdict. Reviewing this twice produced two wrong inferences worth recording so they are not reintroduced:

• Provider selection branches on the configured mode before capability — MODE_AUTO/MANUAL return Deadline before Limit is consulted — so Deadline proves nothing.
• Toggle also accepts MODE_LIMIT and enforces targetPct itself by cutting charging, so binding it is a capable mechanism, not a rejection. isHALModeSupported additionally swallows RemoteException into false.

Hence LineageLimitMechanism has no negative case (NATIVE_LIMIT/FRAMEWORK_TOGGLE/NOT_OBSERVED/UNKNOWN), and a test enumerates the constants so one cannot be added back. Even NATIVE_LIMIT is not qualification — oriole bound Limit on LineageOS 20 and still charged past the cap.

Safety boundary. The new AIDL op takes no arguments: constant binary, constant argument, read-only, no write-allowlist involvement, nothing caller-supplied to validate. The raw dump is reduced to PROVIDER|mode inside the user service — it contains StartTime/TargetTime (the user's charging schedule, i.e. their sleep window) and battery level, which must not reach a public report. Reviewed by Codex over four passes; no injection path and no route by which raw text reaches the app process or a log.

Review guidance. Worth the closest look: the mechanism inference in LineageHealthProbe.kt against upstream ChargingControlController.getProviderForMode and Toggle.java; the guidedCaptureUseful gating (both entry points plus the destination, which waits on adapterResolved so a saved-state restore cannot flash the wizard on the permissive default); and the BackendStatus branching on the card, since requesting permission is a no-op while the Shizuku server is stopped.

Verified on Pixel 6 (oriole) / LineageOS 23.2 / Android 16. Adapter selection lineageos-lab; report reads is_lineageos=true, lineageos_version=none, lineage_cc_provider=DEADLINE, lineage_cc_mode=1, lineage_cc_limit_mechanism=NOT_OBSERVED; all fields degrade to unknown with Shizuku stopped, where the button correctly reads "Open Shizuku" and launches it. Lineage settings unchanged throughout; no crashes. The device itself remains NO-GO on both LineageOS builds — that verdict rests on the mode=3 write reading back as 1 and the LOS 20 charge-past observation, not on this probe.

Also fixed alongside: the contribution wizard's bottom bar had no navigation-bar inset and sat under the 3-button nav bar (~31px of Back/Next tappable), and the unsupported card interpolated Build.MANUFACTURER, telling a LineageOS Pixel user that "Google devices" are unmapped.