Bug 18580 - Linker strips __TypeRegistrations and JNI type mappings fail
Summary: Linker strips __TypeRegistrations and JNI type mappings fail
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.12.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Radek Doulik
Depends on:
Reported: 2014-03-26 05:58 UTC by Mart Roosmaa
Modified: 2015-02-27 10:35 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Test case for the bug. (21.67 KB, application/zip)
2014-03-26 05:59 UTC, Mart Roosmaa

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Mart Roosmaa 2014-03-26 05:58:08 UTC
When using "Link all assemblies" (and NOT using "Fast assembly deployment" [1]) the linker strips out the __TypeRegistrations magic type for the assembly, thus when the mono runtime loads the assembly into memory the JNI types aren't registered.

In most cases nothing breaks when types aren't registered, however, when dealing with objects coming in from the Java side (ie exception subclass like in the attached test case) they will be mapped incorrectly to the base object (which mapping is loaded).

The attached test case uses Google Play Services component to do authentication and thus relies on the exception types being correctly resolved into C# types.

One additional thing I noticed in the application output is that the mono runtime behaves differently for linked vs not-linked assemblies (might be expected, might be another linker bug).

  For not-linked:
    [Mono] Assembly Ref addref NoJniRegistration[0x787dde70] -> GooglePlayServicesLib[0x787dea10]: 2
  For linked:
    [Mono] Assembly Ref addref NoJniRegistration[0x790cd2a0] -> GooglePlayServicesLib[0x790cd300]: 2
    [Mono] Assembly Ref addref GooglePlayServicesLib[0x790cd300] -> Mono.Android[0x790ce768]: 3
    [Mono] The request to load the assembly mscorlib v2.0.5.0 was remapped to v2.0.0.0
    [Mono] Unloading image mscorlib.dll [0x7a6aeb70].
    [Mono] Assembly Ref addref GooglePlayServicesLib[0x790cd300] -> mscorlib[0x74e32750]: 6

The workaround for this seems to be to register the type(s) manually:
  Java.Interop.TypeManager.RegisterType ("com/google/android/gms/auth/UserRecoverableAuthException", typeof(UserRecoverableAuthException));

Software versions where the bug lurks:
  Xamarin Studio - 4.2.3 (build 60)
  Mono - 3.2.6 ((no/9b58377)
  Xamarin.Android - 4.12.1 (Business Edition)

[1] When using fast assembly deployment it seems that the assemblies deployed aren't linked. (bug/intentional?)
Comment 1 Mart Roosmaa 2014-03-26 05:59:50 UTC
Created attachment 6409 [details]
Test case for the bug.
Comment 2 Shruti 2014-04-04 10:26:26 UTC
I have tested this issue with attached project 'NoJniRegistration'. I deploy this app on device and get 2 links. When I tap on links , getting 'Generic Exception' value. When I go through the attached project, It has StartAuth() method where "Generic exception" has been thrown.

Output Error log regarding same is mentioned below :


Environment Info :
data transfer test: === Xamarin Studio ===

Version 4.2.3 (build 60)
Installation UUID: ce3f5199-e126-42fd-bc8a-6a96370af9ab
 Mono 3.2.7 ((no/40f92d5)
 GTK+ 2.24.23 theme: Raleigh
 GTK# (
 Package version: 302070000

=== Apple Developer Tools ===

Xcode 5.0 (3332.22)
Build 5A1412

=== Xamarin.iOS ===

Version: (Trial Edition)
Hash: 46b2486
Build date: 2014-03-24 15:04:26-0400

=== Xamarin.Android ===

Version: 4.12.1 (Trial Edition)
Android SDK: /Users/mac109/Desktop/android-sdk-macosx
 Supported Android versions:
  2.2   (API level 8)
  2.3   (API level 10)
  3.1   (API level 12)
  4.0   (API level 14)
  4.0.3 (API level 15)
  4.1   (API level 16)
  4.2   (API level 17)
  4.4   (API level 19)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Xamarin.Mac ===

Xamarin.Mac: Not Installed

=== Build Information ===

Release ID: 402030060
Git revision: 30c4afc300c2a39ec5300851357ce02e49dd217e
Build date: 2014-03-05 22:09:33+0000
Xamarin addins: f8a9589b57c2bfab2ccd73c880e7ad81e3ecf044

=== Operating System ===

Mac OS X 10.9.2
Darwin mac109s-Mac-mini.local 13.1.0 Darwin Kernel Version 13.1.0
    Thu Jan 16 19:40:37 PST 2014
    root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
[4/3/2014 7:01:09 PM] data transfer test: iOS Stack trace
[4/3/2014 7:01:11 PM] data transfer test: http://screencast.com/t/Whc2OGEN6d
[4/3/2014 7:25:56 PM] data transfer test: http://screencast.com/t/iduDs9Jz
[4/3/2014 7:27:09 PM] data transfer test: Mono 3.2.7 ((no/40f92d5)
[4/3/2014 7:27:24 PM] data transfer test: Xcode 5.0 (3332.22)
[4/3/2014 7:27:36 PM] data transfer test: Xamarin.iOS
Version: (Trial Edition)
[4/3/2014 7:27:44 PM] data transfer test: Xamarin.Android
Version: 4.12.1 (Trial Edition)
Comment 3 Alex Rønne Petersen 2014-04-07 05:30:43 UTC
Fixed in 1cbf18692759b1a55e98c50883118053c8a6d515 in XA master.
Comment 4 Udham Singh 2014-07-07 14:29:38 UTC
I have checked this issue with sample project attached in comment 1. I have deployed this application on device and got the "Generic exception" when I tap on available link. Hence I am reopening this issue.

Screencast : http://www.screencast.com/t/BtcvQPui

Output Log : https://gist.github.com/lal360/de8202df74d7731f2608
Adb Logcat : https://gist.github.com/lal360/c07f493493bb0866409c

Environment Info :

=== Xamarin Studio ===

Version 5.2 (build 180)
Installation UUID: 3dbf10c4-ed30-4e55-8a8b-1704777c7b5f
	Mono 3.6.0 ((no/a653694)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 306000000

=== Apple Developer Tools ===

Xcode 5.1 (5084)
Build 5B130a

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 762ebac
Build date: 2014-07-03 15:53:37-0400

=== Xamarin.Android ===

Version: 4.14.0 (Business Edition)
Android SDK: /Users/apprpject/Desktop/android-sdk-macosx
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		3.2   (API level 13)
		4.0   (API level 14)
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.2   (API level 17)
		4.3   (API level 18)
		4.4   (API level 19)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Xamarin.Mac ===


=== Build Information ===

Release ID: 502000180
Git revision: c27cfff0160e6f3d8ad82b57be030d6adf866743
Build date: 2014-07-04 18:06:04-04
Xamarin addins: 68026ad1ccee9923e927d9cfcca408d673d5ab61

=== Operating System ===

Mac OS X 10.8.5
Darwin localhost 12.5.0 Darwin Kernel Version 12.5.0
    Sun Sep 29 13:33:47 PDT 2013
    root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
Comment 5 Alex Rønne Petersen 2014-07-07 14:32:03 UTC
I don't know what that exception is about, but it isn't related to the actual bug.
Comment 6 Radek Doulik 2015-02-27 10:35:23 UTC
The exception is from the application where it is missing meta-data tag

E/NoJni (22803): Failed with generic exception!
E/NoJni (22803): java.lang.IllegalStateException: A required meta-data tag in your app's AndroidManifest.xml does not exist. You must have the following declaration within the <application> element: <meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" />

Thus closing the bug as the original issue is fixed.