[native_toolchain_c] Consider `ANDROID_HOME` environment variable

[simolus3]

When searching for an NDK, this now considers:

• $ANDROID_HOME/ndk/*/ directories.
• If the environment variables ANDROID_NDK, ANROID_NDK_HOME, ANDROID_NDK_LATEST_HOME or ANDROID_NDK_ROOT are set (as they are in GitHub actions), those directories.

To make this testable (it's kind of odd there's no way to patch Platform.environment with IOOverrides), this replaces the logger passed to tool resolvers with a ToolResolvingContext class that allows mocking environment variables (well, kind of. Most resolvers shell out and we can't mock that yet).

Closes https://github.com/dart-lang/native/issues/2632.

[github-actions[bot]]

PR Health

License Headers :heavy_check_mark:

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/hooks_runner/test_data/download_assets/hook/build.dart
pkgs/objective_c/example/command_line/lib/main.dart
pkgs/objective_c/lib/src/ns_input_stream.dart

This check can be disabled by tagging the PR with skip-license-check.

API leaks :heavy_check_mark:

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbol	Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

Breaking changes :heavy_check_mark:

Package	Change	Current Version	New Version	Needed Version	Looking good?
hooks_runner	None	1.0.1	1.0.2-wip	1.0.1	:heavy_check_mark:
native_toolchain_c	None	0.17.4	0.17.5-wip	0.17.4	:heavy_check_mark:

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry :heavy_check_mark:

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

[simolus3]

It looks like the failing health checks may be an analyzer issue? Or at least I don't understand how these changes could cause the error from the logs.

[dcharkes]

It looks like the failing health checks may be an analyzer issue? Or at least I don't understand how these changes could cause the error from the logs.

I have filed https://github.com/dart-lang/sdk/issues/61870. We're not using any dot-shorthands in the code yet, so it's kinda weird.

The new tests fail on Windows, backslashes. 🙃

[simolus3]

I believe the Linux tests are failing here because we arbitrarily pick one tool out of the list returned (CompilerResolver._tryLoadToolFromNativeToolchain picks the first). So now that we find additional NDK installations, we also find outdated ones which don't generate 16KB-aligned ELF segments, which then causes test failures.

I'm not sure what the best way to fix this would be, should _AndroidNdkResolver sort NDKs by descending version number?

[dcharkes]

I believe the Linux tests are failing here because we arbitrarily pick one tool out of the list returned (CompilerResolver._tryLoadToolFromNativeToolchain picks the first). So now that we find additional NDK installations, we also find outdated ones which don't generate 16KB-aligned ELF segments, which then causes test failures.

I'm not sure what the best way to fix this would be, should _AndroidNdkResolver sort NDKs by descending version number?

Yeah that seems reasonable.

Why is the order arbitrary? I believe we should avoid this, I'd like the resolvers to have deterministic behavior. If we do file listing, we should order alphabetically (or descending if we want newest). And if we have async code we should not call .add in racy ways but rather merge lists in a predictable order.

[simolus3]

Sorry, I meant arbitrary in the sense that we pick the first one instead of one that might make more sense semantically :D I don't think there's a race here, but I'll check versions to use the latest NDK consistently.