Skip to content

Changing timezone crashes app #7953

Closed

Description

@rgroenewoudt

Android application type

.NET Android (net7.0-android, etc.)

Affected platform version

VS2022 17.5.4, .NET 7 Android

Description

When building an app with PublishTrimmed enabled, changing the device timezone crashes the app:

[monodroid] Unable to find Android.Runtime.AndroidEnvironment.NotifyTimeZoneChanged()!

illinker seems to remove the method.

The timezone is often automatically changed by getting close to an other country, even though the time itself doesn't change. (changes to Europe/Amsterdam to Europe/Berlin)

The timezone can also be changed manually in the Android settings for the same effect.

Steps to Reproduce

Attached is a new Android 7 app with PublishTrimmed enabled in debug mode which shows the started timestamp in UI.

AndroidApp1.zip

Start the app from Visual Studio in debug mode and note the time. Go to Android settings and change the current timezone to for example Afghanistan.
The app immediately crashes, VS stops debugging and the log shows the error message that AndroidEnvironment.NotifyTimeZoneChanged() is missing.

This happens in both emulator-33 and physical devices.

Did you find any workaround?

Add a linker description file containing:

<linker>
	<assembly fullname="Mono.Android">
		<type fullname="Android.Runtime.AndroidEnvironment">
			<method name="NotifyTimeZoneChanged" /> <!-- Workaround for Xamarin bug trimming method away -->
		</type>
	</assembly>
</linker>

To prevent the method being trimmed away.

Relevant log output

No response

Activity

  1. rgroenewoudt commented on Apr 12, 2023

    @rgroenewoudt
    Author

    I would also like to add that this was very difficult to debug.
    The message [monodroid] Unable to find Android.Runtime.AndroidEnvironment.NotifyTimeZoneChanged()! only shows up in debug mode and not in release mode.
    Nothing in adb logcat or adb bugreports.

    Android's ActivityManager.GetHistoricalProcessExitReasons() only reports REASON_EXIT_SELF with signal 13. (it's not recognized as crash?)

    If the app is immediately killed/aborted, I would at least expect the related error message to be present in logcat.

  2. added
    Area: TrimmingIssues with ILLink or NativeAOT related to trimming.
    and removed
    needs-triageIssues that need to be assigned.
    on Apr 12, 2023
  3. removed their assignment
    on Apr 12, 2023
  4. grendello commented on Apr 12, 2023

    @grendello
    Contributor

    @rgroenewoudt The message is logged with the ANDROID_LOG_FATAL priority, can't get any higher alas. If it was missing from the logcat, then that's on Android I'm afraid.

  5. grendello commented on Apr 12, 2023

    @grendello
    Contributor

    Android's ActivityManager.GetHistoricalProcessExitReasons() only reports REASON_EXIT_SELF with signal 13. (it's not recognized as crash?)

    Back in the day, calling exit() from the application would actually terminate the process. At some point Android changed the behavior and right now it mostly restarts the application if exit() is called. To quit the app, one needs to call abort() now. Until very recently, we weren't consistent in that, preserving a lot of older code that still called exit() on fatal failures.

  6. jonathanpeppers commented on Apr 12, 2023

    @jonathanpeppers
    Member

    @grendello do we need to do an audit of all mono_class_get_method_from_name calls and make sure we have xml to preserve it? Some might be fine to trim away, if we don't have to abort in those cases.

    I will work on fixing this specific case -- adding a test. I think I can probably just try calling the method from System.Reflection in Release mode to assert that it exists.

  7. grendello commented on Apr 13, 2023

    @grendello
    Contributor

    @jonathanpeppers Isn't it a bug in the linker though? I was under impression that such lines preserve the entire type? If not, then what's the point of the <type> element?

  8. grendello commented on Apr 13, 2023

    @grendello
    Contributor

    @grendello do we need to do an audit of all mono_class_get_method_from_name calls and make sure we have xml to preserve it? Some might be fine to trim away, if we don't have to abort in those cases.

    If the <type> element doesn't preserve the entire type, then yes, we probably need to list each method in the preserve lists.

  9. jonathanpeppers commented on Apr 13, 2023

    @jonathanpeppers
    Member

    No, the problem here is we removed <type fullname="Android.Runtime.AndroidEnvironment" />: 11f0e1b

    We don't actually have anything preserving AndroidEnvironment.NotifyTimeZoneChanged(), if it isn't called from managed code the linker doesn't know about it.

  10. rgroenewoudt commented on Apr 13, 2023

    @rgroenewoudt
    Author

    If only the .NET 5+ is supported, it might also be an idea to use DynamicallyAccessedMembersAttribute.

  11. jonathanpeppers commented on Apr 13, 2023

    @jonathanpeppers
    Member

    DynamicallyAccessedMembersAttribute would be good if using some type required this method, but I think all apps actually require it?

  12. ghost locked as resolved and limited conversation to collaborators on May 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Area: TrimmingIssues with ILLink or NativeAOT related to trimming.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions