fix Android memory full boot loop soft brick bug

IllegalStateException:
"Cannot broadcast before boot completed"
log:
"Running low on memory. Sending notification"

perhaps this is the most ridiculous bug that annoyed many Android users, especially normal users. if i were not able to find the root cause of this bug, i think i would have to reformat the whole device and start to pray. just can't believe it is still there in Android 4.1.2



what is this about?

during the boot process, the checkMemory function will be called to see if your memory (disk space) is full or nearly full. if this is the case, it will send a "Phone storage is full. Delete some files to free space." notification to the users telling them the device is running out of memory (space). thus, users will be alerted by this notification message which, supposedly, shown as a ticker in the status bar

but for some reasons, all notifications will be "checked" by the verifyBroadcastLocked function before sending to the users by showing a message in the status bar, for instance. the "checking mechanisms" include the status of the device, like whether the phone is booted up already. this is very straight forward since it will be pointness to show any notification if the phone is not booted up yet. these notifications will be dropped or should be queued up and will not be sent to the users until a proper time has come. in this case, screen is on or the home screen (desktop) is drawn could be regarded as a proper time



why is this happening?

if one boots up his device which the memory is neary full, then during the boot process the checkMemory function will send a notification to inform the user about this and logged as "Running low on memory. Sending notification". however, since the device is not booted up yet, the verifyBroadcastLocked function will not allow to send this notification for the reason that the boot process is not yet comlpete and throw an IllegalStateException "Cannot broadcast before boot completed"

when this fatal IllegalStateException is sent by verifyBroadcastLocked and received by the system, the boot process will be crashed. this crash event alerts the system that the previous attempt to boot was a failure, which in turn will try to boot the system again. now the device will begin to boot again and during this second boot, the checkMemory function will send a memory low notification again, followed by another "Cannot broadcast before boot completed" IllegalStateException and hence, a boot loop (some describe as soft brick) is created, as illustrated in a simple flow chart as below:

booting up --> low memory/memory full --> send notification --> notification dropped and IllegalStateException thrown --> failed to boot --> try to boot up again --> booting up --> low memory/memory full ...... --> fail to boot --> try to boot up again ......


so if your phone enters a boot loop for unknown reason, try to take a look at the log. if you find something like "Cannot broadcast before boot completed" or "Running low on memory. Sending notification" in the log file, you will know why and how to solve it



how to solve this problem?
1/. always keep an eye on your phone and make sure you have "sufficient" memory (disk space). unfortunately, the word "sufficient" is defined by Google, the programmers, the manufacturers, etc, which could be 2%, 5%, 10% of the total available memory, and can be different in different Android versions, different firmware versions, etc

2/. modify the sending low memory notifications process by:
a) removing sendNotification in checkMemory function in DeviceStorageMonitorService
b) handling the IllegalStateException thrown by verifyBroadcastLocked in ActivityManagerService in a better way


for me, i opted to disable the sendNotification in DeviceStorageMonitorService.smali found inside services.jar as temporary solution. here's how to (based on stock I9300XXELKC):


[i] find the lines that read like:

const-string v2, "DeviceStorageMonitorService"

const-string v3, "Running low on memory. Sending notification"


[ii] remark the following lines a few lines after [i] (line 229 and 230 in my case, may be differnet for you):

### low memory --> boot loop bug --> Cannot broadcast before boot completed
.line 229
#invoke-direct {p0}, Lcom/android/server/DeviceStorageMonitorService;->sendNotification()V

.line 230
#iput-boolean v7, p0, Lcom/android/server/DeviceStorageMonitorService;->mLowMemFlag:Z


by commenting or removing these lines, no memory full notification will be sent but a log will be printed to the system log, and the memory full boot loop bug can be avoided

freeNANDmod - get more space from NAND - PART III

Since the day I understood how Galaxy S works with Android about a year ago, I always ask myself why it is designed like that. So I spent a few months to modify the systems to suit my own needs with tons of modifications. Although Samsung changed the system a bit in recent roms and rectified some problems like inadequate size for the /cache partition, there are still a lot of improvements need to be done.

Among these, the most frustrating thing, in my opinion, is the way how Samsung/Android treat the modem. Why should we waste the invaluable 12.5MB for storing the modem.bin in the NAND drive as a temporary storage? So I tried to move it elsewhere but found that the location of the modem.bin is hard coded in the boot loader. More, the loading of the modem file is performed by the bml utils which reads the modem.bin from the nand drive and put it into the memory during the init process. Unfortunately, I was unable to change this due to I am not an expert in C and they are not open sources (althought I discovered some related source files at a later stage).


freeNANDmod

Finally, I found a way to remove the modem completely from the nand drive and freed the extra 12.5MB when I tried to free some more nand disk space for my own use. This finding, together with the mod for the nand drive partitons (let's call it freeNANDmod :D), allows us to get more free nand disk space available for faster reads/writes. And what it does actually is to make more room in the nand storage for larger partitions, by moving the traditional partitions in the nand disk to and from the mmc disk.

Although it looks like easy enough to move the partitions around, there are some more works needed to reflect these changes to the system. The obvious thing is to handle the new partition layout so that the system will get the right partition when needed. It is not a difficult task for me, and since I modified my system to run on loop devices, I already have my own mount and umount processes/scripts to override the system's. However, for most of the rom modders, they will need to find a way to tell the system where and which the partitions are, since afaik, they dont' have to care about this before.

Other areas which required attentions include, but not limiting to, making sure the rom and subsequent files can be written to the correct partitions during rom reflashing while maintaining your new layouts, as well as handling these info in the recovery process or otherwise neither the stock recovery nor cwm recovery will work properly especially if you made changes to the /cache.

You may ask at this point, "So what did you do to the layout and how can we benefit from your mod?"
Let's take a look at my current partitions snapshot:

device name	mount point	size in MB	location
/dev/block/stl10	/dbdata	444	NAND
/dev/block/mmcblk0p1	/mnt/sdcard	13757	MMC (unchanged)
/dev/block/mmcblk0p2	/data	1408	MMC
/dev/block/mmcblk0p3	/system	370	MMC
/dev/block/mmcblk0p4	/cache	105	MMC

As you can see in the table above, I have one single partition with 444MB available on /dbdata. It is 4x compared with the stock version (134MB with s1_odin_20100512.pit). You can also find the /system and /cache partition are moved to the mmc disk, for the reasons that:
- the /system holds read only files usually (that's why it is mounted as read-only by default), therefore the writing speed to /system can be ignored
- for those files reside on /system that require faster read, you can always put them in the new /dbdata instead
- the /cache now is a dummy partition which require limited reads/writes, and can be completely removed in case you want to handle it yourself during the boot process

PS I am not following S2's. I have made these changes for about 2 months and I only realized the /system in S2 is located at mmc also about 2 weeks ago

* wearing and tearing is not taken into account and will not be discussed



read more:
Free more available disk space from NAND - PART I
Free more available disk space from NAND - PART II
freeNANDmod - get more space from NAND - PART IV

reserved memory settings for Galaxy S I9000 in Gingerbread 2.3.3 (I9000XWJVB)

ok guys, time for tweaking the mem thing again. may be u have wondered about why there is no FIMC0/FIMC1/FIMC2 etc in the default config for 2.3.3 (me at least)... so, as usual, i started to take a look at this

for those who have no idea where to change the reserved memory settings, take a look at arch/arm/mach-s5pv210/mach-aries.c and you will be delighted to get them back, plus some interesting things

the default settings for movies play back for general I9000 is:
S5PV210_VIDEO_SAMSUNG_MEMSIZE_MFC0 (35840 * SZ_1K)
S5PV210_VIDEO_SAMSUNG_MEMSIZE_MFC1 (35840 * SZ_1K)

while, for NTT, the settings for "1080p support" is:
S5PV210_VIDEO_SAMSUNG_MEMSIZE_MFC0 (36864 * SZ_1K)
S5PV210_VIDEO_SAMSUNG_MEMSIZE_MFC1 (36864 * SZ_1K)

u'll find also what we used to tune in froyo like:
VIDEO_SAMSUNG_MEMSIZE_FIMC0
VIDEO_SAMSUNG_MEMSIZE_FIMC1
VIDEO_SAMSUNG_MEMSIZE_FIMC2
VIDEO_SAMSUNG_MEMSIZE_JPEG
VIDEO_SAMSUNG_MEMSIZE_PMEM
VIDEO_SAMSUNG_MEMSIZE_GPU1
VIDEO_SAMSUNG_MEMSIZE_ADSP


i've conducted a few tests with the min values for 1080p support but up to now, i do have the answer yet, nor the max available mem in Gingerbread this time. however, i can show you some of the rough values required for 1080p playback:


NOTE THAT THESE VALUES ARE NOT YET OPTIMIZED

MFC0: 36864
MFC1: 36864
FIMC0: 12288
FIMC1: 9900
FIMC2: 12288

boot up Samsung Galaxy S I9000 in 19 seconds

Galaxy S I9000 2.2.1 JPY with my mods and lag fix
- boots up in 19 secs
- no overclock, stock cpu frequency
- lightening fast to open and scroll 1000 sms messages
- 353 mb available memory



watch original movie clip in youtube

memory tweak 1: 356MB visible 258MB free

just performed some tests with different reserved mem sizes (stock kernel ZSJP8) for your ref

default settings:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=16384
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=10240
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=14336
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=36864
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=36864
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=5012
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240



1/. minimum (almost) reserved mem with movie playback possible (no lag in youtube), 356mb memory, no special lags observed, opened 4 tabs in browser with lots of imgs and swfs



CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=4096
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=6144
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=6144
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=29696**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=29696**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=3072
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=2048

** min value in order to play movies = 29mb, 28mb wont play
## can be set to a lower value without movie playback, setting these with too low values caused problems, below 20mb should be ok


2/. nearly double all default values, 219mb available, didnt feel faster




as to min mem usage, u'll need to (in brief):
1/. remove unneccessary apps
2/. remove startup/network chg broadcast listeners from the app - a lot of apps/services are launched at startup up or network state chg, remove them so they wont start automatically, eg gtalk, sync/feed, vold service, installd, etc
3/. kill unneccessary services & processes - i didnt use any killer since i rooted my phone, i use script to kill them since killers consume more mem
4/. i have read the source and found that only -Xmx (max mem) is included but no -Xms (initial mem), perhaps we can do something here (not done yet)


test2: available memory - 257.68mb




reference for 2.1
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=10240
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=10240
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=24576
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=24576
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=8192


more info