[Q] Need to stop BootAnimation (Custom Launcher)

Search This thread

kikiwa

Member
Aug 12, 2013
10
0
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.
 
Last edited:

ammcom

Member
Jan 9, 2009
27
1
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?
 

ammcom

Member
Jan 9, 2009
27
1
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

New member
Oct 15, 2014
1
2
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:
Code:
   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

Member
Jan 9, 2009
27
1
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:
Code:
   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

Member
Oct 21, 2013
12
0
command "setprop ctl.start bootanim" to perform boot animation;
command "setprop ctl.stop bootanim" stop the boot animation.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    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:
    Code:
       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.