Hey there! I was experiencing similar behavior at first with my own mobile app, SubverseIM. My solution was to adjust the LaunchMode for the MainActivity class in the Android subproject to LaunchMode.SingleInstance. This seemed to prevent a duplicate call to OnCreate whenever I launched the activity from a notification.

I also had to adjust the way I initialized the notification object in order to replicate the behavior of launching the app from the home screen upon tapping the notification. Here's the relevant code:

// Configure intent for special "launcher" behavior
Intent notifyIntent = new Intent(this, typeof(MainActivity));
notifyIntent.SetAction(Intent.ActionMain);
notifyIntent.AddCategory(Intent.CategoryLauncher); 
notifyIntent.AddFlags(ActivityFlags.NewTask);

// Create PendingIntent using this instance
PendingIntent? pendingIntent = PendingIntent.GetActivity(
    this, 0, notifyIntent, PendingIntentFlags.UpdateCurrent |
    PendingIntentFlags.Immutable);

// Setup the notification object with the PendingIntent
Notification notif = new NotificationCompat.Builder(this, /* notif id */)
    .SetContentIntent(pendingIntent) // make sure to set the pending intent
    .Build();

See this link for a working example project: https://github.com/SubverseIM/SubverseIM

Hope this helps!!

Thanks, we have already tried what you have done in fact using GetLaunchIntentForPackage of package manager "to replicate the behavior of launching the app from the home screen upon tapping the notification" improved things further but the bug still happens under certain sequences ie when swiping the app clear ,launching the app from an action button on notification and then after that closing the app and opening from a notification causes the exception. We cannot possibly handle every edge case ,the underlying issue needs fixing.

No problem! Fair enough, in my case I didn't have this edge case issue because my app uses a ForegroundService to stay resident in memory. I agree, it should be fixed at its source!
Cheers~

Could you provide a minimal repro?

@emmauss I came accross the same issue and created a minimal reproducible example here. In contrast to this issue's description my example uses an intent-filter to show files instead of notifications. Nevertheless, I believe the underlying error is the same.

@daniel-lerch you can fix it by adding LaunchMode = LaunchMode.SingleInstance, to your activity options, but that would force your app into single instance mode. For multi-instancing or embedding scenerios, we would need changes to how lifecycle works on android.

@emmauss Thanks for pointing this out. I would propose to make LaunchMode.SingleInstance the default in Avalonia templates and add to Avalonia's documentation that other launch modes are currently not supported due to its architecture.

Regarding the bugs that @sessiontalk originally described, I cannot reproduce them when using LaunchMode.SingleInstance. Regardless whether I use notifications or file open intents, swipe out the app or not, it simply does not crash. But that is actually what I would expect as Android documentation says: Also, the device can hold only one instance of the "singleInstance" activity at a time Link.

There are many reasons you wouldn't want to have SingleInstance as default. It isn't the default mode for an android app. And it can cause app state to be lost. Take a scenario where you have an active activity thats viewing a file. You open a new file in your file explorer. That replaces your previous file data. Pressing back to go to your file browser will finish the activity and remove the whole app from your tasks.
We instead need to have a lifecycle where you can open as many activities and not interfere with each activity state.