Repository: flutter
Issue: [infra] Android SDK+NDK CIPD packages should follow the standard directory structure.
Labels: platform-android,tool,P2,c: tech-debt,team-android,triaged-android,fyi-infra

TL;DR: The CI bots have the Android `sdk` and `ndk` folders as siblings, and set `ANDROID_SDK_ROOT` and `ANDROID_NDK_PATH`. An env-var for the NDK is non-standard, and the standard location of the `ndk` directory is nested inside the `sdk` directory. We should update our DEPS and scripts to do the same.

Long version:

The Android SDK & NDK are installed through a CIPD package: https://chrome-infra-packages.appspot.com/p/flutter/android/sdk/all
The directory structure inside the package (for every OS) is the `ndk` and `sdk` directories as siblings.

Our infra sets the `ANDROID_NDK_PATH` env var https://cs.opensource.google/flutter/recipes/+/main:recipe_modules/flutter_deps/api.py;l=341, and presumably we use this env var somewhere in our build (but I have not been able to find uses in flutter repos including the recipes).

When the Android SDK & NDK are installed on a users' machine through Android Studio or the SDK manager, the `sdk` directory contains the `ndk` directory. (Older SDK versions had an `ndk-bundle` directory.)

The official Android documentation makes no mention of using an environment variable for the NDK location: https://developer.android.com/studio/command-line/variables.html#envar

An online search reveals that project use conflicting env vars for the NDK: `ANDROID_NDK_PATH`, `ANDROID_NDK_HOME`, and `ANDROID_NDK_ROOT`. The latter seems the most common. But none of them is mentioned in the official Android documentation on recommendations.

https://github.com/flutter/flutter/pull/135148 adds logic for NDK discovery on top of the SDK discovery. Since there is no well defined env variable and the ndk is always nested as `ndk/` inside `sdk/` (old versions of the Android SDK can contain `ndk-bundle` instead of `ndk`), and we'd like to use an NDK belonging to the SDK we're using, we look for a nested `ndk` directory inside `sdk`.

This fails on our CI bots currently, because that `ndk/` directory is not there. Our script for making the CIPD package explicitly moves the `ndk` directory out of the `sdk` directory: 

```sh
  # Special treatment for NDK to move to expected directory.
  mv $upload_dir/sdk/ndk $upload_dir/ndk-bundle
  ndk_sub_paths=`find $upload_dir/ndk-bundle -maxdepth 1 -type d`
  ndk_sub_paths_arr=($ndk_sub_paths)
  mv ${ndk_sub_paths_arr[1]} $upload_dir/ndk
  rm -rf $upload_dir/ndk-bundle
```

https://github.com/flutter/engine/blob/c24f30343cf6506bda6a56b833e77461f299fd0c/tools/android_sdk/create_cipd_packages.sh#L118-L123

Changing the CIPD package to _not_ modify the directory structure makes the tests on the above mentioned PR pass ([log](https://logs.chromium.org/logs/flutter/led/godofredoc_google.com/0ee7e718653360504020ce3cc89cd1bd1a312acc8c5ab8a2fb87b008eca8bac5/+/u/run_test.dart_for_tool_integration_tests_shard_and_subshard_5_6/test_stdout)). ([log of failing tests](https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8767530688386819265/+/u/run_test.dart_for_tool_integration_tests_shard_and_subshard_5_6/test_stdout))

Changing the directory structure will likely require multiple changes:
* The recipes to set up `ANDROID_NDK_PATH` correctly again ([link](https://cs.opensource.google/flutter/recipes/+/main:recipe_modules/flutter_deps/api.py;l=341)).
* The script to make the CIPD package ([link](https://github.com/flutter/engine/blob/c24f30343cf6506bda6a56b833e77461f299fd0c/tools/android_sdk/create_cipd_packages.sh#L118-L123)).
* Stuff that pops up when trying to make this change.

Many thanks to @godofredoc for helping me triage this! 🙇 

@reidbaker Do you agree we should depend the `ndk` directory being inside the `sdk` directory in the discovery in `lib/src/android/android_sdk.dart` in https://github.com/flutter/flutter/pull/135148?

@GaryQian You have modified the mentioned lines in create_cipd_packages.sh. Would you happen to know why we have a non-standard directory structure? And any concerns about the above proposal?