-
Notifications
You must be signed in to change notification settings - Fork 564
[build-tools] Bump Test emulator to use API 31 #5257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I found an old PR that did this: https://github.com/xamarin/xamarin-android/pull/4874/files Do we need these URLs, too? I'll rebase it. |
|
@jonathanpeppers this is a work in progress (forgot to make it draft), and yes I am changing those other files as well |
|
Fails to build: |
ecc14ad to
e6a4254
Compare
|
I fear/suspect that the API-30 emulator has moved where we expect our Consider Mono.Android_Tests > Possible Crash / Release. Check the actual logcat, and we see: The tests did finish; there is no crash. Checking Looks like we need to use some other mechanism to retrieve the |
|
@jonpryor yup I'm looking at just using the |
76e2b1b to
a0b6dc9
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
a0b6dc9 to
6a80790
Compare
|
Looks like we're not hitting breakpoints?! https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4279056&view=logs&j=bc770d6b-0ee0-5594-b22c-77e857541d93&t=ffd8a1cf-6dca-58c0-3f91-29722003ed50 |
6a80790 to
c85052f
Compare
c85052f to
93049e7
Compare
93049e7 to
f91680a
Compare
src/Xamarin.Android.NUnitLite/Gui/Instrumentations/TestSuiteInstrumentation.cs
Outdated
Show resolved
Hide resolved
tests/Xamarin.Forms-Performance-Integration/Droid/Properties/AndroidManifest.xml
Outdated
Show resolved
Hide resolved
fa2d459 to
50c8a77
Compare
8f84367 to
acaf5fe
Compare
ecd5649 to
f7219dd
Compare
jonathanpeppers
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good except for the 2 spots I found something.
...ools.BootstrapTasks/Xamarin.Android.Tools.BootstrapTasks/RunAndroidEmulatorCheckBootTimes.cs
Outdated
Show resolved
Hide resolved
63761e7 to
8234bed
Compare
c267f95 to
acd8864
Compare
...n.Android.Tools.BootstrapTasks/Xamarin.Android.Tools.BootstrapTasks/CreateAndroidEmulator.cs
Outdated
Show resolved
Hide resolved
...Android.Tools.BootstrapTasks/Xamarin.Android.Tools.BootstrapTasks/RunInstrumentationTests.cs
Show resolved
Hide resolved
|
What's doubly odd is that this isn't the first pid in the log file; above snippet is from pid 3686, but the first pid of consequence in the log file is pid 3546: …which finished successfully. I don't know where pid 3686 came from. Looks like pid 3546 is from the Thus, it looks like:
@grendello: this feels like something "weird" is going in when using all of (1) .NET 6, (2) the interpreter, and (3) an API-31 emulator target. Would you be able to investigate? |
acd8864 to
a6ccff3
Compare
|
I was able to reproduce this crash using Xamarin.Android from
xamarin-android/tests/Mono.Android-Tests/Runtime-Microsoft.Android.Sdk $ dotnet msbuild msbuild.binlog /v:diag |grep '^[ ]*/home.*native/libmono-android\.'|tr -d ' '|sort|uniq
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-arm/31.0.101-preview.11.117/runtimes/android-arm/native/libmono-android.debug.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-arm/31.0.101-preview.11.117/runtimes/android-arm/native/libmono-android.release.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-arm64/31.0.101-preview.11.117/runtimes/android-arm64/native/libmono-android.debug.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-arm64/31.0.101-preview.11.117/runtimes/android-arm64/native/libmono-android.release.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-x64/31.0.101-preview.11.117/runtimes/android-x64/native/libmono-android.debug.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-x64/31.0.101-preview.11.117/runtimes/android-x64/native/libmono-android.release.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-x86/31.0.101-preview.11.117/runtimes/android-x86/native/libmono-android.debug.so
~/android-toolchain/dotnet/packs/Microsoft.Android.Runtime.31.android-x86/31.0.101-preview.11.117/runtimes/android-x86/native/libmono-android.release.so
Perhaps the same situation happens on CI and we don't use what we just built, but something from the past packages? The problem is likely to be the fact that the runtimes from the API 31 packs were built against a different |
05cb0b1 to
c9896e5
Compare
032625c to
e2bb779
Compare
ae56ed2 to
9de878a
Compare
|
@jonpryor This Nightly build is green https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5736992&view=results |
1fbda49 to
b012cc5
Compare
We need to be able to test our build system against newer emulators.
Include both API-30 and API-31 -based emulator images into our
nightly test pipeline `azure-pipelines-nightly.yaml`.
We will leave the normal CI tests running on API-29 for now as the
newer emulators seem to be reliable in a CI environment.
One of the changes is in the use of `Context.GetExternalFilesDir(null)`
to create a subdirectory within the external files directory. This is
due to [permissions changes which came into effect in API-30][0]:
> **Note**: On Android 11 (API level 30) and higher, apps cannot
> create their own app-specific directory on external storage.
As a result our previous code can no longer be used on newer devices.
We shall instead unify the tests to all use
`Context.GetExternalFilesDir(null)`, then use
`Context.FilesDir.AbsolutePath` as a backup.
The result of this change is we MUST use the `run-as` command to
retrieve the test log file for processing on API-30. This is because
the external directory is no longer readable globally on API-30; it
is only readable for the app. As a result we also need to make the
API-30 build of the test app "debuggable" via
`[Application (Debuggable=true)]`.
Thankfully this change was reverted somewhat in API-31, so we can
still `adb pull` from the directory returned by
`Context.GetExternalFilesDir(null);`.
Other changes include updating tests to include the `x86_64` abi.
This is because the newer x86_64 emulators no longer appear to be
able to run `x86` code.
[0]: https://developer.android.com/training/data-storage/app-specific#external-access-files |
70c7885 to
d6eec19
Compare
d6eec19 to
b6074ce
Compare
|
Nightly is also green https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5801345&view=results |
We need to be able to test our build system against newer emulators. So let's include both API 30 and API 30 based emulator images in our nightly tests.
We will leave the normal development tests running on API 29 for now as the newer emulators seem to be unreliable
in a CI environment.
Part of the changes in to use the
Context.GetExternalFilesDir (null);to get the external files directory. This is due to permissions changes which came into effect from API 30. As a result the older code which we used can no longer beused on newer devices. So we shall unify the tests to all use
Context.GetExternalFilesDir (null);. Then useContext.FilesDir.AbsolutePath;as a backup. The result of this change is we MUST use therun-ascommand to retrieve the test log file for processing on API 30. This is because the external directory is no longer readable globally on API 30. It is only readable for the app. As a result we also need to make the API 30 build of the test app debuggable via the[Application (Debuggable=true)]attribute.Thankfully this change was reverted somewhat in API 31, so we can still
adb pullfrom the directory returned byContext.GetExternalFilesDir (null);.Other changes include updating tests to include the
x86_64abi. This is because the newer x86_64 emulators no longer appear to be able to runx86code.