Skip to content

Conversation

@jonpryor
Copy link
Contributor

android.app.Application is special: Android contructs it before the
mono runtime has been initialized, requiring that the
activation constructor be used for all Android.App.Application
subclasses:

[Application]
partial class MyApp : Android.App.Application {
    public MyApp (IntPtr r, JniHandleOwnership transfer)
        : base (r, transfer)
    {
    }
}

As a consequence of this, the Android.App.Application..ctor() default
constructor is never used in normal use, which means that the linker
is free to remove it.

This in turn means that in Release (linked) apps, no constructor
would be present in the MyApp Java Callable Wrappers, because
constructor generation requires that the binding assembly contain the
constructor to emit.

This is kinda/sorta fine, in that the Java compiler-provided default
constructor would still be emitted, allowing the MyApp
Java Callable Wrapper to be constructed, but that's only true so long
as the default constructor is sufficient.

Unfortunately, the default constructor isn't always sufficient: on
certain Android versions (API <= 15), the Application instance isn't
provided to the bootstrap MonoRuntimeProvider.attachInfo() method,
which means that the Android.App.Application.Context property returns
the wrong value.

Fixing this requires updating the Java Callable Wrapper of the
Application subclass to contain code to preserve the first Application
instance created in the process, which in turn means the default
Application constructor is no longer sufficient.

Update JavaCallableWrapperGenerator so that (in Debug builds) the
default Application constructor is skipped, and in all
configurations a custom constructor is generated within the
Java Callable Wrapper for android.app.Application subclasses.

android.app.Application is special: Android contructs it before the
mono runtime has been initialized, requiring that the
[activation constructor][0] be used for all Android.App.Application
subclasses:

	[Application]
	partial class MyApp : Android.App.Application {
		public MyApp (IntPtr r, JniHandleOwnership transfer)
			: base (r, transfer)
		{
		}
	}

As a consequence of this, the Android.App.Application..ctor() default
constructor *is never used in normal use*, which means that the linker
is free to remove it.

This in turn means that in Release (linked) apps, *no* constructor
would be present in the `MyApp` Java Callable Wrappers, because
constructor generation requires that the binding assembly contain the
constructor to emit.

This is kinda/sorta fine, in that the Java compiler-provided default
constructor would still be emitted, allowing the `MyApp`
Java Callable Wrapper to be constructed, but that's only true so long
as the default constructor is sufficient.

Unfortunately, the default constructor isn't always sufficient: on
certain Android versions (API <= 15), the Application instance isn't
provided to the bootstrap `MonoRuntimeProvider.attachInfo()` method,
which means that the Android.App.Application.Context property returns
the wrong value.

Fixing this requires updating the Java Callable Wrapper of the
Application subclass to contain code to preserve the first Application
instance created in the process, which in turn means the default
Application constructor is no longer sufficient.

Update JavaCallableWrapperGenerator so that (in Debug builds) the
default Application constructor is skipped, and in *all*
configurations a custom constructor is generated within the
Java Callable Wrapper for android.app.Application subclasses.

[0]: https://developer.xamarin.com/guides/android/under_the_hood/architecture/#Java_Activation
@dellis1972 dellis1972 merged commit a9312d2 into master May 20, 2016
radekdoulik added a commit to radekdoulik/java.interop that referenced this pull request Aug 27, 2018
Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1:

9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (dotnet#47)
bdf0158 Better support no installed JDKs on macOS (dotnet#48)
6353659 Log what is happening during path selection (dotnet#46)
3ef860b Take BUILD_NUMBER into consideration for Version sorting (dotnet#45)
d3de054 Allow an optional locator to be provided to JdkInfo (dotnet#43)
917d3b3 Don't require quotes around `release` values (dotnet#41)
7427692 [tests] Unit tests for finding NDK location based on $PATH (dotnet#40)
dbc517b Merge pull request dotnet#38 from jonpryor/jonp-ndk-via-path
511d580 Allow finding NDK location based on $PATH
b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (dotnet#37)
a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (dotnet#35)
fae7e0a [tests] Remove temporary directories (dotnet#36)
07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (dotnet#34)
radekdoulik added a commit that referenced this pull request Aug 27, 2018
Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1:

9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (#47)
bdf0158 Better support no installed JDKs on macOS (#48)
6353659 Log what is happening during path selection (#46)
3ef860b Take BUILD_NUMBER into consideration for Version sorting (#45)
d3de054 Allow an optional locator to be provided to JdkInfo (#43)
917d3b3 Don't require quotes around `release` values (#41)
7427692 [tests] Unit tests for finding NDK location based on $PATH (#40)
dbc517b Merge pull request #38 from jonpryor/jonp-ndk-via-path
511d580 Allow finding NDK location based on $PATH
b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (#37)
a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (#35)
fae7e0a [tests] Remove temporary directories (#36)
07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (#34)
@jonpryor jonpryor deleted the jonp-app-ctor branch January 25, 2021 20:10
@github-actions github-actions bot locked and limited conversation to collaborators Apr 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants