A service manager hands its process a scrubbed environment -- measured in
the Gentoo guest, an OpenRC user service gets 19 variables and neither
ANDROID_HOME nor ANDROID_NDK_HOME among them -- so the tool lookups have
to stand on their own. Two ways they did not:
- $ANDROID_HOME was taken as given. This machine exports a system-wide
/opt/android-sdk whose build-tools/36.0.0 holds nothing but
package.xml, so the download failed with "failed to spawn
.../zipalign", naming the tool rather than the root that was wrong.
Each lookup now takes the first candidate that actually contains what
it needs, and names every place it looked.
- The NDK search took the newest child of ~/Android and filtered it
afterwards, which can only reject that one directory. It worked by
the luck of `Sdk` sorting before `android-ndk-r27c`; a lowercase
neighbour would have hidden an NDK that was sitting right there.
newest_child_where filters before taking the max.
And the failure had nowhere to go: ApiError::Internal answered with an
empty body, so a missing NDK reached the phone as "Server returned HTTP
500" while the message naming the path stayed in a log on a machine the
person holding the phone cannot see. It now answers with the same
{err:#} chain it logs. Every route is behind the bearer token of a
device somebody enrolled themselves, so there is no third party to
withhold it from.
Diagnosis from the tdep-survey session, which measured the OpenRC
environment and the /opt/android-sdk contents.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
irisandClaude Opus 5
0e9c7842f7