[android] Update internal documentation on CoreCLR on Android experimental support #112034
Conversation
|
After discussion with @janvorli, we agreed to remove the outdated Linux documentation and to refer to MacOS one. |
| 2. In Windows, create and start an emulator | ||
| 3. In WSL, swap the `adb` from the Android SDK in WSL2 with that from Windows | ||
| - `mv $ANDROID_SDK_ROOT/platform-tools/adb $ANDROID_SDK_ROOT/platform-tools/adb-orig` | ||
| - `ln -s /mnt/<path-to-adb-on-host> $ANDROID_SDK_ROOT/platform-tools/adb` |
There was a problem hiding this comment.
do you really need to symlink or would it be enough to set xharness ADB_EXE_PATH to /mnt/<path-to-adb-on-host> ?
There was a problem hiding this comment.
I had to symlink it somewhere. It didn't necessarily need to be the path from the Android SDK in WSL2, but I found that convenient for just using adb from the command line in WSL.
When I directly set ADB_EXE_PATH=/mnt/<path-to-adb-on-host>, running with xharness would fail with:
Exit code: 1
Std out:
Performing Streamed Install
Std err:
adb: failed to stat /home/elinor/runtime/artifacts/bin/AndroidSampleApp/x64/Release/android-x64/Bundle//bin/HelloAndroid.apk: No such file or directory
I admittedly didn't really spend time looking into why.
Directly running /mnt/<path-to-adb-on-host> install <path-to-apk-in-wsl> from my WSL terminal works fine, so I guess it may be something with how it gets launched with xharness?
|
@kotlarmilos could you include a note about the problem you were having with |
|
/ba-g wasm jobs not affected |
Description
This pull request updates the internal documentation with instructions for:
This is intended for developers working on CoreCLR's support for Android.
NOTE: As the support is experimental, the documentation covers only currently supported scenarios, and will be updated in the future as we expand our support.
Fixes #111955