When your app is launched and it isn’t in memory yet, there may be some delay between when the user starts your app and when your launcher Activity’s onCreate() is actually called.

During the ‘cold start’, the window manager tries to draw a placeholder UI using elements from the app theme like the windowBackground . So, rather than showing the default windowBackground (usually white or black), you can change it to a custom drawable that shows your splash screen. This way the splash screen only shows when needed and you don’t slow down your users.

The key is creating a custom theme that overrides android:windowBackground , then replacing that custom theme with your standard theme before calling super.onCreate() in your Activity.

Implementation

In this example, I will assume your app main theme is named AppTheme, but if it’s not then you can replace all occurrence of AppTheme with the name of your app main theme.

You will have to create a new theme for the launcher. The only element we are interested in overriding in this theme is the windowBackground , so the launcher theme will be:

To inherit every other attribute in your main theme, the dot notation was used by prefixing the name of the theme (AppTheme), separated by a period (.).

Let’s define the launch_screen drawable. While you could just use a simple image, it will end up stretched to fill the entire screen. Instead, you can use an XML file such as:

Then apply the launcher theme to your launcher Activity in your AndroidManifest.xml file using:

android:theme=”@style/AppTheme.Launcher”

The easiest way to transition back to your normal theme in your launcher (main) activity is to call setTheme(R.style.AppTheme) before super.onCreate() and setContentView() :

You can read more about this approach from the source here.

Pros:

No launch/splash activity needed — there is no delay such as there would be if you were launching a second activity from a dedicated splash screen activity. No artificial delays — No intentional x seconds delay. Only showing the splash screen when the system is loading up the app.

Cons:

I have seen 3 very common complains about this approach.

The splash screen showing again if the activity was killed and recreated by the system. In most cases, this is not a very serious issue, but you can use Method 2 to fix it. Some developers want to have a dedicated splash screen Activity that routes to different pages based on some state after the splash screen is done. Again you can easily do this using Method 2 below, but sometimes this dedicated router Activity end up getting really messy. Not able to load heavy data/components while the splash screen is shown. It’s usually a bad idea to require heavy data or components to be loaded before the app is actually started (there are some exceptions). You can try one of the suggestions below:

i) Try to lazy load your components/modules/libraries. Except a component is really really required for the app to work, try not to load it at launch time rather load it when you need it or use a background thread to load it after the app has started. Try to keep your Application onCreate() as light as possible

ii) Make use of caching. Except that info changes very frequently, you should cache it. So when next the user comes to your app, you can show this cached content while you load more recent content.

I think we should strive to remove things like long splash screens, ProgressDialogs that make the user unable to perform any other action apart from just staring at the screen. You never know how long it will take to load that data from the Internet.