Related
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]
Improve your battery life tenfold by PureMotive
tested and working at: SGS, Xperia Play, HTC Inc S, the battery life has increased significantly
Original link: http://forum.xda-developers.com/showthread.php?t=1621808http://forum.xda-developers.com/showthread.php?t=1621808
PureMotive said:
Okay guys, I just thought I'd give you my mod for achieving good-great battery life. This is the mod I use in Anthem™ which has given me 50+ hours on a single charge. Feel free to include it in your own ROM or whatever. Please give credit or thanks or both
First: Here is a flashable .zip of the mod that may or may not work with your ROM. I'd still advise doing it manually.
Sysctl.conf - Outdated as of 4/29/2012
Step 1
Open up your ROM.zip (or whatever it's called) in 7zip (Windows) or Betterzip (OSX) and locate
sysctl.conf in /system/etc
If it's not in this directory, create it.
Step 2
In your sysctl.conf file, paste the following code and save it.
Code:
#sysctl.conf file
fs.nr_open=1053696;
fs.inotify.max_queued_events=32000;
fs.inotify.max_user_instances=256;
fs.inotify.max_user_watches=10240;
fs.lease-break-time=10;
fs.file-max=165164;
kernel.threads-max=525810;
kernel.random.write_wakeup_threshold=256;
kernel.random.read_wakeup_threshold=128;
kernel.panic=5;
kernel.sched_compat_yield=1;
kernel.panic=0;
kernel.panic_on_oops=1;
kernel.msgmni=2048;
kernel.msgmax=64000;
kernel.shmmni=4096;
kernel.shmall=2097152;
kernel.shmmax=268435456;
kernel.sem='500 512000 64 2048';
kernel.sched_features=24189;
kernel.hung_task_timeout_secs=30;
kernel.sched_latency_ns=18000000;
kernel.sched_min_granularity_ns=1500000;
kernel.sched_wakeup_granularity_ns=3000000;
kernel.sched_shares_ratelimit=256000;
kernel.sched_child_runs_first=0;
fs.lease-break-time=10;
fs.file-max=65536;
net.core.wmem_max=524288;
net.core.rmem_max=524288;
net.core.rmem_default=262144;
net.core.wmem_default=262144;
net.core.optmem_max=20480;
net.unix.max_dgram_qlen=50;
net.ipv4.tcp_keepalive_time=900;
net.ipv4.tcp_keepalive_probes=5;
net.ipv4.tcp_keepalive_intvl=156;
net.ipv4.tcp_timestamps=0;
net.ipv4.tcp_sack=1;
net.ipv4.tcp_fack=1;
net.ipv4.tcp_window_scaling=1;
net.ipv4.tcp_tw_recycle=1;
net.ipv4.tcp_tw_reuse=1;
net.ipv4.tcp_congestion_control=cubic;
net.ipv4.tcp_syncookies=1;
net.ipv4.conf.all.rp_filter=1;
net.ipv4.conf.default.rp_filter=1;
net.ipv4.tcp_synack_retries=2;
net.ipv4.tcp_syn_retries=2;
net.ipv4.tcp_max_syn_backlog=1024;
net.ipv4.tcp_max_tw_buckets=16384;
net.ipv4.icmp_echo_ignore_all=1;
net.ipv4.icmp_ignore_bogus_error_responses=1;
net.ipv4.tcp_no_metrics_save=1;
net.ipv4.tcp_fin_timeout=15;
net.ipv4.tcp_keepalive_intvl=30;
net.ipv4.tcp_keepalive_probes=5;
net.ipv4.tcp_keepalive_time=1800;
net.ipv4.ip_forward=0;
net.ipv4.conf.default.accept_source_route=0 ;
net.ipv4.conf.all.accept_source_route=0;
net.ipv4.conf.all.accept_redirects=0;
net.ipv4.conf.default.accept_redirects=0;
net.ipv4.conf.all.secure_redirects=0;
net.ipv4.conf.default.secure_redirects=0;
net.ipv4.udp_rmem_min=6144;
net.ipv4.udp_wmem_min=6144;
net.ipv4.tcp_rfc1337=1;
net.ipv4.ip_no_pmtu_disc=0;
net.ipv4.tcp_ecn=0;
net.ipv4.route.flush=1;
net.ipv4.tcp_rmem='6144 87380 524288';
net.ipv4.tcp_wmem='6144 87380 524288';
net.ipv6.conf.default.use_tempaddr=2;
net.ipv6.conf.all.use_tempaddr=2;
net.ipv6.conf.all.temp_prefered_lft=3600;
net.ipv6.conf.default.temp_prefered_lft=3600;
vm.dirty_ratio=90;
vm.dirty_background_ratio=80;
vm.oom_kill_allocating_task=1;
vm.overcommit_memory=1;
vm.page-cluster=3;
vm.drop_caches=3;
vm.min_free_kbytes=4096;
vm.panic_on_oom=0;
vm.dirty_expire_centisecs=1000;
vm.dirty_writeback_centisecs=2000;
vm.oom_kill_allocating_task=0;
vm.vfs_cache_pressure=10;
vm.min_free_order_shift=4;
vm.laptop_mode=0;
vm.block_dump=0;
PureMotive said:
I updated the OP with a new code (Thanks to Tiny). I just removed the semicolons. Use this version if the other does not work for you.
Click to expand...
Click to collapse
If the above code does not work for you, try this one. It has the semi-colons removed. Thanks Tiny
Code:
#sysctl.conf file
fs.nr_open=1053696
fs.inotify.max_queued_events=32000
fs.inotify.max_user_instances=256
fs.inotify.max_user_watches=10240
fs.lease-break-time=10
fs.file-max=165164
kernel.threads-max=525810
kernel.random.write_wakeup_threshold=256
kernel.random.read_wakeup_threshold=128
kernel.panic=5
kernel.sched_compat_yield=1
kernel.panic=0
kernel.panic_on_oops=1
kernel.msgmni=2048
kernel.msgmax=64000
kernel.shmmni=4096
kernel.shmall=2097152
kernel.shmmax=268435456
kernel.sem='500 512000 64 2048'
kernel.sched_features=24189
kernel.hung_task_timeout_secs=30
kernel.sched_latency_ns=18000000
kernel.sched_min_granularity_ns=1500000
kernel.sched_wakeup_granularity_ns=3000000
kernel.sched_shares_ratelimit=256000
kernel.sched_child_runs_first=0
fs.lease-break-time=10
fs.file-max=65536
net.core.wmem_max=524288
net.core.rmem_max=524288
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.optmem_max=20480
net.unix.max_dgram_qlen=50
net.ipv4.tcp_keepalive_time=900
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_keepalive_intvl=156
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=1
net.ipv4.tcp_fack=1
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_max_syn_backlog=1024
net.ipv4.tcp_max_tw_buckets=16384
net.ipv4.icmp_echo_ignore_all=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_keepalive_time=1800
net.ipv4.ip_forward=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv4.udp_rmem_min=6144
net.ipv4.udp_wmem_min=6144
net.ipv4.tcp_rfc1337=1
net.ipv4.ip_no_pmtu_disc=0
net.ipv4.tcp_ecn=0
net.ipv4.route.flush=1
net.ipv4.tcp_rmem='6144 87380 524288'
net.ipv4.tcp_wmem='6144 87380 524288'
net.ipv6.conf.default.use_tempaddr=2
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.all.temp_prefered_lft=3600
net.ipv6.conf.default.temp_prefered_lft=3600
vm.dirty_ratio=90
vm.dirty_background_ratio=80
vm.oom_kill_allocating_task=1
vm.overcommit_memory=1
vm.page-cluster=3
vm.drop_caches=3
vm.min_free_kbytes=4096
vm.panic_on_oom=0
vm.dirty_expire_centisecs=1000
vm.dirty_writeback_centisecs=2000
vm.oom_kill_allocating_task=0
vm.vfs_cache_pressure=10
vm.min_free_order_shift=4
vm.laptop_mode=0
vm.block_dump=0
Step 3
Now we need to enable it. So, navigate to /system/etc/init.d and create a file with the following code:
Code:
#!/system/bin/sh
# grep sysctl /etc/init.d/*
# Load /sys/etc/sysctl.conf
sysctl -p
sysctl -p is what initializes the code.
Just FYI: You don't actually need these lines:
Code:
# grep sysctl /etc/init.d/*
Code:
# Load /sys/etc/sysctl.conf
So this would have just sufficed.
Code:
#!/system/bin/sh
sysctl -p
If the above code does not work for any reason, try this:
Code:
#!/system/bin/sh
sysctl -p /system/etc/
Name your file something like this 10sysctl
Save your file.
NOTE: Your ROM must support init.d. You can do this by using dsixda's android kitchen
Step 4
Save your ROM and install it via recovery
OR
you could just push the files into your current ROM and try them out.
Step 5
For operating the script enter the following code in terminal emulator
Code:
su
sysctl -p
is all that is really needed to run the script. So here are some more options:
If you think that init.d is being faulty, enter in terminal emulator
Code:
su
sysctl -p
and then
Code:
sysctl -a| grep vm
What this does is manually start up sysctl.conf and then verify it with the succeeding code.
OR
Ignore what
Code:
sysctl -a| grep vm
is outputting and just see if you experience better battery life (you should)
----------- For knowledge -----------
Credits to imoseyon for portions of the info
Ok, so what exactly is sysctl.conf?
The sysctl.conf is a configuration file for "sysctl" which is an interface for dynamically changing kernel parameters in the Linux OS. The configuration file contains the following elements, vm.min_free_kbytes, vm.dirty_ratio, vm.dirty_backgroud_ratio, vm.vfs_cache_pressure, vm.oom_kill_allocating_task. There are many other elements within the file, but we will be primarily focusing on these specifically (the vm prefix stands for virtual memory). The sysctl.conf file should be located in /etc (/system/etc) by default. To enable it you need your ROM to execute "sysctl -p" somewhere during the boot process (or shortly afterward). We will also be discussing how to enable it if it is not already done so. You can also run sysctl -p manually to enable it any time after the OS is started.
Now, let’s get down to what sysctl.conf does and how it works.
min free kbytes (vm.min_free_kbytes)
This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a pages_min value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size. Default is 2048kb.
dirty ratio (vm.dirty_ratio) and dirty background ratio (vm.dirty_background_ratio)
This controls how often the kernel writes data to "disk" (in our case the internal microSD system card, not the removable microSD card). When your apps write data to disk, Linux actually doesn't write the data out to the disk right away, it actually writes the stuff to system memory and the kernel handles when and how the data is actually going to be flushed to the disk. These values represent a percentage, the higher the percentage, the longer it waits to flush, the lower the percentage, the more often flushes will occur. Now remember, we are dealing with solid state storage, not the traditional disk platter and spindle. So we are actually able to delay flushes a little longer with solid state versus a traditional hard drive disk.
VFS Cache Pressure (vm.vfs_cache_pressure)
Now here is where it gets interesting! File system cache (dentry/inode) is really more important than the block cache above in dirty ratio and dirty background ratio, so we really want the kernel to use up much more of the RAM for file system cache, this will increas the performance of the system without sacrificing performance at the application level. The default value is 100, as a percentage, and what you want to do is lower the value to tell the kernel to favor the file system cache and not drop them aggressively.
oom allocating task (vm.oom_kill_allocating_task)(enable or disable, generally in Linux this value is either a "1" or a "0," representing as on or off.)
This enables or disables killing the OOM-triggering task in out-of-memory (oom) situations. If this is set to zero, or disabled, the OOM killer will scan through the entire task list and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed. If this is set to non-zero, or enabled, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive task list scan, which can take mass amounts of time and "hang" or freeze the system.
block_dump (vm.block_dump)
This enables block I/O debugging when set to a nonzero value. If you want to find out which process caused the disk to spin up (see /proc/sys/vm/laptop_mode), you can gather information by setting the flag.
When this flag is set, Linux reports all disk read and write operations that take place, and all block dirtyings done to files. This makes it possible to debug why a disk needs to spin up, and to increase battery life even more. The output of block_dump is written to the kernel output, and it can be retrieved using "dmesg". When you use block_dump and your kernel logging level also includes kernel debugging messages, you probably want to turn off klogd, otherwise the output of block_dump will be logged, causing disk activity that is not normally there.
overcommit_memory (vm.overcommit_memory)
This controls overcommit of system memory, possibly allowing processes to allocate (but not use) more memory than is actually available.
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
1 - Always overcommit. Appropriate for some scientific applications.
2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap plus a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while attempting to use already-allocated memory but will receive errors on memory allocation as appropriate.
page-cluster (vm.page-cluster)
This controls the number of pages which are written to swap in a single attempt. The swap I/O size.
It is a logarithmic value - setting it to zero means "1 page", setting it to 1 means "2 pages", setting it to 2 means "4 pages", etc.
The default value is three (eight pages at a time). There may be some small benefits in tuning this to a different value if your workload is swap-intensive.
panic_on_oom (vm.panic_on_oom)
This enables or disables panic on out-of-memory feature. If this is set to 1, the kernel panics when out-of-memory happens. If this is set to 0, the kernel will kill some rogue process, by calling oom_kill().
Usually, oom_killer can kill rogue processes and system will survive. If you want to panic the system rather than killing rogue processes, set this to 1.
The default value is 0.
Panic is a system error that is detected by the kernel.
dirty_expire_centisecs (vm.dirty_expire_centisecs)
How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is expressed in 100ths of a second.
dirty_writeback_centisecs (vm.dirty_writeback_centisecs)
This is the interval of when the writeback daemons periodically wake up and write "old" data out to disk. It is expressed in 100ths of a second.
Click to expand...
Click to collapse
Woah.!!
Sent from my GT-S5830 using Tapatalk
Flashable ZIP
Tenfold huh? should give it a try..
EDIT (updated):
Heres a flashable zip to make things a little easier:
Instructions:
1. Reboot to CWM
2. Mount system
3. Flash
DOES IT WORK?
See for yourself
v2-04/30/2012 [without semi-colons of sysctl.conf (refer Step 2) & removed extra lines of 10sysctl (refer step 3)]
pure AWESOMENESS
Sent from my GT-I9100 using xda premium
Is it working. For ace?????
Sent from my GT-S5830 using Tapatalk 2
Anyone comfirm this working?
added to my future rom
Sure.. after 30min from the first post someone definitely will answer if it extends battery life
Let's see who'll be the first to notice that his bettery last longer
Thanks for sharing this
Is it compatible with CM9?
I installed this on my 2.3.6 based ROM and everything is smooth so far. I also ran the supercharger scripts and all 3 had no errors just in case anyone was wondering if they'd conflict with eachother.
/me Flashed,charging Batt ... ->Start
Testing ...edit with notes follows in 24h ...
Thx 4 sharing
(Edit) for me the battery jumps stopped,its more accurate...but i dont have more battery life.
Verstuurd va men ace via Tapatalk
Installed on 2.3.6 based ROM. Everything went smoothly installing. I ran the V6 turbocharger scripts and it didnt cause any errors to come up in case anyone was wondering.
Sent from my VS910 4G using xda premium
Just installed now, on CM9, Beta 8 by the GalaxyICS team.
Currently charging, and I will show a battery life screenie tomorrow and report on the performance
Downloaded, short term testing looks promising, played angry bird for 30mins, that use to drain like 10% battery, now it's only 6%. Not ten fold but still, improvement from just a file, i'll take that any day, this should come standard on all roms now
Does it works on Lewa rom?
Yes i think it was we need It appears to save battery ... Tomorrow i will do full test with full charge
ok installed 5 minutes back on Lk's I two Rom aka cyanogenmod. no problem but I notified a significant change in speed.. phone feels faster. battery backup dropped two percent in 3 minutes of edge usage. ll update this post after 5 hours.. those who want to install do it without fear its installing no bootloops no errors...
thanks for the share
---------- Post added at 08:01 AM ---------- Previous post was at 07:38 AM ----------
kohrangi said:
Does it works on Lewa rom?
Click to expand...
Click to collapse
Yes it works...
Mmm... testing... im at hospital for 2 days without my charger so... It will come handy if works.
Thanks!
Enviado desde el hospital usando Tapatalk con la mano derecha (soy surdo pero tengo suero)
A question, though: is this version of the mod any different from the original? Because the flashable zip of the original mod is bigger than the one posted here. Just curious. Anyway, I'm going to install the original. I'll come back later with answers.
AlterJack said:
A question, though: is this version of the mod any different from the original? Because the flashable zip of the original mod is bigger than the one posted here. Just curious. Anyway, I'm going to install the original. I'll come back later with answers.
Click to expand...
Click to collapse
Files sysctl.conf are the same. Original sysctl.conf contains one empty line at the end of file - that is all.
Hello!
I'm trying to enable boot console output instead of boot animation. I did not found a lot of articles and ones I got did not help me.
So why do I need it? Because my phone stuck in boot animation loop and I have no option to see what is happening. I have no adb or adb logcat and my phone does not have UART or JTAG interface to see what is wrong.
The last option is to enable linux kernel console and turn off boot animation.
To disable boot animation on cyanogenmod builds you have to add "debug.sf.nobootanimation=1" to the build.prop. For example for my S4 you need to change:
/device/samsung/i9500/system.prop
...
debug.sf.nobootanimation=1
or add BoardConfig.mk or i9500.mk
PRODUCT_PROPERTY_OVERRIDES += \
debug.sf.nobootanimation=1
And it is actually work. I have black screen instead of boot animation.
Next what you need is to enable kernel console. To do so I ran menuconfig on samsung kernel:
CONFIG_FRAMEBUFFER_CONSOLE=y
and several other flags like (fonts, framebuffer enabled) But I still see no console output. Instead of that after I turn CONFIG_FRAMEBUFFER_CONSOLE=y my device start to fail even before bootanimation (so it stuck on first welcome device name text) which means kernel crashed at boot.
Any suggestions how to enable kernel output on android devices?
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.
Hi
I rooted my Redmi 2 and installed CWM recovery then install [ CM 13 ]
it worked with me but had an annoying problem :silly:
the system reboot itself randomly ! every few minutes.
I tried to install another ROM [ Resurrection Remix ] using and didn't work
I tried two different recovery [CWM] and [TWRP] and the problem still happening
What you advise me to do
Please help me
Regards
ObadaKh said:
Hi
I rooted my Redmi 2 and installed CWM recovery then install [ CM 13 ]
it worked with me but had an annoying problem :silly:
the system reboot itself randomly ! every few minutes.
I tried to install another ROM [ Resurrection Remix ] using and didn't work
I tried two different recovery [CWM] and [TWRP] and the problem still happening
What you advise me to do
Please help me
Regards
Click to expand...
Click to collapse
I'm facing a problem almost like that.
Searched a bit, downloaded the kernel log and found that is a kernel panic caused by the modem crashing (Whenever a turn on the mobile data of the SIM card operator X) (No, doesn't matter if it is on slot 1 or 2)
So every time I reboot I gotta quickly disable the mobile data and disable the kernel panic so I can use the phone normally
With your super user terminal
try {
sysctl -w vm.panic_on_oom=0
sysctl -w kernel.panic_on_oops=0
sysctl -w kernel.panic=0
}
Lennoard said:
I'm facing a problem almost like that.
Searched a bit, downloaded the kernel log and found that is a kernel panic caused by the modem crashing (Whenever a turn on the mobile data of the SIM card operator X) (No, doesn't matter if it is on slot 1 or 2)
So every time I reboot I gotta quickly disable the mobile data and disable the kernel panic so I can use the phone normally
With your super user terminal
try {
sysctl -w vm.panic_on_oom=0
sysctl -w kernel.panic_on_oops=0
sysctl -w kernel.panic=0
}
Click to expand...
Click to collapse
Could you please explain how to disable the mobile data and disable the kernel panic ?
ObadaKh said:
Could you please explain how to disable the mobile data and disable the kernel panic ?
Click to expand...
Click to collapse
I'm disabling the mobile data just because it is causing the kernel panic
Soooooo, in order to enable the mobile data safely, I must disable the kernel panic (Which actually does the reboot)
To do so:
Install a terminal emulator (Play Store)
Open it, type su hit enter
Grant root
Type these lines in sequence and hit enter in every
sysctl -w vm.panic_on_oom=0 hit enter
sysctl -w kernel.panic_on_oops=0 hit enter
sysctl -w kernel.panic=0 hit enter
You don't need to reboot.
ObadaKh said:
Could you please explain how to disable the mobile data and disable the kernel panic ?
Click to expand...
Click to collapse
Much simpler method
Download L speed app from playstore
And complete the tutorial
In the tutorial tick advanced options
On the first page u will find disable kernel panic option enable it and done.
My wife's one year old Redmi 2 Prime seems to have developed the same problem as OP's. It reboots randomly. Tried different ROMs numerous times as well as Fastboot flashing clearing everything. Didn't help. Then found this thread and tried L Speed with "disable kernel panic" option enabled. Phone keeps rebooting.
Wife noticed several times that back of the phone got quite hot with no clear reason. She never plays games etc. Just browses the internet on wifi/4G and messaging. I wonder if it's a hardware problem and it's only good for trash bin. Or maybe something can be done with it.
Not found
Lennoard said:
I'm disabling the mobile data just because it is causing the kernel panic
Soooooo, in order to enable the mobile data safely, I must disable the kernel panic (Which actually does the reboot)
To do so:
Install a terminal emulator (Play Store)
Open it, type su hit enter
Grant root
Type these lines in sequence and hit enter in every
sysctl -w vm.panic_on_oom=0 hit enter
sysctl -w kernel.panic_on_oops=0 hit enter
sysctl -w kernel.panic=0 hit enter
You don't need to reboot.
Click to expand...
Click to collapse
Command returns not found each time
Vikasthedevil said:
Command returns not found each time
Click to expand...
Click to collapse
You dont have busybox installed
Install AICP ROM with Gapps arm/7.1/pico
Lennoard said:
I'm disabling the mobile data just because it is causing the kernel panic
Soooooo, in order to enable the mobile data safely, I must disable the kernel panic (Which actually does the reboot)
To do so:
Install a terminal emulator (Play Store)
Open it, type su hit enter
Grant root
Type these lines in sequence and hit enter in every
sysctl -w vm.panic_on_oom=0 hit enter
sysctl -w kernel.panic_on_oops=0 hit enter
sysctl -w kernel.panic=0 hit enter
You don't need to reboot.
Click to expand...
Click to collapse
I tried your method, but the problem still persists. Have flashed many ROMS but same prob.
This Redmi 2 is my daily driver and my only working phone. Pls help me.
Im currently on AEX 3.2
UPDATE: The terminal returned "not found", fixed by installing busybox.
I have entered the commands via adb shell,hope this works
UPDATE: Do I need to repeat same process everytime I reboot? Cos the phone rebooted again today