Can not Export CREATOR Field for IParcelable instance

[fullmetaltac]

Sample link

https://github.com/xamarin/monodroid-samples/blob/f944f42001fa134915069fa7bbb9cb493bfd446d/ExportAttribute/ExportAttributeTest/MainActivity.cs#L55
https://github.com/xamarin/monodroid-samples/blob/f944f42001fa134915069fa7bbb9cb493bfd446d/android5.0/Topeka/Topeka/Models/Player.cs#L18

Verified on Monodroid v8.2.0.1

Issue description

Can not ExportField CREATOR for IParcelable instance

Steps to reproduce the issue

1. Open Topeka sample.
2. Input login info.
3. Tap Login button.

What's the expected result?

• User successfully login.

What's the actual result?

• Application crashes.

Steps to reproduce the issue

1. Open ExportAttributeTest sample.
2. Tap button.

What's the expected result?

• Parcelable object handled properly.

What's the actual result?

• Application crashes.

Additional details / screenshot (Optional)

InitializeCreator method is not reachable via debugger.
MSBuildOutput.log
logCat.txt

[jonpryor]

This does not crash on d15-5/Xamarin.Android 8.1.

@fullmetaltac: Does this happen in the Debug configuration or when linking is disabled?

@radekdoulik: I suspect that this is a linker bug, and that Player.InitializeCreator() is being linked away, which would explain why it can't be found.

Could this be related to PR #1059?

[fullmetaltac]

@jonpryor I tried with Visual Studio Tools for Xamarin v4.9.0.669 and v4.8.0.753 both with Release and Debug configurations. I tested on real device Xiaomi Redmi 3S (v6.0.1) and with Nexus One (API:27) emulator. Result the same in each case.

Here is crash info from device. The same error I was getting spontaneously and was not able to write concrete steps to reproduce. This error getting periodically and I hope has the same root cause.

[fullmetaltac]

@jonpryor Should I close this duplicate?
dotnet/android-samples#254

[radekdoulik]

Looks like it is not Linker related. Happens in Debug configuration as well.

I will try to find out why it fails.

[radekdoulik]

@jonathanpeppers Looks like it might be related to dotnet/java-interop@429dc2a

Do you know what might be wrong here? Looks like we might be looking for wrong signature?

[jonpryor]

@radekdoulik: @jonathanpeppers is OOF until ~march, so don't expect much from him. :-)

I also doubt that it's dotnet/java-interop@429dc2a, as the bug is reported against d15-6, and the referenced Java.Interop commit should only be in d15-7/master, not d15-6. (At least it better not be in d15-6; I wanted it to get more testing!)

I don't see that commit in https://github.com/xamarin/Java.Interop/commits/d15-6.

@radekdoulik: Do you have any additional information to bring to the table?

[radekdoulik]

@jonpryor Indeed. Another candidate might be dotnet/java-interop@cb161d2

Trying to find out more about it.

[radekdoulik]

The above mentioned commit indeed caused the regression.

The signature for the InitializeCreator signature is now ()Ljava/lang/Object; while it was ()Lmd59b7a7576784821ea63294fbca8600da1/Creator_1; before.

[jonpryor]

@radekdoulik: I think I have a theory. Consider JavaNativeTypeManager.ToJniNameFromAttributes(TypeDefinition). What happens if the TypeDefinition does not implement IJniNameProviderAttribute?

In particular, Creator<T> does not implement IJniNameProviderAttribute -- nor should it.

If the TypeDefinition (typeof(Creator<>)) does not implement IJniNameProviderAttribute, then JavaNativeTypeManager.ToJniNameFromAttributes(TypeDefinition) will return null, which means JavaNativeTypeManager.ToJniName(TypeDefinition) will return java/lang/Object, which explains the new signature you're seeing for InitializeCreator().

...which doesn't actually make sense; shouldn't the IJavaObject check in JavaNativeTypeManager.ToJniName(TypeDefinition, ExportKind) catch Creator<T>? In which case we should be hitting ToJniName<T>(), which should create the md5.../Creator_1 name.

More digging is needed. :-(