Database Users

Framebuffer Console in Recovery

I'm trying to implement a console in a recovery kernel. I'm stuck at this: After selecting the option to launch the console, recovery does exit, but to a blank screen with "A N D R O I D" flashing in the middle of the screen with a cursor, and then restarting the recovery UI. I've added the proper options to init.rc, plus the required binaries for sbin. Does anyone have any idea about what I'm doing wrong? Here's what I've done so far:
Added the option to exit to the console (do_reboot = 0, gr_exit);
Added openvt, vtspawn, consolemap, loadkeys and start_fbcon to sbin
Added the required calls to init.rc (class_start con when recovery exits, bunch of openvts with class con, start_fbcon disabled until started).

Bump, forgive the double post, etcetera.
I fixed it. If anyone is interested in the method, since this will probably work on any recovery to implement a console, I'd surely help. If not, let this topic die once more.

[Q] Kernel Fails To Boot With Increased Version In Makefile

I have been woeking on a custom kernel I will be releasing shortly but I am having a problem with it. Everything works great with it but when I change the kernel version # and attempt to boot it freezes at rhe samsung screen. I tried insmod -f and compiling with modversions enabled and it continues to freeze and I do not know how to pull a /proc/kmsg during a failed boot to find out as adb does not appear to be active. I suspect a module is barfing at the higher kernel version #. Anyone have a suggestion?

Don't change it.
Its a problem several have had, but with no clear solution yet.

Solution found
Hex edit binary modules from samsung with current required source version...not kosher but it boots and plays well with others. Use my soon to be released kernel as an example.

Dev tools setting causing reboot loop :(

Just installed Elelinux-7.1.0-Hero-v2.1, poked around in Dev Tools, and apparently turned on some debugging feature I should not have. Now my phone goes into a reboot loop. It isn't a full reboot... only the Android boot animation is shown, not the initial HTC splash screen. It makes it up to the lockscreen and the phone is responsive for about 10 seconds before it freezes up and reboots.
This isn't enough time for me to unlock the screen, open the app drawer, run Dev Tools, and change back the setting before the phone reboots. Is there another way of manually clearing the Dev Tools settings without having to do a factory wipe?
Since I can't get into Dev Tools now, I cannot say which options were enabled. I turned on one that shows the touch coordinates, and I think another that shows the running processes (trying to track down battery drain issues). There may have been a couple of others, but due to the delay in the reboot, it's hard to tell exactly which one is the culprit.
So I'm hoping there is some way to bring up the phone in single-user mode, edit or delete a settings file, and then rebooting the phone. I'm using the AmonRA recovery console, if that helps.

I'd just reflash...

Yeah, there isn't much on the phone yet, so I could do a wipe and not lose anything, but I'd rather see if there is a way to recover in case something like this happens again in the future.
I did find an issue tracker page on Google that describes the problem, and a couple of proposed fixes. I'm not allowed to post links yet, so demangle this to bring up the page. I'm going to try editing the settings.db file and hopefully that will fix things:
ht tp://code.google.com/p/cyanogenmod/issues/detail?id=1026

Hooray, editing the settings.db file worked! I followed the suggest posted by cryptographrix in post #14 of the code.google.com thread:
Code:
$ [B]./adb shell[/B]
/ # [B]mount /data[/B]
/ # [B]mount /system[/B]
/ # [B]/system/xbin/sqlite3 ./data/data/com.android.providers.settings/databases/settings.db[/B]
SQLite version 3.7.2
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> [B].header ON[/B]
sqlite> [B]select * from system where name="show_processes";[/B]
_id|name|value
109|show_processes|1
sqlite> [B]update system set value=0 where name="show_processes";[/B]
sqlite> [B]select * from system where name="show_processes";[/B]
_id|name|value
109|show_processes|0
sqlite> [B].quit[/B]
/ # [B]reboot[/B]

[Q] Need to stop BootAnimation (Custom Launcher)

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.

Same problem
kikiwa said:
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.
Click to expand...
Click to collapse
I am having the same problem , have you found any solution?

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

kikiwa said:
Hello !
Sorry but no. I'm still interested by the solution BTW.
Good luck
Kikiwa
Click to expand...
Click to collapse
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?

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.

Thank you
dtyler7 said:
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.
Click to expand...
Click to collapse
It is exactly my problem and your solution seems perfect
Thank you for your efforts

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

Shutdown tablet on off charge

I have rooted tablet T580 with TWRP and magisk.
So my project is to shutdown tablet after beeing offcharge for a certain amount of time. Idea was to create a script that would check status of battery charging and when different then "Discharging" do nothing. After chenging status it would shutdown. It looks something like this:
Code:
#!/system/bin/sh
# Initialise variable
var="Empty"
# Wait for system to boot
#sleep 30
# Do while charging status once a second is not different than charging.
while [ "$var" != "Discharging" ];
do
var=`/system/bin/cat /sys/class/power_supply/battery/status`
#echo "Not discharging\n"
#echo $var
sleep 1
done
/system/bin/reboot -p
When i start script "by hand" everything works nicely. So the tablet, after unpluging it from the power, turns off. The problem is im not able to start the script on boot with Magisk init.d injector. My question is how could i start this script after booting? What could be the problem that it does not start it? What im i missing?
Thank you very much for your help!