Repository navigation
11407
A bug fix for the Superuser page.
What was wrong
On some devices nothing on that page could be authorized. Every switch did nothing at all — no error, no movement — and it depended on the device, so it could not be reproduced where it worked.
The report that came in carried the device's own listing of /data/adb/ap, and that showed why:
-rw------- 1 root root u:object_r:adb_data_file:s0 0 2026-09-16 21:11 package_config
The file was empty. The manager reads it strictly before rewriting it — deliberately, because rewriting a file it cannot read in full would drop the grants of the records it skipped — and an empty file has no first line, so it was turned away as having an invalid header.
The list itself is read leniently, which is why it went on rendering normally while every change to it was refused. And since the write that would have put a header in that file was the very thing being refused, the device stayed that way.
What changed
- An empty file is read as an empty configuration, which is what it is. The refusal still stands for a file whose header is not the one this version writes.
- A refusal now says so instead of doing nothing. An unreadable file, no root, or a lock that will not clear each produce a message naming the reason.
- The root escalation sat outside the error handling with its result discarded. It is inside it now, and its answer is checked.
- The configuration lock was taken without a timeout, which waits forever on a holder that never lets go. It gives up after five seconds and reports that too.
- Files carrying a byte-order mark, CRLF line endings or a blank first line are accepted. None of those changes what a record means, and each of them used to cost the whole file.
If you were affected
Your package_config was emptied at some point, so any grants made before that are gone and have to be made again.