@jiahaog any updates on this issue? Let me know if you want me to take a look, and go ahead with the PR.

One consideration to make though wrt #85139 is that it still can't make Android's first frame a correct measurement of Flutter's first frame, since Android's first frame will still be

[Flutter's first frame] + [time needed to jump from raster to main thread and get a next Android vsync] = [Android's first frame].

Yes, I've started looking at it, will follow up with a PR soon

Support a compatibility mode with the old way. Likely by letting this be configurable via FlutterView constructor argument and letting there be intent builder flags defaulting to yes on FlutterActivity/FlutterFragment/FlutterFragmentActivity

What about if we check if the user has supplied a io.flutter.embedding.android.SplashScreenDrawable by calling https://github.com/flutter/engine/blob/40edba381e758e4abaaa4e59192748f12eb97895/shell/platform/android/io/flutter/app/FlutterActivityDelegate.java#L432, if true, then we don't add OnPreDrawListener. Otherwise, we opt into this new mode?

Also, is there a valid use case for this custom splash screen API? could we deprecate it, and document that it's not longer needed?

@xster any thoughts?

@blasten we may still need a flag - users may still want to provide io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen for APIs < 31, while at the same time using the Android S splash screen. (unless we do option 2 below)

There are a few approaches I can think of:

Option 1: Support the Flutter-specific splash screen for APIs >= 31

There may be a jarring transition here depending on how users set up their Flutter splash screen. But in this case, we continue to show the provided drawable.

This will require a flag roughly named useLegacySplashScreenAboveAPI31 for this discussion, which will probably be read from the users' AndroidManifest.xml. The following table tries to enumerate possible use cases of how users may configure their app, and the behavior on the API versions.

The guidance here is for users who want to show a splash screen to do the following, which are not mutually exclusive, and since the API 31 rollout may take a while:

• For API < 31, continue to use io.flutter.embedding.android.SplashScreenDrawable or provideSplashScreen
• For API >=31, set useLegacySplashScreenAboveAPI31 to false and use the Android S splash screen APIs

Option 2: Don't support the Flutter-specific splash screen for APIs >= 31

Another approach is to use preDraw unconditionally for APIs >= 31. This is probably breaking, since the provided splash screens through io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen will not be shown.

Do we need to worry about the V1 embedding? I also noticed the existence of the io.flutter.app.android.SplashScreenUntilFirstFrame option, but this appears to only be used for V1.

Jotting down my findings as well about how it works today on cold start.

API < 31

1. android:theme on activity is shown
2. Show io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen if present
3. Crossfade to Flutter

API 31

1. Android S splash is shown
   <possible jarring transition because Android S splash is not nessarily aligned with 2 or 3>
2. Show io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen if present
3. Crossfade to flutter

Thanks Jia.

I was under the impression that the custom Flutter splash screen was added because we didn’t know that we could delay showing the Android view hierarchy until Flutter painted the first frame. If this is true, then this feature is not longer necessary.

I’d like to see a real world use case where a secondary splash screen is needed because the oficial Android splash screen isn’t sufficient. have you seen this case internally?

Note that onPreDraw() has been available since API level 1.

From what I can see, most use cases internally point their io.flutter.embedding.android.SplashScreenDrawable to @drawable/launch_background.xml. The same @drawable/launch_background.xml is also referenced by the android:theme of the Activity, as the android:windowBackground. There is one instance where the app uses provideSplashScreen to offset the same @drawable/launch_background.xml by the status bar height. I'm not really sure why, but I reached out to the author.

Thanks Jia. Do we still need the flag useLegacySplashScreenAboveAPI31 or could we still use the same check from https://github.com/flutter/engine/blob/40edba381e758e4abaaa4e59192748f12eb97895/shell/platform/android/io/flutter/app/FlutterActivityDelegate.java#L432?

Not sure if we should reuse it - the linked check comes from the io.flutter.app.android.SplashScreenUntilFirstFrame option which users can set in their manifest, but it appears to be deprecated since it's only part of the V1 embedding. The naming also doesn't really match the semantics of what we're trying to do here as well.

I do like the simplicity of not having a flag though as you've mentioned. Do you know if there are other valid external use cases of manually providing a splash screen?

There's also the equivalent in the V2 embedding: https://github.com/flutter/engine/blob/138c91c614d742c52aa5432b4cb921f0ff9fdee2/shell/platform/android/io/flutter/embedding/android/FlutterActivityLaunchConfigs.java#L16

Right, I think we were both referring to that flag (io.flutter.embedding.android.SplashScreenDrawable) above. I set up a meeting to align on our approach to this offline 🙂

We synced up, next steps:

• Verify if using preDraw and not using io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen causes a white flash on pre-Android S
• If the white flash isn't an issue, make using preDraw the default, and add a manifest flag that controls the behavior on all API versions to allow users to opt-out
  • if users use io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen, print logs to direct them to documentation / migration guide
  • Then deprecate the io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen APIs
• Verify that the proposed behavior doesn't do anything weird on add-to-app

Verify if using preDraw and not using io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen causes a white flash on pre-Android S

@jiahaog I just tested it on Android 30/ Moto G7. No white splash. However, I do see the fade-out transition.

I changed the custom drawable bg color to purple, and I see a fade-out purple background that gets blended with the color I set in the initial Android splash screen.

Here's the code I added to FlutterView.java:

private void init() {
    // ... current code ... //
    this.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
      @Override
      public boolean onPreDraw() {
        return isFlutterUiDisplayed;
      }
    });
}

Yeah, I can reproduce that as well. I must have remembered something wrongly, apologies for the confusion. As discussed, I'll work on a PR for the following then:

• if the white flash isn't an issue, make using preDraw the default, and add a manifest flag that controls the behavior on all API versions to allow users to opt-out
  • if users use io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen, print logs to direct them to documentation / migration guide
  • Then deprecate the io.flutter.embedding.android.SplashScreenDrawable / provideSplashScreen APIs

Update: Working on a PR for what was discussed above

flutter/engine#27645 was rolled back in flutter/engine#27788 because it broke some devicelab tests.

• https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_android%20hybrid_android_views_integration_test/2047/overview
• https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_android%20embedded_android_views_integration_test/2044/overview

Will investigate and try to reland

@jiahaog flutter/engine#27811 seems to have landed. Can we close this issue?

I think so

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.