[Q] Need to stop BootAnimation (Custom Launcher)

[kikiwa]

Hi everybody,

I work on a light Launcher (to replace Launcher2.apk).
One of my objectives is obviously to have a quick boot.
But when my app is ready to show something, the bootanimation is still visible until the Boot timeout (40s after the first log):
WindowManager: ***** BOOT TIMEOUT: forcing display enabled

If I reboot with my command line :
adb reboot && adb wait-for-device && adb shell setprop service.bootanim.exit 1
My boot time is around 15s but with a bad rotation display until I receive the first ConfigurationChanged event. Without this point, the app is ready so...

Question 1: Do you know a way to properly close the boot animation?
Question 2: If the Q1 don't solve the ConfigurationChanged event, do you know a method to receive the ConfigurationChanged event in my Launcher?

Best Regards,
Kikiwa

PS : I hope this topic is in the right section, sorry if it's not the case.

 

[ammcom]

Same problem

Hi everybody,

I work on a light Launcher (to replace Launcher2.apk).
One of my objectives is obviously to have a quick boot.
But when my app is ready to show something, the bootanimation is still visible until the Boot timeout (40s after the first log):
WindowManager: ***** BOOT TIMEOUT: forcing display enabled

If I reboot with my command line :
adb reboot && adb wait-for-device && adb shell setprop service.bootanim.exit 1
My boot time is around 15s but with a bad rotation display until I receive the first ConfigurationChanged event. Without this point, the app is ready so...

Question 1: Do you know a way to properly close the boot animation?
Question 2: If the Q1 don't solve the ConfigurationChanged event, do you know a method to receive the ConfigurationChanged event in my Launcher?

Best Regards,
Kikiwa

PS : I hope this topic is in the right section, sorry if it's not the case.

I am having the same problem , have you found any solution?

 

[kikiwa]

Hello !
Sorry but no. I'm still interested by the solution BTW.
Good luck
Kikiwa

 

[ammcom]

Hello !
Sorry but no. I'm still interested by the solution BTW.
Good luck
Kikiwa

In my case I pushed my custom launcher apk to system/app and deleted launcher2.apk

Could it be that the system is waiting for some special response from default launcher? That should be made in custom luancher?

 

[dtyler7]

Possible Solution

Hey guys,

I was having this same issue for a while now, and I finally found a solution that works for me, at least as of Android 4.4.4 on a Nexus 7 2013 (LTE)

What I did to find this was selectively disable system apps one by one, and then test a reboot.
In my case, disabling Launcher2 didn't affect the boot sequence, but SystemUI (com.android.systemui) did cause these delayed boot times.

I dug through the ASOP source code, and found that the WindowManagerService performs a few checks in performEnableScreen() before stopping boot animation / displaying normally:
- System services must all be ready (mSystemBooted)
- A keyguard or application must be attached to Window Manager (haveApp || haveKeyguard)
- The Wallpaper Service must be disabled or ready (!wallpaperEnabled || haveWallpaper)

Since monitoring logcat showed my replacement launcher was open, and the system services had no errors, I suspected #3 was the problem

In the source for SystemUI, I found a single reference for "wallpaper" - com.android.systemui.ImageWallpaper is an included class that extends WallpaperService but itself is never referenced from that package.
Checking logcat again, I found these lines:

   Attempted wallpaper ComponentInfo{com.android.systemui/com.android.systemui.ImageWallpaper} is unavailable
   Default wallpaper component not found!

It turns out that the system-level WallpaperManagerService has hard-coded that particular class.

As a test fix, I created a new project with package name "com.android.systemui" and a single class "ImageWallpaper" that extends WallpaperService, declared this as a service in my manifest, and installed this apk on a device.
I rebooted, and the boot times were back to normal (~20sec) instead of the previous ~50sec.

So in summary: SystemUI was the culprit in my case; creating a fake replacement package with that hardcoded class back in fixed the long boot times.

 

[ammcom]

Thank you

Hey guys,

I was having this same issue for a while now, and I finally found a solution that works for me, at least as of Android 4.4.4 on a Nexus 7 2013 (LTE)

What I did to find this was selectively disable system apps one by one, and then test a reboot.
In my case, disabling Launcher2 didn't affect the boot sequence, but SystemUI (com.android.systemui) did cause these delayed boot times.

I dug through the ASOP source code, and found that the WindowManagerService performs a few checks in performEnableScreen() before stopping boot animation / displaying normally:
- System services must all be ready (mSystemBooted)
- A keyguard or application must be attached to Window Manager (haveApp || haveKeyguard)
- The Wallpaper Service must be disabled or ready (!wallpaperEnabled || haveWallpaper)

Since monitoring logcat showed my replacement launcher was open, and the system services had no errors, I suspected #3 was the problem

In the source for SystemUI, I found a single reference for "wallpaper" - com.android.systemui.ImageWallpaper is an included class that extends WallpaperService but itself is never referenced from that package.
Checking logcat again, I found these lines:

   Attempted wallpaper ComponentInfo{com.android.systemui/com.android.systemui.ImageWallpaper} is unavailable
   Default wallpaper component not found!

It turns out that the system-level WallpaperManagerService has hard-coded that particular class.

As a test fix, I created a new project with package name "com.android.systemui" and a single class "ImageWallpaper" that extends WallpaperService, declared this as a service in my manifest, and installed this apk on a device.
I rebooted, and the boot times were back to normal (~20sec) instead of the previous ~50sec.

So in summary: SystemUI was the culprit in my case; creating a fake replacement package with that hardcoded class back in fixed the long boot times.

It is exactly my problem and your solution seems perfect

Thank you for your efforts

 

[luckydroid]

command "setprop ctl.start bootanim" to perform boot animation;
command "setprop ctl.stop bootanim" stop the boot animation.