Android Splash screen get visible again after using `_system`

[SidiBecker]

Bug Report

Problem

Splash screen get visible again after open a _system URL and return to app on Android devices.

What is expected to happen?

Is expect to app hold the same state before open a url externaly (_system target).

What does actually happen?

Using _system target, the URL opens as usual, but when the user returns to app, the splash become visible again for some milliseconds. In some cases, the app restarts.

Visual example:
https://github.com/SidiBecker/in-app-browser-splash-bug/blob/master/reports/report.gif

Information

Command or Code

    this.inAppBrowser.create('https://google.com', '_system');

Full source-code: https://github.com/SidiBecker/in-app-browser-splash-bug

Environment, Platform, Device

Android devices.
Cordova-android: 14.0.1
Android SDK levels that I tested and got this behavior: 33, 34, 35

Version information

Ionic CLI : 6.20.5
Ionic Framework : not installed
@angular-devkit/build-angular : 20.3.12
@angular-devkit/schematics : 20.3.12
@angular/cli : 20.3.12
@ionic/angular-toolkit : 12.3.0

Cordova:

Cordova CLI : 13.0.0
Cordova Platforms : android 14.0.1
Cordova Plugins : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 5.0.0, (and 4 other plugins)

Utility:

cordova-res : not installed globally
native-run : 1.7.1

System:

NodeJS : v20.19.6 (C:\Program Files\nodejs\node.exe)
npm : 10.8.2
OS : Windows 10

Checklist

• I searched for existing GitHub issues
• I updated all Cordova tooling to most recent version
• I included all the necessary information above

[breautek]

Using _system means you're leaving the app by launching the device's preferred web browser, which places your app in the background.

Once the app is in the background (for any reason), you're at the mercy of Android's app management which may destroy your app's activity at any time. If the activity is destroyed, that's when you'll typically see Android's splash screen, as the app launch is creating a new activity (and such is creating webview instance again). This can be explicitly tested by using the "Don't keep activities" option enabled in Android's developer settings.

Based on the provided gif, it's not exactly clear if the activity is in fact being destroyed in this case. If it's not then there might be something we can do, but having your app's activity destroyed while it's in the background will always be a possibility.

[SidiBecker]

In this case, the app activity is not being destroyed. All the states are holded, but the splash become visible for a short time, for some reason. Exemple:

App starts -> Show splash -> Splash hide -> App started -> Navigate to page 2
Open IAB with _system -> External browser started -> Return to app -> The app still in page 2, but the splash is visible for a short time.

That behavior not happen with _blank target. When return to app, nothing happens, as expected. This happens only with _system target.

Is this behavior expected, or is really a bug?

[breautek]

That behavior not happen with _blank target. When return to app, nothing happens, as expected. This happens only with _system target.

The difference between _blank and _system is definitely cause with _system your app goes into the background. _blank launches a second webview instance that is overlaid on top of your app, so you never actually leave your app.

As far as seeing the splashscreen on app resume... you're only suppose to see it in two situation:

1. Cold start (android needs to launch the entire process into memory)
2. warm start (your app process is already in memory, but the activity needs to be created)

There is a 3rd state, "hot start" which is when your app is launched, and it already has a process in memory, and it already has an activity in memory. This is the state that you're explaining, so no I don't think you should be seeing the splashscreen in this case.

https://developer.android.com/topic/performance/vitals/launch-time#hot
https://developer.android.com/develop/ui/views/launch/splash-screen#how

I wonder if the exit animation is what you're seeing. The fade effect is enabled by default, but can be disabled by setting FadeSplashScreen preference to "false":

<!-- config.xml -->
<preference name="FadeSplashScreen" value="false" />

If the issue goes away, then I think that's sufficient evidence that the exit animation is to blame.

[SidiBecker]

I made two tests with the fade splash config.

 <preference name="FadeSplashScreenDuration" value="2000" />
 <preference name="FadeSplashScreen" value="true" />

The result was:
https://github.com/SidiBecker/in-app-browser-splash-bug/blob/master/reports/splash-fade-2000.gif

 <preference name="FadeSplashScreenDuration" value="2000" />
 <preference name="FadeSplashScreen" value="false" />

The result was:
https://github.com/SidiBecker/in-app-browser-splash-bug/blob/master/reports/splash-fade-off.gif

So, it seems to be the exit animation running. Is this expected? Is there a config to disable this animation on app resume?
I want to keep the fade on app start.

[breautek]

So, it seems to be the exit animation running. Is this expected?

No I don't think that's the intent. I'll move this issue to cordova-android since the issue actually relates to the core platform.

Is this expected? Is there a config to disable this animation on app resume?

No preferences are read-only and stored in memory once it's read from the XML resource. So there isn't a way to programmatically change it within Cordova's framework as currently written.

I also want to remind you that while I do believe this is an issue, using _system and leaving the app can still lose app state if the android os decides to destroy the activity object. So if that flow is important, you will have to find a way to store state somewhere that can be read later and rebuilt later. You can test flows where the activity gets destroyed by enabling the "Don't keep activities" developer option.