Fixes: https://github.com/xamarin/xamarin-android/issues/8779
Updates all NuGet packages other than Microsoft.Android.Sdk to include
the MIT license at the root of the repo.
The license file name and contents have also been updated to improve
consistency with other dotnet repos.
Changes: d070660282...893b762b6e
Changes: 99b76018b6...5e603d595e
Changes: 2d3f1fe480...0f3e462442
Changes: 61250b0ed4...0d0bc8e0f4
Updates:
* Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.3.24126.2 to 9.0.100-preview.3.24153.2
* Microsoft.NETCore.App.Ref: from 9.0.0-preview.2.24123.1 to 9.0.0-preview.3.24129.2
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-preview.2.24121.1 to 9.0.0-preview.3.24126.1
* Microsoft.NET.ILLink.Tasks: from 9.0.0-preview.2.24123.1 to 9.0.0-preview.3.24129.2
* Microsoft.DotNet.Cecil: from 0.11.4-alpha.24119.1 to 0.11.4-alpha.24120.1
Fixes: https://github.com/xamarin/xamarin-android/issues/8740
There is a race condition in `AndroidMessageHandler` (see https://github.com/xamarin/xamarin-android/issues/8740#issuecomment-1960331579
for more information).
The solution is fairly simple: we should determine the decompression strategy only during the setup, when `AutomaticDecompression` is set.
We don't need to do any more work during the request.
To prevent changing the decompression strategy while there are requests mid-flight, the setter will only accept values until the first request
is sent. This is exactly what the `SocketsHttpHandler` does. I didn't want to touch any code unrelated to the race condition in this PR so if we
want to prevent other properties from being mutated while HTTP requests are being sent, we should do it in a follow-up PR.
The recent 1ES pipeline template migration added a new source code
analysis stage that is failing on PR builds from forks. We should be
able to fix this by skipping AzDO build tagging and monodroid scanning
for such builds.
The `@self` yaml template annotation only appears to be needed in the
pipeline file, and not in nested templates. This should fix potential
issues with other repos that use these templates.
Context: https://aka.ms/1espt
The build pipeline has been updated to extend the 1ES pipeline template,
which will keep the pipeline up to date with the latest compliance and
security requirements. Most compliance tasks and scans will now run
automatically as part of artifact upload steps. API Scan and policheck
scans against multiple languages are not supported and will continue to
run separately.
Context: https://github.com/xamarin/xamarin-android/issues/5652
Context: https://github.com/xamarin/xamarin-android/issues/8724
Context: https://github.com/xamarin/java.interop/issues/1165
Context: b8f6f8884a
Context: dc3dc3ccf28cdbe9f8c0a705400b83c11a85c81a980ccf2
Fix another set of trimmer warnings found via:
<IsTrimmable>true</IsTrimmable>
<EnableAotAnalyzer>true</EnableAotAnalyzer>
~~ JavaObjectExtensions ~~
`Extensions.JavaCast<T>()` now requires `PublicConstructors` and
`NonPublicConstructors` because `TypeManager.CreateProxy()` uses
`ConstructorInfo.Invoke()`. This change bubbles up to various other
types that have a `Find*ById<T>()` method:
* `Activity`
* `Dialog`
* `FragmentManager`
* `View`
* `Window`
`JavaObjectExtensions.GetInvokerType()` also has suppressions around
`Assembly.GetType()` and `Type.MakeGenericType()`. We track this for
the future at xamarin/xamarin-android#8724.
~~ AndroidRuntime ~~
Update `[DynamicallyAccessedMembers]` based on changes to
`RegisterNativeMembers` in xamarin/java.interop@b8f6f888.
~~ JNINativeWrapper ~~
`$(EnableAotAnalyzer)` found usage of `DynamicMethod`. Suppress for
now, as we track this for the future at xamarin/xamarin-android#8724.
~~ ResourceIdManager ~~
Usage of `Type.GetMethod ("UpdateIdValues")` leads to decoration of
`[ResourceDesignerAttribute]` with:
[DynamicallyAccessedMembers (DynamicallyAccessedMemberTypes.PublicMethods)]
public string FullName { get; set; }
I also had to suppress warnings around `Assembly.GetType()`.
This *should* be OK, as `Resource.designer.cs` is always in the
"root assembly" of Android application projects.
Additionally, this code should no longer be used in .NET 8+ apps;
see dc3ccf28.
~~ JavaProxyThrowable ~~
Suppress warning around `StackFrame.GetMethod()`; we already handle
`null` return values and exceptions. The existing code appears to be
"best effort" to provide additional stack trace information.
~~ TypeManager ~~
Suppress warning around a call to `Type.GetType()` with a string
passed in from Java. There is not much we can really do yet, except
rely on the `MarkJavaObjects` trimmer step.
Likely also a problem for the future:
* xamarin/java.interop#1165
* xamarin/xamarin-android#8724
~~ Impact on `.apk` size ~~
`BuildReleaseArm64XFormsDotNet.apkdesc` shows a ~33KB size increase
in the `.apk`. Much of this is attributable to changes from
dotnet/runtime (`System.Private.CoreLib.dll` is ~20KB larger).
Some of this is due to increases in the size of `classes*.dex`.
These changes are because more managed constructors are now preserved
by the trimmer, which causes more constructors to be emitted into the
Java Callable Wrappers.
Fixes: https://github.com/xamarin/xamarin-android/issues/8331
Context: https://github.com/xamarin/xamarin-android/pull/8569
Context: 25b360d579
Building for `net9.0-android33` would give a poor error message:
error NETSDK1181: Error getting pack version: Pack 'Microsoft.Android.Ref.33' was not present in workload manifests.
C:\Program Files\dotnet\sdk\8.0.100-preview.7.23376.3\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets
To solve this, you would either change 33 to 34, or just remove the number to rely on the default value.
To make this easier:
* Automatically switch to 34 if the user specifies 33 or less.
* Opt into `%(DefineConstantsOnly)=true` for API levels 21-33 (and not
the latest), which allows the .NET SDK to emit the *better* .NET SDK
error message instead.
So now users will get:
(_CheckForInvalidTargetPlatformVersion target) ->
dotnet/sdk/9.0.100-alpha.1.23628.5/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(243,5):
error NETSDK1140: 33.0 is not a valid TargetPlatformVersion for Android.
Valid versions include: 34.0
I added a test for this scenario.
Changes: 0a73f814e1...d070660282
Changes: dcc66a7ca2...99b76018b6
Changes: 258b51a8e5...2d3f1fe480
Updates:
* Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.2.24122.3 to 9.0.100-preview.3.24126.2
* Microsoft.NETCore.App.Ref: from 9.0.0-preview.2.24122.2 to 9.0.0-preview.2.24123.1
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-preview.2.24120.1 to 9.0.0-preview.2.24121.1
* Microsoft.NET.ILLink.Tasks: from 9.0.0-preview.2.24122.2 to 9.0.0-preview.2.24123.1
Other changes:
* [tests] ignore `IncrementalFastDeployment` for now
Context: https://github.com/NuGet/Home/issues/13269
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Context: https://github.com/xamarin/xamarin-android/issues/5652
Fixing the following trimmer warnings:
~~ TypeConverter ~~
Context: https://source.dot.net/#System.ComponentModel.TypeConverter/System/ComponentModel/TypeConverter.cs,226
src\Mono.Android\System.Drawing\SizeFConverter.cs(121,49): error IL2046:
Base member 'System.ComponentModel.TypeConverter.GetProperties(ITypeDescriptorContext, Object, Attribute[])' with 'RequiresUnreferencedCodeAttribute' has a derived member
'System.Drawing.SizeFConverter.GetProperties(ITypeDescriptorContext, Object, Attribute[])' without 'RequiresUnreferencedCodeAttribute'.
'RequiresUnreferencedCodeAttribute' annotations must match across all interface implementations or overrides.
Various `TypeConverter` implementations need to specify
`[RequiresUnreferencedCode]` to match the base type.
~~ ColorValueMarshaler & IJavaObjectValueMarshaler ~~
Context: 7d1e7057cf
From the trimmer warnings solved in `Java.Interop.dll`, we need to
bring these changes forward to any `*Marshaler` types.
~~ AndroidClientHandler ~~
'this' argument does not satisfy 'DynamicallyAccessedMemberTypes.NonPublicFields' in call to 'System.Type.GetField(String, BindingFlags)'.
The return value of method 'System.Collections.IEnumerator.Current.get' does not have matching annotations.
The source value must declare at least the same requirements as those declared on the target location it is assigned to.
This class had a loop that was not trimming safe:
for (var type = GetType (); type != null; type = type.BaseType) {
field = type.GetField (fieldName, BindingFlags.Instance | BindingFlags.NonPublic);
if (field != null)
break;
}
If we *look* at the actual base types of `AndroidClientHandler`, we
can simplify this loop to something that *is* trimming safe:
const BindingFlags flags = BindingFlags.Instance | BindingFlags.NonPublic;
FieldInfo? field = typeof (HttpClientHandler).GetField (fieldName, flags) ??
typeof (HttpMessageHandler).GetField (fieldName, flags);
There should be no need to iterate *beyond* `HttpMessageHandler`, the
code is looking for this field:
* 135fec006e/src/libraries/System.Net.Http/src/System/Net/Http/HttpClientHandler.AnyMobile.cs (L25)
As `AndroidClientHandler` is `[Obsolete]` and unlikely to have its
inheritance hierarchy changed, removing the loop is deemed safe.
Changes: fb7b9a4b9e...0a73f814e1
Changes: d40c654c27...dcc66a7ca2
Changes: 687be2a32a...258b51a8e5
Changes: b8c2293cd1...61250b0ed4
Updates:
* Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.2.24106.6 to 9.0.100-preview.2.24122.3
* Microsoft.NETCore.App.Ref: from 9.0.0-preview.2.24080.1 to 9.0.0-preview.2.24122.2
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-preview.2.24076.1 to 9.0.0-preview.2.24120.1
* Microsoft.NET.ILLink.Tasks: from 9.0.0-preview.2.24080.1 to 9.0.0-preview.2.24122.2
* Microsoft.DotNet.Cecil: from 0.11.4-alpha.24065.1 to 0.11.4-alpha.24119.1
Other changes:
* Move *ahead* to newest dotnet/runtime build.
Ran `darc update-dependencies --id 213925`, using build ID from:
https://maestro-prod.westus2.cloudapp.azure.com/3883/https:%2F%2Fgithub.com%2Fdotnet%2Fruntime/latest/graph
This picks up a fix for the AOT compiler:
8819b222b3
* Fix assertions in `BuildAotApplicationWithSpecialCharactersInProject` test cases
There are fixes in the AOT compiler to support special characters.
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
A new $(RunMAUITestJob) variable has been added to control execution of
the MAUI integration test job. The value of this variable defaults to
true and it provides an easy way to disable the job on servicing/older
branches if needed.
* Add a property required by #8478
Context: https://github.com/xamarin/xamarin-android/pull/8478
Context: https://github.com/xamarin/monodroid/pull/1393
Merging this no-op change will make it easier to orchestrate merging
of the two PRs above. It allows us to merge the `monodroid` one
before merging #8478 and prevents breaking of any other builds or
PRs in between merging of the two PRs.
* Don't require it yet
* Dummy change to kick-off the build
* Undo the former change
Fixes: https://github.com/dotnet/maui/issues/20752
Context: d1ba2ccdd1
Context: 34e98e2b65
Context: https://github.com/xamarin/xamarin-android/pull/8746
`dotnet build` (.NET Core) ignores assembly versions.
`msbuild.exe` (.NET Framework) does not.
Enter d1ba2ccd, which updates the `libZipSharp.dll` assembly version
from 3.0.0.0 to 3.1.1.0. However, this change only impacted
`Xamarin.Android.Build.Tasks.dll`:
% monodis --assemblyref bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/34.99.0/tools/Xamarin.Android.Build.Tasks.dll
…
11: Version=3.1.1.0
Name=libZipSharp
Flags=0x00000000
It did *not* impact `Microsoft.Android.Build.BaseTasks.dll`, as it
is built by `external/xamarin-android-tools` and was using a
`@(PackageReference)` for libZipSharp 3.0.0:
% monodis --assemblyref bin/Release/lib/packs/Microsoft.Android.Sdk.Darwin/34.99.0/tools/Microsoft.Android.Build.BaseTasks.dll
…
5: Version=3.0.0.0
Name=libZipSharp
Flags=0x00000000
The resulting NuGet package only contains *one* `libZipSharp.dll`,
the 3.1.1.0 version (what `Xamarin.Android.Build.Tasks.dll` refs).
On PR builds and CI, everything was fine, because all the tests we
have use `dotnet build`, and .NET Core ignores assembly versions.
However, if you use *`msbuild.exe`* to invoke the tasks within
`Microsoft.Android.Build.BaseTasks.dll`, things fail:
XARLP7028 System.IO.FileNotFoundException: Could not load file or assembly 'libZipSharp, Version=3.0.0.0, Culture=neutral, PublicKeyToken=276db85bc4e20efc' or one of its dependencies.
The system cannot find the file specified.File name: 'libZipSharp, Version=3.0.0.0, Culture=neutral, PublicKeyToken=276db85bc4e20efc'
at Xamarin.Android.Tasks.ResolveLibraryProjectImports.Extract(IDictionary`2 jars, ICollection`1 resolvedResourceDirectories, ICollection`1 resolvedAssetDirectories, ICollection`1 resolvedEnvironments, ICollection`1 proguardConfigFiles)
at Xamarin.Android.Tasks.ResolveLibraryProjectImports.RunTask()
at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 25
Fix this by adding an `external/xamarin-android-tools.override.props`
file (xamarin/xamarin-android-tools@34e98e2b) which imports
`Directory.Build.props`, which causes `$(LibZipSharpVersion)` to be
set so that the xamarin-android-tools build uses values provided by
xamarin-android.
TODO: xamarin/xamarin-android#8746 adds a unit test for the
"build with `msbuild.exe`" scenario.
Context: https://github.com/xamarin/xamarin-android/pull/8478
Changes in this commit were originally made in #8478 but aren't
strictly tied to that PR. To make reviews of #8478 easier, a portion
of changes were extracted and placed here.
Modify the LLVM IR generator to output more readable and compact
code:
* Use hexadecimal integer notation wherever it makes sense (e.g.
hashes, managed token IDs)
* Use boolean literals `true` and `false` instead of previously used
`1` and `0`, respectively
* Improve formatting of arrays
* Introduce arrays which can composed from various "sections",
each with its own comment and with data provided during the
generation process, instead of during the preparation phase.
Additional changes:
Extract portions of `MonoAndroidHelper.cs` and place them in a separate
file, `MonoAndroidHelper.Basic.cs` . Code placed in there provides conversion
between RID, and various forms of Android ABI names as well as `xxHash` functions
used throughout the repository, as well as methods to handle paths of ZIP archive
entries in a uniform way. #8478 uses these extracted methods in tests, in standalone
utilities in addition to build tasks.
Use maximum LZ4 compression level when compressing assemblies to be placed in
the application APK/AAB archives.
From time to time, `7zip` invoked by `xaprepare` with an error similar to:
ERROR: Dangerous symbolic link path was ignored : android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/lib/python3.10/site-packages/lldb/lldb-argdumper : ../../../../bin/lldb-argdumper
ERROR: Dangerous symbolic link path was ignored : android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/lib/python3.10/site-packages/lldb/_lldb.cpython-310-x86_64-linux-gnu.so : ../../../liblldb.so
The problem is that this symlink is **not** a dangerous one, as it doesn't
point outside the archived directory tree.
This happened on mac, Windows and Linux alike.
Try to work around the issue by using an undocumented `-snld` 7zip option
when extracting ZIP archives. Since the option is understood only from
`7-Zip` 20.x, check the version before using the argument.
* Debugging MSBuild Tasks
One thing that is very useful is the ability to debug your Tasks while
they are being run on a build process. This is possible thanks to the
`MSBUILDDEBUGONSTART` environment variable. When set to `2` this will
force MSBuild to wait for a debugger connection before continuing.
You will see the following prompt.
```dotnetcli
Waiting for debugger to attach (dotnet PID 13001). Press enter to continue...
```
You can then use VS or VSCode to attach to this process and debug you tasks.
In the case of .NET Android we need to do a couple of thing first though. Firstly
we need to disable the use of `ILRepacker` on the `Xamarin.Android.Build.Tasks`
assembly. This is because `ILRepacker` does NOT handle debug symbols very well.
Assemblies it generates seem to be JIT optimized so the debugger will not load
the symbols. A new MSBuild property has been introduced to disable this feature
while debugging. `_ILRepackEnabled` can be set as an environment variable which
MSBuild will pickup.
```dotnetcli
make prepare && _ILRepackEnabled=false make jenkins
```
This will disable the `ILRepacker` for the build.
You can then start your test app with the `dotnet-local` script (so it uses your build)
```dotnetcli
MSBUILDDEBUGONSTART=2 ~/<some xamarin.android checkout>/dotnet-local.sh build -m:1
```
Once MSBuild starts it will print the following
```dotnetcli
Waiting for debugger to attach (dotnet PID xxxx). Press enter to continue...
```
You need to copy the PID value so we can use this in the IDE. For Visual Studio you can use the `Attach to Process` menu option, while you have the Xamarin.Android.sln solution open. For VSCode open the workspace then use the `Debug MSBuild Task` Run and Debug option. You will be prompted for the PID and it will then connect.
Once connection go back to your command prompt and press ENTER so that the MSBuild process can continue.
You will be able to set breakpoints in Tasks (but not Targets) and step through code from this point on.
Context: 4b33a6229c
Remove `tools/xabuild` completely. It is no longer required; use
`dotnet-local.*` instead (4b33a622).
Additionally, remove unneeded pipelines. `build.groovy` and
`azure-pipelines-oss.yaml` (among others) haven't been executed in
*years*; there is no need to keep these files around.
Context: 46f10fe0a5
Context? 68368189d6
`tools/tmt` (46f10fe0) is a utility to print typemap entries contained
within an application.
`tools/tmt` no longer supports dumping typemap entries; it was
possibly broken in 68368189:
% ./dotnet-local.sh build tools/tmt/*.csproj
% ./dotnet-local.sh build -c Release samples/HelloWorld/HelloWorld/HelloWorld.DotNet.csproj
% bin/Debug/bin/tmt samples/HelloWorld/HelloWorld/bin/Release/net9.0-android/*-Signed.apk
No type maps found in 'samples/HelloWorld/HelloWorld/bin/Release/net9.0-android/com.xamarin.android.helloworld-Signed.apk'
Update the `tools/tmt` utility to support the current format of
typemaps within `libxamarin-app.so`, and update it to generate nicely
formatted Markdown report files instead of the text file output:
% bin/Debug/bin/tmt samples/HelloWorld/HelloWorld/bin/Release/net9.0-android/*-Signed.apk
samples/HelloWorld/HelloWorld/bin/Release/net9.0-android/com.xamarin.android.helloworld-Signed.apk!lib/arm64-v8a/libxamarin-app.so:
File Type: Xamarin App Release DSO
Format version: 2
Map kind: Release
Map architecture: ARM64
Managed to Java entries: 56
Java to Managed entries: 46 (without duplicates)
…
`typemap-v2-Release-ARM64.md` will be created (among other files)
which contains the actual typemap data, in Markdown tabular form:
> # Java to Managed
> | Java type name | Managed type name | Type token ID | Is Generic? | MVID |
> | -------------------------------------------------- | ---------------------------------------------------------------- | --------------------- | ---------------- | ------------------------------------ |
> | android/app/Activity | Android.App.Activity, Mono.Android | 0x02000042 (33554498) | no | 33da2efb-61bb-4fd5-b529-2dee309a3d65 |
> …
> | java/lang/Object | Java.Lang.Object, Mono.Android | 0x0200008B (33554571) | no | 33da2efb-61bb-4fd5-b529-2dee309a3d65 |
> …
> # Managed to Java
> | Managed type name | Java type name | Type token ID | Is Generic? | Is Duplicate? | MVID |
> | ----------------------------------------------------------------------- | -------------------------------------------------- | --------------------- | ----------- | ------------- | ------------------------------------ |
> | HelloLibrary.LibraryActivity, HelloLibrary.DotNet | mono/samples/hello/LibraryActivity | 0x02000002 (33554434) | no | false | ca140934-068f-47d0-a861-6179233e49aa |
> …
Fixes: https://developercommunity.visualstudio.com/t/Visual-Studio-2022-Community-1785-ver/10577484
Related: https://github.com/xamarin/xamarin-android/issues/8662
I found the following build performance issue using a .NET Android
project template inside VS Windows:
1. Create a new .NET Android project
2. Open some `AndroidResource` `.xml` file in the Android designer
3. *Every* incremental build appears to rebuild everything!
`obj\Debug\net8.0-android\build.props` appears to be changing between
builds with the change:
```diff
--androidsupportedabis=armeabi-v7a;arm64-v8a;x86;x86_64
++androidsupportedabis=arm64-v8a
```
I narrowed this down to the designer running two targets,
`PrepareResources;_GenerateCompileInputs`:
7b167eae94/src/Xamarin.Designer.Android/Xamarin.AndroidDesigner/MSBuildConstants.cs (L32)
In this example:
* The designer does *not* mark the build as a "design-time build" with
`-p:DesignTimeBuild=true`. This would have used a design-time `build.props`.
* The designer does *not* pass in the selected Android device.
This code is *ancient*, so I suspect this has just always been an
issue? Perhaps, it only occurs in .NET 6+ projects and not
Xamarin.Android?
Because `$(AndroidSupportedAbis)` is not a "supported" thing in .NET
6+, let's just remove it?
Removing `$(AndroidSupportedAbis)` from this file manually does fix
the problem for me locally:
C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.52\tools\Xamarin.Android.Common.targets
There is also a *second* `adb.props` file that triggers a subset of
things to rebuild if the selected Android device changes:
<WriteLinesToFile
File="$(_AdbPropertiesCache)"
Lines="AdbTarget=$(AdbTarget);AdbOptions=$(AdbOptions)"
Usage of the new property, `$(RuntimeIdentifier)`, also changes
`$(IntermediateOutputPath)`, so I feel like we shouldn't need this
value in `build.props` in a .NET 6+ world.
Context: 68c643b466/src/Microsoft.CodeAnalysis.BannedApiAnalyzers/BannedApiAnalyzers.Help.md
Context: 526172b431
In 526172b4, we had some reasonable performance wins just by using
`TypeDefinitionCache`. Let's take this a step further by "banning"
usage of the methods:
* `Mono.Cecil.FieldReference.Resolve()`
* `Mono.Cecil.MethodReference.Resolve()`
* `Mono.Cecil.TypeReference.Resolve()`
I applied this change to `Xamarin.Android.Build.Tasks.csproj` for now.
In various places, I had to pass `TypeDefinitionCache` around or use
an existing one.
In a future PR, I'll make a small change in xamarin/java.interop so we
can apply the same treatment to `Microsoft.Android.Sdk.ILLink.csproj`.
Changes: 7f08b77f34...dfcbd67030
* xamarin/Java.Interop@dfcbd670: Bump to xamarin/xamarin-android-tools/main@a698a33 (xamarin/Java.Interop#1189)
* xamarin/Java.Interop@6182baff: [build] Target `net8.0` (xamarin/Java.Interop#1186)
xamarin/java.interop@6182baff updated Java.Interop to target .NET 8
instead of .NET 7. This introduced a build break:
…/xamarin-android/src/Mono.Android/Mono.Android.csproj(402,5):
error MSB3030: Could not copy the file
"…/xamarin-android/external/Java.Interop/bin/Debug-net7.0/ref/Java.Interop.dll"
because it was not found.
Introduce a new `$(JavaInteropTargetFrameworkVersion)` MSBuild
property within `Configuration.props` which contains the .NET version
that Java.Interop is targeting.
Update `Mono.Android.csproj` and `Microsoft.Android.Ref.proj` so that
they use `$(JavaInteropTargetFrameworkVersion)` to locate the
reference `Java.Interop.dll` assembly.
Remove old and unused code originally written for:
* Classic Xamarin.Android
* [Xamarin.Android Designer][0] on Windows
* Xamarin.Android Designer on macOS
Remove a collection of platform and compiler compatibility macros,
typedefs and wrapper functions.
Migrate from `char` arrays to `std::string_view` for more strongly
typed code.
Move `-fstack-clash-protection` from `LOCAL_COMMON_COMPILER_ARGS` to
`LOCAL_COMMON_LINKER_ARGS`; it's a linker flag.
Use `#pragma clang diagnostic ignored "-Warray-bounds"` around
certain "MonoVM-isms" in the GC bridge to silence array bounds
checking warnings.
Refactor to use new(er) C++ types such as `std::span`, `std::array`,
and `std::string_view`. This helps reduce memory allocations in some
scenarios, allows usage of the newer `for (e : collection)` syntax,
and increases type safety.
[0]: ff833dc5af/docs/android/user-interface/android-designer/designer-basics.md
Fixes: https://github.com/xamarin/xamarin-android/issues/8708
Add README links to Android SDK 13.2.2 packages. (The most recent available.)
Also, remove mention of OSS packages, as the pipeline has not run in 2 years.
Changes: 66a65e3b3e...848d1277b7
The `<_InstallAndroidJdk/>` target has been removed from the
`<InstallAndroidDependencies/>` target, as Java SDK installation support
has been added to `Xamarin.Installer.Build.Tasks`.
Changes in monodroid:
* Bump external/xamarin-android from a2472a1 to 87341cc (#1417)
* Bump tools/msbuild/external/androidtools from 5bd9cb3 to 34aa04b (#…
* Bump external/android-sdk-installer from 4b563c7 to b9665c8 (#1416)
* Bump tools/msbuild/external/androidtools from 34aa04b to fa69e26 (#…
* [ci] Use NuGetAuthenticate@1 (#1421)
* Bump tools/msbuild/external/androidtools from fa69e26 to 21f6c6f
* Bump external/xamarin-android from 87341cc to 80ee320
* Bump to xamarin/android-sdk-installer@9e143d7298
Context: https://github.com/xamarin/xamarin-android/issues/8421
Working a bit on build performance, I tested:
* `dotnet new maui`
* `dotnet build -bl`
The `.binlog` shows:
LinkAssembliesNoShrink 3.797s
Attaching `dotnet-trace` as mentioned on:
2f192386e8/Documentation/guides/tracing.md (how-to-dotnet-trace-our-build)
I see time broken down such as:
FixAbstractMethods: 37%
AssemblyDefinition.Write: 27%
ProcessAssemblyDesigner: 20%
CopyIfChanged: 13%
DirectoryAssemblyResolver.GetAssembly: 4.4%
This made me focus in on `FixAbstractMethodsStep` and make the
following changes:
* All calls for `TypeReference.Resolve()` and
`MethodReference.Resolve()` should go through the
`TypeDefinitionCache` to avoid repeated lookups.
* `IsInOverrides()` can compare the `MethodReference.Name` before
calling `Resolve()`. It could resolve many unnecessary methods
otherwise.
After these changes, I instead see from `dotnet-trace`:
--1.45s (3.7%) xamarin.android.build.tasks!MonoDroid.Tuner.FixAbstractMethodsStep.FixAbstractMethods()
++949.70ms (2.5%) xamarin.android.build.tasks!MonoDroid.Tuner.FixAbstractMethodsStep.FixAbstractMethods()
Time is now broken down differently, such as:
AssemblyDefinition.Write: 31%
FixAbstractMethods: 28%
ProcessAssemblyDesigner: 23%
CopyIfChanged: 12%
DirectoryAssemblyResolver.GetAssembly: 4.8%
In an overall `.binlog` (without `dotnet-trace` attached):
--LinkAssembliesNoShrink 3.797s
++LinkAssembliesNoShrink 3.105s
This saved ~700ms on initial build of a new MAUI project.
Changes: 1c496970b7...fb7b9a4b9e
Changes: bcc1d3d6f0...d40c654c27
Changes: ae7c93e25a...687be2a32a
Updates:
* Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.2.24078.1 to 9.0.100-preview.2.24106.6
* Microsoft.NETCore.App.Ref: from 9.0.0-preview.2.24076.4 to 9.0.0-preview.2.24080.1
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-alpha.1.24072.1 to 9.0.0-preview.2.24076.1
* Microsoft.NET.ILLink.Tasks: from 9.0.0-preview.2.24076.4 to 9.0.0-preview.2.24080.1
Previously, we would regenerate `api.xml` for `Mono.Android` API-34
on every build.
This involves:
- Installing Android SDK platforms 23 - 34 (2.2 GB)
- Running `class-parse` on every API level
- Running `api-xml-adjuster` on every API level
- Running `api-merge` to merge every level into a single `api.xml`
However, the output ~never changes, as the Android API should not
change once it has shipped. Thus, we can save disk space and build
time by committing a completed `api.xml` instead of rebuilding it.
Additionally, `xaprepare` no longer installs all Android SDK Platforms
by default. Instead it defaults to only installing the latest stable
version and any unstable preview version(s).
A new `xaprepare -android-sdk-platforms=all` command line option is
added to request all platforms be installed instead.
Updated the `HowTo: Add a new Android API Level` document to instruct
how to generate a new `api.xml`.
This saves:
- ~1 minute on the macOS Build (where all platform SDKs are already
installed because we reuse CI agents)
- ~16 minutes on Windows Builds with fresh CI agents (where we
previously had to download all the platform SDKs)
Context: 005c914170
Context: https://github.com/xamarin/java.interop/pull/1181
Context: 25d1f007a7
When attempting to bump to xamarin/java.interop@005c9141, multiple
unit tests would fail, e.g.
Java.Lang.LinkageError : net.dot.jni.test.CallVirtualFromConstructorDerived
----> System.NotSupportedException : Could not find System.Type corresponding to Java type JniTypeSignature(TypeName=net/dot/jni/test/CallVirtualFromConstructorDerived ArrayRank=0 Keyword=False) .
This happened because xamarin/java.interop@005c9141 implicitly
required that typemaps exist for `Java.Interop.JavaObject` subclasses.
Fair enough; enter xamasrin/java.interop#1181, which added support to
`Java.Interop.Tools.JavaCallableWrappers` to emit typemaps for
`Java.Interop.JavaObject` subclasses.
That caused *crashes* in `tests/Mono.Android-Tests`:
E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x75 (index 7 in a table of size 7)
F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75
…
F droid.NET_Test: runtime.cc:630] native: #13 pc 00000000003ce865 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::GetObjectClass(_JNIEnv*, _jobject*)+837)
The immediate cause of the crash was a "use after free" bug within
`TypeManager.CreateInstance()` in a never-hit-before error path; the
"use after free" bug was fixed in 25d1f007.
However, the cause of the hitting a never-hit-before error path is
because `EmbeddedAssemblies::typemap_java_to_managed()` would only
map Java types to `System.Type` instances for assemblies that have
*already been loaded*. If the assembly had not yet been loaded, then
`EmbeddedAssemblies::typemap_java_to_managed()` would return `null`,
and if the binding it couldn't find happens to be for
`java.lang.Object`, we hit the (buggy!) "Where is the Java.Lang.Object
wrapper" error condition.
Commit 25d1f007 fixes that and a great many other related issues.
What's left is `EmbeddedAssemblies::typemap_java_to_managed()`:
it should *never* return null *unless* there is no typemap at all.
Whether the target assembly has been loaded or not should be
irrelevant.
Update `EmbeddedAssemblies::typemap_java_to_managed()` so that it
will load the target assembly if necessary.
Additionally, before we figured out that we had a "use after free"
bug, all we had to go on was that *something* related to
`JNIEnv::GetObjectClass()` was involved. Review JNI usage around
`JNIEnv::GetObjectClass()` and related invocations, and cleanup:
* Simplify logic related to `JNIEnv::DeleteLocalRef()`.
* Decrease scope of local variables.
* Clear variables passed to `JNIEnv.DeleteLocalRef()`.
Co-authored-by: Jonathan Pryor <jonpryor@vt.edu>
Co-authored-by: Marek Habersack <grendel@twistedcode.net>
Context: https://github.com/xamarin/java.interop/issues/1165
Context: 005c914170
Context: https://github.com/xamarin/xamarin-android/pull/8543
Context: 07c7300957
Context: https://github.com/xamarin/xamarin-android/pull/8625
Context: e3e4f123d8
Context: a04b73b30e
Context: efbec22767
Changes: 8b85462e5f...07c7300957
* xamarin/java.interop@07c73009: [Java.Interop] Typemap support for JavaObject & `[JniTypeSignature]` (xamarin/java.interop#1181)
* xamarin/java.interop@d529f3be: Bump to xamarin/xamarin-android-tools/main@ed102fc (xamarin/java.interop#1182)
* xamarin/java.interop@def5bc0d: [ci] Add API Scan job (xamarin/java.interop#1178)
* xamarin/java.interop@d5afa0af: [invocation-overhead] Add generated source files (xamarin/java.interop#1175)
* xamarin/java.interop@473ef74c: Bump to xamarin/xamarin-android-tools/main@4889bf0 (xamarin/java.interop#1172)
* xamarin/java.interop@005c9141: [Java.Interop] Avoid `Type.GetType()` in `ManagedPeer` (xamarin/java.interop#1168)
* xamarin/java.interop@0f1efebd: [Java.Interop] Use PublicApiAnalyzers to ensure we do not break API (xamarin/java.interop#1170)
(From the "infinite scream" department…)
It started with a desire to remove some linker warnings
(xamarin/java.interop#1165):
external/Java.Interop/src/Java.Interop/Java.Interop/ManagedPeer.cs(93,19,93,112):
warning IL2057: Unrecognized value passed to the parameter 'typeName' of method 'System.Type.GetType(String, Boolean)'.
It's not possible to guarantee the availability of the target type.
xamarin/java.interop@005c9141 attempted to fix this by requiring the
use of "typemaps" mapping Java type signatures to managed types,
replacing e.g.:
Type type = Type.GetType ("Example.Type, AssemblyName", throwOnError: true)!;
Type[] parameterTypes = GetParameterTypes ("System.Int32:System.Int32");
ConstructorInfo ctor = type.GetConstructor (ptypes);
// ctor=Example.Type(int, int) constructor
with (not exactly, but for expository purposes):
Type type = GetTypeFromSignature("crc64…/Type");
Type[] parameterTypes = GetConstructorCandidateParameterTypes ("(II)V");
ConstructorInfo ctor = type.GetConstructor (ptypes);
// ctor=Example.Type(int, int) constructor
among other changes.
This was a *significant* change that would alter *Java.Interop*
semantics but *not* .NET Android semantics -- .NET Android uses
`Java.Interop.TypeManager.n_Activate()` (in this repo) for Java-side
"activation" scenarios, not `Java.Interop.ManagedPeer` -- so in an
abundance of caution we did a manual integration test in
xamarin/xamarin-android#8543 to make sure nothing broke before
merging it.
Something was apparently "off" in that integration. (We're still not
sure what was off, or why it was completely green.)
Ever since xamarin/java.interop@005c9141 was merged, every attempt to
bump xamarin/Java.Interop has failed, in a number of ways described
below. However, instead of reverting xamarin/java.interop@005c9141
we took this as an opportunity to understand *how and why* things
were failing, as apparently we had encountered some *long-standing*
corner cases in How Things Work.
The oversights and failures include:
1. In order to make the Java.Interop unit tests work in .NET Android,
the (largely hand-written) Java.Interop test types *also* need to
participate with .NET Android typemap support, so that there is a
typemap entry mapping `net/dot/jni/test/GenericHolder` to
`Java.InteropTests.GenericHolder<T>` and vice-versa.
xamarin/java.interop@07c73009 updates
`Java.Interop.Tools.JavaCallableWrappers` to support creating
typemap entries for `Java.Interop.JavaObject` subclasses,
introducing a new `TypeDefinition.HasJavaPeer()` extension method.
2. (1) meant that, for the first time ever, types in
`Java.Interop-Tests` participated in .NET Android type mapping.
This *sounds* fine, except that `Java.Interop-Tests` contains
"competing bindings" for `java.lang.Object`:
[JniTypeSignature ("java/lang/Object", GenerateJavaPeer=false)]
partial class JavaLangRemappingTestObject : JavaObject {
}
3. (2) means that, for the first time ever, we *could* have the
typemap entry for `java/lang/Object` map to
`Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`,
*not* `Java.Lang.Object, Mono.Android`.
Arguably a bug, arguably "meh", but this setup triggered some
never previously encountered error conditions:
4. `EmbeddedAssemblies::typemap_java_to_managed()` within
`libmonodroid.so` returns a `System.Type` that corresponds to a
JNI type. `typemap_java_to_managed()` has a bug/corner case
wherein it will only provide `Type` instances from assemblies
which have already been loaded.
Early in startup, `Java.Interop-Tests` hasn't been loaded yet, so
when `java/lang/Object` was mapped to
`Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`,
`typemap_java_to_managed()` would return `null`.
This is a bug/corner case, which is being investigated in
xamarin/xamarin-android#8625.
5. Calls to `Java.Lang.Object.GetObject<T>()` call
`Java.Interop.TypeManager.CreateInstance()`, which loops through
the type and all base types to find a known binding/wrapper.
Because of (3)+(4), if (when) we try to find the wrapper for
`java/lang/Object`, we would find *no* mapping.
This would cause an `JNI DETECTED ERROR IN APPLICATION` *crash*.
This was due to a "use after free" bug.
See the "TypeManager.CreateInstance() Use After Free Bug" section.
6. Once (5) is fixed we encounter our next issue: the
`Java.InteropTests.JnienvTest.NewOpenGenericTypeThrows()` unit
test started failing because
`crc641855b07eca6dcc03.GenericHolder_1` couldn't be found.
This was caused by a bug in `acw-map.txt` parsing within `<R8/>`.
See the "`<R8/>` and `acw-map.txt` parsing.`" section.
7. Once (6) was fixed, (3) caused a *new* set of failures:
multiple tests started failing because `java/lang/Object` was
being mapped to the wrong managed type.
(3) becomes less "meh" and more "definitely a bug".
See the "Correct `java/lang/Object` mappings" section.
*Now* things should work reliably.
~~ TypeManager.CreateInstance() Use After Free Bug ~~
On 2011-Oct-19, xamarin/monodroid@e3e4f123d8 introduced a
use-after-free bug within `TypeManager.CreateInstance()`:
JNIEnv.DeleteRef (handle, transfer);
throw new NotSupportedException (
FormattableString.Invariant ($"Internal error finding wrapper class for '{JNIEnv.GetClassNameFromInstance (handle)}'. (Where is the Java.Lang.Object wrapper?!)"),
CreateJavaLocationException ());
`handle` *cannot be used* after `JNIEnv.DeleteRef(handle)`.
Failure to do so results in a `JNI DETECTED ERROR IN APPLICATION`
crash; with `adb shell setprop debug.mono.log lref+` set, we see:
I monodroid-lref: +l+ lrefc 1 handle 0x71/L from thread '(null)'(1)
D monodroid-gref: at Android.Runtime.AndroidObjectReferenceManager.CreatedLocalReference(JniObjectReference , Int32& )
D monodroid-gref: at Java.Interop.JniRuntime.JniObjectReferenceManager.CreatedLocalReference(JniEnvironmentInfo , JniObjectReference )
D monodroid-gref: at Java.Interop.JniEnvironment.LogCreateLocalRef(JniObjectReference )
D monodroid-gref: at Java.Interop.JniEnvironment.LogCreateLocalRef(IntPtr )
D monodroid-gref: at Java.Interop.JniEnvironment.InstanceMethods.CallObjectMethod(JniObjectReference , JniMethodInfo )
D monodroid-gref: …
…
I monodroid-lref: -l- lrefc 0 handle 0x71/L from thread '(null)'(1)
D monodroid-gref: at Android.Runtime.AndroidObjectReferenceManager.DeleteLocalReference(JniObjectReference& , Int32& )
D monodroid-gref: at Java.Interop.JniRuntime.JniObjectReferenceManager.DeleteLocalReference(JniEnvironmentInfo , JniObjectReference& )
D monodroid-gref: at Java.Interop.JniObjectReference.Dispose(JniObjectReference& reference)
D monodroid-gref: at Android.Runtime.JNIEnv.DeleteLocalRef(IntPtr )
D monodroid-gref: at Android.Runtime.JNIEnv.DeleteRef(IntPtr , JniHandleOwnership )
D monodroid-gref: at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
D monodroid-gref: at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
D monodroid-gref: at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
D monodroid-gref: at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
D monodroid-gref: …
D monodroid-gref:
E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x71 (index 7 in a table of size 7)
F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x71
…
F droid.NET_Test: runtime.cc:630] native: #13 pc 00000000003ce865 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::GetObjectClass(_JNIEnv*, _jobject*)+837)
The immediate fix is Don't Do That™; use a temporary:
class_name = JNIEnv.GetClassNameFromInstance (handle);
JNIEnv.DeleteRef (handle, transfer);
throw new NotSupportedException (
FormattableString.Invariant ($"Internal error finding wrapper class for '{class_name}'. (Where is the Java.Lang.Object wrapper?!)"),
CreateJavaLocationException ());
Unfortunately, *just* fixing the "use-after-free" bug is insufficient;
if we throw that `NotSupportedException`, things *will* break
elsewhere. We'll just have an "elegant unhandled exception" app crash
instead of a "THE WORLD IS ENDING" failed assertion crash.
We could go with the simple fix for the crash, but this means that in
order to integrate xamarin/java.interop@005c9141 &
xamarin/java.interop@07c73009 we'd have to figure out how to *ensure*
that `java/lang/Object` is bound as `Java.Lang.Object, Mono.Android`,
not `Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`.
(We actually need to do this *anyway*; see the
"Correct `java/lang/Object` mappings" section. At the time we I was
trying to *avoid* special-casing `Mono.Android.dll`…)
There is a*slightly* more complicated approach which fixes (5)
while supporting (4) `typemap_java_to_managed()` returning null;
consider the `-l-` callstack:
at Android.Runtime.JNIEnv.DeleteRef(IntPtr , JniHandleOwnership )
at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
at Android.Runtime.JavaSet.Iterator()
This is part of a generic `Object.GetObject<IIterator>()` invocation!
Additionally, because `IIterator` is an interface, in *normal* use
the `type` variable within `TypeManager.CreateInstance()` would be
`Java.Lang.Object, Mono.Android` and then *immediately discarded*
because `Java.Lang.Object` cannot be assigned to `IIterator`.
Moving the type compatibility check to *before* the
`type == null` check fixes *an* issue with `typemap_java_to_managed()`
returning null.
~~ `<R8/>` and `acw-map.txt` parsing.` ~~
There are many ways for Android+Java code to refer to managed types.
For example, consider the following View subclass:
namespace Example {
partial class MyCoolView : Android.Views.View {
// …
}
}
Within layout `.axml` files, you can mention an `Android.Views.View`
subclass by:
* Using the .NET Full Class Name as an element name.
<Example.MyCoolView />
* Using the .NET Full Class Name with a *lowercased* namespace
name as the element name.
<example.MyCoolView />
* Use the Java-side name directly.
<crc64….NiftyView />
Within Fragments, you can also use the *assembly-qualified name*:
<fragment class="Example.MyCoolView, AssemblyName" />
At build time, all instances of the .NET type names will be
*replaced* with the Java type names before the Android toolchain
processes the files.
The association between .NET type names and Java names is stored
within `$(IntermediateOutputPath)acw-map.txt`, which was introduced
in xamarin/monodroid@a04b73b3.
*Normally* `acw-map.txt` contains three entries:
1. The fully-qualified .NET type name
2. The .NET type name, no assembly
3. (2) with a lowercased namespace name, *or* the `[Register]`
value, if provided.
For example:
Mono.Android_Test.Library.CustomTextView, Mono.Android-Test.Library.NET;crc6456ab8145c81c4100.CustomTextView
Mono.Android_Test.Library.CustomTextView;crc6456ab8145c81c4100.CustomTextView
mono.android_test.library.CustomTextView;crc6456ab8145c81c4100.CustomTextView
Java.InteropTests.GenericHolder`1, Java.Interop-Tests;net.dot.jni.test.tests.GenericHolder
Java.InteropTests.GenericHolder`1;net.dot.jni.test.tests.GenericHolder
net.dot.jni.test.tests.GenericHolder;net.dot.jni.test.tests.GenericHolder
However, when warning XA4214 is emitted (efbec227), there is a
"collision" on the .NET side (but *not* the Java side); (2) and (3)
are potentially *ambiguous*, so one .NET type is arbitrarily chosen.
(Collisions on the Java side result in XA4215 *errors*.)
The first line is still possible, because of assembly qualification.
Enter ``Java.InteropTests.GenericHolder`1``: this type is present in
*both* `Java.Interop-Tests.dll` *and* `Mono.Android-Tests.dll`.
xamarin/java.interop@07c73009, this was "fine" because the
`GenericHolder<T>` within `Java.Interop-Tests.dll` did not participate
in typemap generation. Now it does, resulting in the XA4214 warning.
XA4214 *also* means that instead of three lines, it's *one* line:
Java.InteropTests.GenericHolder`1, Mono.Android.NET-Tests;crc641855b07eca6dcc03.GenericHolder_1
Enter `<R8/>`, which parses `acw-map.txt` to create a
`proguard_project_primary.cfg` file. `<R8/>` did it's *own* parsing
of `acw-map.txt`, parsing only *one of every three lines*, on the
assumption that *all* entries took three lines.
This breaks in the presence of XA4214, because some entries only take
one line, not three lines. This in turn meant that
`proguard_project_primary.cfg` could *miss* types, which could mean
that `r8` would *remove* the unspecified types, resulting in
`ClassNotFoundException` at runtime:
Java.Lang.ClassNotFoundException : crc641855b07eca6dcc03.GenericHolder_1
----> Java.Lang.ClassNotFoundException : Didn't find class "crc641855b07eca6dcc03.GenericHolder_1" on path: DexPathList[[zip file "/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/base.apk", zip file "/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.x86_64.apk", zip file "/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.xxhdpi.apk"],nativeLibraryDirectories=[/data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/lib/x86_64, /system/fake-libs64, /data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/base.apk!/lib/x86_64, /data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.x86_64.apk!/lib/x86_64, /data/app/Mono.Android.NET_Tests-2stBqO43ov5F6bHfYemJHQ==/split_config.xxhdpi.apk!/lib/x86_64, /system/lib64, /system/product/lib64]]
at Java.Interop.JniEnvironment.StaticMethods.CallStaticObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
at Android.Runtime.JNIEnv.FindClass(String )
Update `<R8/>` to instead use `MonoAndroidHelper.LoadMapFile()`,
which reads all lines within `acw-map.txt`. This results in a
`proguard_project_primary.cfg` file which properly contains a `-keep`
entry for XA4214-related types, such as
`crc641855b07eca6dcc03.GenericHolder_1`.
~~ Correct `java/lang/Object` mappings ~~`
Previous valiant efforts to allow `java/lang/Object` to be mapped to
"anything", not just `Java.Lang.Object, Mono.Android`, eventually
resulted in lots of unit test failures, e.g.:
`Android.RuntimeTests.XmlReaderPullParserTest.ToLocalJniHandle()`:
System.NotSupportedException : Unable to activate instance of type Java.InteropTests.JavaLangRemappingTestObject from native handle 0x19 (key_handle 0x2408476).
----> System.MissingMethodException : No constructor found for Java.InteropTests.JavaLangRemappingTestObject::.ctor(System.IntPtr, Android.Runtime.JniHandleOwnership)
----> Java.Interop.JavaLocationException : Exception_WasThrown, Java.Interop.JavaLocationException
at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership )
at Android.Runtime.XmlResourceParserReader.FromNative(IntPtr , JniHandleOwnership )
at Android.Runtime.XmlResourceParserReader.FromJniHandle(IntPtr handle, JniHandleOwnership transfer)
at Android.Content.Res.Resources.GetXml(Int32 )
at Android.RuntimeTests.XmlReaderPullParserTest.ToLocalJniHandle()
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object , BindingFlags )
--MissingMethodException
at Java.Interop.TypeManager.CreateProxy(Type , IntPtr , JniHandleOwnership )
at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
With a partially heavy heart, we need to special-case typemap entries
by processing `Mono.Android.dll` *first*, so that it gets first dibs
at bindings for `java/lang/Object` and other types.
Update `NativeTypeMappingData` to process types from `Mono.Android`
before processing any other module.
Note that the special-casing needs to happen in `NativeTypeMappingData`
because typemaps were formerly processed in *sorted module order*, in
which the sort order is based on the *byte representation* of the
module's MVID (a GUID). Additionally, *linking changes the MVID*,
which means module order is *effectively random*. Consequently,
trying to special case typemap ordering anywhere else is ineffective.
~~ Other ~~
Update `JavaCompileToolTask` to log the contents of its response file.
Update LLVM-IR -related types within
`src/Xamarin.Android.Build.Tasks/Utilities` to use `TaskLoggingHelper`
for logging purposes, *not* `Action<string>`. Update related types
to accept `TaskLoggingHelper`, so that we can more easily add
diagnostic messages to these types in the future.
Peter Collins
dotnet-maestro[bot]
Jonathan Peppers
Šimon Rozsíval
dependabot[bot]
Marek Habersack
Jonathan Pobst
Dean Ellis
Jonathan Pryor