Skip to content

[Mono.Android] JNIEnv.FindClass(Type) now uses TypeManager #9812

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.

Sign up for GitHub

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

Merged
merged 5 commits into from
Feb 21, 2025
Merged

[Mono.Android] JNIEnv.FindClass(Type) now uses TypeManager #9812

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1b1f145
[Mono.Android] `JNIEnv.FindClass(Type)` now uses `TypeManager`
jonathanpeppers Feb 19, 2025
32e43f0
Try dotnet/java-interop#1312
jonpryor Feb 20, 2025
137214a
Fixity Fix
jonpryor Feb 20, 2025
164166b
…and again!
jonpryor Feb 20, 2025
92a5642
Bump to dotnet/java-interop/main@9dea87dc
jonpryor Feb 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions samples/NativeAOT/MainActivity.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
using Android.Content.Res;
using Android.Runtime;
using Android.Util;
using System.Reflection;
Expand All @@ -17,5 +18,9 @@ protected override void OnCreate(Bundle? savedInstanceState)

// Set our view from the "main" layout resource
SetContentView(Resource.Layout.activity_main);

// An example of an Android API that uses a Java array
var list = new ColorStateList (new int[][] { [ 0, 1 ]}, [0, 1]);
Log.Debug ("NativeAOT", "MainActivity.OnCreate() ColorStateList: " + list);
}
}
12 changes: 10 additions & 2 deletions src/Mono.Android/Android.Runtime/JNIEnv.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -254,12 +254,20 @@ public static unsafe IntPtr CreateInstance (Type type, string signature, params

public static IntPtr FindClass (System.Type type)
{
int rank = JavaNativeTypeManager.GetArrayInfo (type, out type);
try {
return FindClass (JavaNativeTypeManager.ToJniName (GetJniName (type), rank));
var sig = JNIEnvInit.androidRuntime?.TypeManager.GetTypeSignature (type) ?? default;
if (!sig.IsValid || sig.SimpleReference == null) {
throw new ArgumentException ($"Could not determine Java type corresponding to `{type.AssemblyQualifiedName}`.", nameof (type));
}

JniObjectReference local_ref = JniEnvironment.Types.FindClass (sig.Name);
IntPtr global_ref = NewGlobalRef (local_ref.Handle);
JniObjectReference.Dispose (ref local_ref);
return global_ref;
} catch (Java.Lang.Throwable e) {
if (!((e is Java.Lang.NoClassDefFoundError) || (e is Java.Lang.ClassNotFoundException)))
throw;
int rank = JavaNativeTypeManager.GetArrayInfo (type, out type);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should log or something in the error path so we have something to look for in NativeAOT builds to see if we're hitting the error path.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It calls monodroid_log for e currently, which would also fail spectacularly...

I put on the list to cleanup monodroid_log() along with the Android system property parsing:

RuntimeNativeMethods.monodroid_log (LogLevel.Warn, LogCategories.Default, $"JNIEnv.FindClass(Type) caught unexpected exception: {e}");
var jni = Java.Interop.TypeManager.GetJniTypeName (type);
if (jni != null) {
Expand Down
Loading