xbsheng
cff782b3de
print_report walks TITLES, which holds four categories - voice, acr, telemetry and the name-only group - while docs/privacy.md said the audit prints three groups, so a reader who ran it on a TV with name matches met a section the page never named (the one --include-low writes). The page also said nothing about the 25-package cap the audit reads dumpsys package under, which limits both the report and the list --write writes. Both are named, with what the cap means for a list. No tests: the checkers over these pages already pass, and the maintainer drops wording-pinning tests from docs PRs (as on #2480, #2491, #2497, #2504). No TV: a docs page read against the tool's own print_report.
2.3 KiB
The microphone, and what can be said about it
"Which of these packages is listening?" has no honest one-line answer, and a permission scan makes it worse:
- On many sets most packages run as
android.uid.system, so fifty of them showRECORD_AUDIO: granted=trueand none of them record anything. - On others the microphone is in the remote, not the panel, and a package with no audio permission at
all still sees everything on screen — ACR clients such as
tv.inscape.tvclient.inscapeacridentify content from the picture and need onlyINTERNET.
tools/privacy.py reports what the TV actually says instead of guessing:
TV_HOST=192.168.1.50 tools/venv/bin/python -I tools/privacy.py prints voice, ACR and telemetry
candidates in up to four groups — the three kinds it can name a job for, and a fourth headed
"Matched by name only, nothing else known" — each with:
- its evidence — named by the firmware's own
voice_interaction_service, a known component fromexamples/, or nothing but a matching name; - whether the package declares
RECORD_AUDIO, and whether it shares the system UID; - whether the returned AppOps history contains microphone access. A configured mode or a rejected attempt alone is not evidence of access.
--write privacy.txt turns the identified candidates into a normal debloat list, so applying it
and undoing it are the commands you already use (tools/disable.sh, tools/restore.sh). Packages
in that fourth group, the ones that only matched by name, stay out unless you pass --include-low;
they are the ones to check with dumpsys package <name> first.
The audit reads dumpsys package for at most 25 packages, so on a TV with a longer list of name
matches the report shows the first 25 and says how many it left out, and --write writes only
those: check the rest by hand.
What the audit cannot do is prove intent. appops shows an op was touched, not what happened to the
stream afterwards, and no scan of package names proves a TV is or is not recording. Disabling an
assistant is a trade you make with a specific loss (the remote's mic button, voice search inside
apps), which is why the report names that loss per package instead of calling it a win.