[Android General] smtddr:
My phone is the BLU Life One, Android 4.4.4. Kernel 3.10.28. Build KTU84P. Custom build version BLU_XO11Q_V04_GENERIC 14-08-2015 12:15. Model Number BLU LIFE ONE. Processor info. Qualcomm Technologies, Inc MSM8916

EDIT:

Forget & ignore all mentions of my script(s) to keep the microsd from umounting. Whatever is causing this problem is stopped if the microsd is remounted as read-only.

If you adb shell into your phone then type "mount" you should see all mounts related to your microsd card. For my phone, that is sdcard1.

/dev/fuse /storage/sdcard1 fuse ro,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:65 /mnt/media_rw/sdcard1 vfat ro,dirsync,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

You'll need root, then do:

mount -o ro,remount /mnt/media_rw/sdcard1
mount -o ro,remount /storage/sdcard1

That's it. Since 99% of the time I'm just listening to music not actively needing write-access to the microsd, this works perfect for me. I use this app: play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en to manage 2 scripts. One to mount it as read-only like the commands above, and another to mount it read-write again(just change "ro" to "rw"). If you want, you can jump to update#23 for the kernel source of this phone http://xdaforums.com/showpost.php?p=64906734&postcount=8 and continue reading to follow my adventures of trying to update the kernel.

echo -------------------------
id
echo -------------------------
cd /storage/sdcard1
while true; do
ls -la . > ./ls_la.log 2>&1
sleep 1
ls -la . >> ./ls_la.log 2>&1
sleep 1
rm ./ls_la.log
sleep 10
done

First, note that the "/storage/sdcard1" is where my phone mounts the microSD to. Your phone might be different, be sure to change it to wherever your phone mounts the microSD to. That last adb shell command to run the script will hang because it's an infinite loop. You'll just have to yank out the usb-cord of your phone to break the connection. On my phone, the script continues to run. I know this because using a file-manager on the phone I can constantly refresh the file list on my microSD and see the logfile appear and disappear in 10-second intervals.

So with all this I start the music in my musicplaying app(poweramp in my case), press the power button to turn off my screen.... press the power button again to turn on the screen and see the lockscreen.... then leave my phone alone. Within 10 seconds, the screen goes off by itself if I don't enter a pin... and the music will play without any glitches or interruptions.

CONS

If my phone ever reboots, I need to go back to a PC with "adb" so I can rerun the command. This app: play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en ....can run the script but the user the script is started with doesn't have write-permissions to the microSD card for whatever reason. I have this problem because my phone is NOT rooted. I rooted it once before, but then used SuperSu's option to "unroot" and since then haven't been able to root again. If you have root, I'm sure a command like "su -c '/data/local/tmp/crazy_sdcard_wakelock.sh'" would start the script as root and it'll be able to write to the microSD. ......I rarely reboot my phone, so this isn't a big issue for me.

How did I come up with this?

Random googling about this problem lead me to a bunch of people talking about it on different devices with different symptoms: code.google.com/p/android/issues/detail?id=22763 , but more or less the same core issue. When the screen is off for awhile(for me it's 30mins), the microSD is unmounted apparently by faulty power-management in Android's OS or Manufacturer's hardware or whatever and if you're like me with tons of music on the microSD... your musicplayer(PowerAmp or whatever), stops working. So I started thinking about all the ways to prevent the microSD card from unmounting. On my home PC, running Linux mint, a mounted USB device cannot be unmounted if there's a bash process that is using it; i.e. if I open a terminal and "cd" to a directory on the usb-drive, I cannot unmount it until I exit that bash shell. That's why in the above script I do the cd command to the microSD card hoping for the same effect on Android. Then you see the infinite loop of "while true", where I repeatedly do:

I run "ls -la" to print out all details of files & folders at the root-level of the microSD card and save the output to a logfile.

I pause for 1 second.

I run "ls -la" command again, and append the already existing file so now the list is in that file twice.

I pause again for 1 second.

I delete the file

Pause for 10 seconds... then do it all again, and again, and again...

With a shell process having the microSD as its CWD and the constant opening, writing, deleting of a file every 10 seconds, along with the PowerManagerWakelock app and the periodically CPU usage reporting.... I've been doing this for a full day and the music never stops, no sdcard unmounting. This is the microSD I'm using: amazon.com/SanDisk-Mobile-MicroSDXC-Memory-Adapter/dp/B0081EAK34

I haven't done any testing to try and narrow stuff down to see if I truly need all 3 of these things to be running, but I don't care. It works for me and my battery life doesn't seem to be draining any faster than normal.

I'm posting this solution so maybe the hackers on this forum can understand exactly why my solution is working and maybe write an apk that'll do all this stuff by just tapping a button. :D

UPDATE:

Got root back by booting into TWRP(Installed before I removed root the first time) and flashing a SuperSU.zip to the device. Disabled the "Show CPU usage" and the solution still works. Using the PowerManagerWakeLock app by itself does _NOT_ work. So right now it's WakeLock+Script that seems to be working. Who knows, maybe the script will work all by itself. But I haven't tried it yet. Now if I reboot my phone, I can use the script-manager app mentioned above to run the script as root and it does keep the microSD mounted and everything works. I also added the "date" command to my script so in case it stops working, the scriptManager's console will show me the last time it worked before problems occurred. But, so far so good no problems and my buyer's regret on this phone is long gone. I hope other people see this post because I see a lot of people complaining about similar problems with other Android phones.

If this works for you, please reply and say so! :D

UPDATE#2

Just spent the whole day listening to uninterrupted music using only the script. So there you go! I was trying to find a way to do this without root using the ScriptManager app, I tried copying the /system/bin/sh file to /data/local/tmp and setting the sticky bit on it; but sticky bit logic doesn't seem to work for me on Android. So if you don't have root, you have to launch the script via "adb shell" command on a PC and don't reboot or do anything that stops the script.

UPDATE#3

So it appears that both Poweramp playing music and the script are required. If I stop playing music the script starts getting I/O Errors and "Transport endpoint is not connected" errors after like 4 hours or so. Kinda lame. And when this happens I have to reboot the phone to get the sdcard back. I suppose this means, be careful if you set the phone's camera to write to the microSD. You might find out later that photos and videos you thought you were capturing didn't actually get saved to the microSD. Should probably have camera save to internal memory then later on copy to microSD using the filemanager and verify that the copy actually worked before deleting from internal memory.

UPDATE#4

In an attempt to keep the sdcard mounted even if there's no music playing, I decided to add the "du" command thinking that command needs to do a lot to the sdcard to get its info. The result? After 3 to 4 hours, the card still went offline and all of its content erased! Luckily, I made a backup because I knew I was dealing with sdcard problems on this phone. So, what I think needs to happen now is to write a script that can somehow detect if the phone is idle for about 2 hours. Idle in this context means, screen off for 2 hours and no music playing... to automatically unmount the sdcard safely instead of whatever happened that causes me to lose everything. Or maybe after detecting idle-state, unmount & remount the sdcard to wake up whatever hardware/software components went to sleep. If that works, then perhaps just keep remounting the sdcard every 2 hours the phone is in an idle state. But so far, my original solution works in that as long as you're listening to music & running the script above there will be no interruptions for at least 8 hours straight.

UPDATE#5

Well, I can now reproduce 100% the sdcard umounting. If I set my phone's display to go off in 2mins of idle time, and immediately lock with pin. Then start Poweramp and listen to tunes, once the screen goes out the music will stop in less than 20 seconds and the sdcard is gone. If I run that script above, then the music continues and the sdcard is still there... so definitely that script is doing something. I see nothing suspicious running logcat while all this is happening other than the normal calls to PowerManager:

I'm learning a lot of stuff about Android and sdcards in this phone. Informative commands, like:

dumpsys mount & dumpsys power, Also interesting processes:

Still looking around to see if I can figure out why it unmounts, or prevent it from unmount, or immediately remount it as soon as it disappears. I've noticed that when the glitchy-unmount happens, the status in "dumpsys mount" does not update. It still shows /storage/sdcard1 as mounted.

UPDATE#6

Okay, getting closer to narrowing it down. Definitely the music stops and sdcard problems when I tamper with the process related to the sdcard. From the example above, PID 8948, /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1. If I send that process a kill -9, the process immediately respawns with a new PID but within the next 20secs the music will skip. If I send a kill -STOP to that process, the music will halt completely and the sdcard access will be messed up within 20 seconds. I can return normal sdcard access by sending kill -CONT to the process. I've haven't verified it yet, but I bet something happens to that process when the sdcard unmounts suddenly and everyone is complaining about the problem. My 100% repro to make the sdcard unmount has stopped working so I can't quickly verify any changes in any attributes to files in /proc/$PID/. I've also just found this nice website with informative stuff: hxxp:\\source.android.com/devices/storage/config-example.html

UPDATE#7

So after a lot of research, I extracted the boot.img(/dev/block/bootdevice/by-name/boot) from this device, unpacked it, edited init.qcom.rc to start the sdcard service for the microSD using a different binary I named sdcard_studio6. I pull this file from my wife's BLU Studio6 phone. From just about any other android device I had around, the sdcard binary would complain about a missing symbol or something. I couldn't just replace the original sdcard binary, because doing that would mount the external microSD but won't mount the internal phone memory and logcat would be overflowing with fuse errors from sdcard. So I have to leave the original sdcard binary to work with all the other mounts, but only modify the service/deamon for the external storage. After rebooting the phone and running "ps|grep sdcard", sure enough I see the sdcard_studio6 binary handling the microSD. Interestingly enough, the custom_boot.img created by my editing was only 7 megs. Compared to the 32 meg one I got from doing dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.backup.img That was worrying, but apparently it works fine.

NOTE: I feel it's important to point out that the command "fastboot" can be used in 2 ways for booting. "fastboot flash boot /path/on/your/PC/to/boot.img" or "flashboot boot /path/on/your/PC/to/boot.img". The first command actually writes the change into your phone's memory, the 2nd command just uses the file to boot up the phone temporarily and holding down the power button for a few seconds to force powerdown & reboot will cause the phone to go back and use the image that's in the phone's internal memory. One of the times I did this i forgot to give mkbootimg a bunch of important options like --cmdline, --base, --pagesize, --ramdisk_offset, etc. When I booted the phone with the image I created, the phone was stuck on the white BLU logo screen and neither fastboot nor adb could detect the phone. Had I flashed that image into the phone, instead of temporarily loading it, the phone would have continued to use the bad boot.img and without fastboot or adb, I think I would have had a nice $189.99 brick. Moral, don't flash a boot.img permanently until you've booted up in temporary mode and used the phone a bunch and you're sure everything works. At the minimum, be sure adb or fastboot can still see it so you have some hope if things screw up later.

Unfortunately, this didn't solve the unmounting problem. I've started checking dmesg and noticed that when the sdcard disappears, it's shortly after these messages:

I should also note this entire issue with the sdcard doesn't happen with my old 32GB card, only with the 2 brand new sandisk 64gig cards that I bought to test this out. It's difficult for me to believe that both of these 64gig sdcards are defective. And both didn't come from the same place. One from amazon.com the other from walking into a Target store in San Francisco and buying it. And both these cards work fine in other devices. Still working on some kind of solution.

UPDATE#8

I noticed that sdcard binary on my phone actually prints out usage:

shell@BLU_LIFE_ONE:/ $ /system/bin/sdcard
no source path specified
usage: sdcard [OPTIONS] <source_path> <dest_path>
-u: specify UID to run as
-g: specify GID to run as
-w: specify GID required to write (default sdcard_rw, requires -d or -l)
-t: specify number of threads to use (default 2)
-d: derive file permissions based on path
-l: derive file permissions based on legacy internal layout
-s: split derived permissions for pics, av

So I tried editing my init.qcom.rc to start with more threads; like 14.... still the problem remains that a screen off will cause the music to stop eventually.

UPDATE#9

Sending kill -STOP to the vold process seems to be working!

After messing with the sdcard binary for awhile I saw this link: hxxp://android.stackexchange.com/questions/75277/vold-makes-my-sd-card-disappear , and started researching /system/bin/vold. I do actually remember seeing vold & MountService unmount the card in logcat at least once. I thought about disabling vold in the init scripts, but it appears it's super important and disabling it will just make everything fail. I tried killing the process but it will restart and I suspect it'll eventually be needed again. I did notice that if I have music playing and I adb shell, su, "/system/bin/vold root", my music player will stop and I have to hit the play button again. I have a theory now that there are actually 3 issues here happening all at the same time confusing people and 2 of them are sorta red herrings.

Theory 1) If you buy a no-name-brand sdcard you might have problems. Don't do that, try to get a good card like those class 4 or even class 10. Having a low quality microSD can send you down the path of madness. It's just a red herring; get a good card before reaching any conclusions that you phone has any problems.

Theory 2) I now suspect some microsd card reading errors are normal. e.g. <3>[ 1864.781982] mmcblk1: error -84 transferring data, sector 87944020, nr 256, cmd response 0x900, card status 0xb00

, is probably something that'll happen from time to time and the underlying filesystem drivers and/or AndroidOS normally recovers from them as long as it doesn't happen way too often. This is the 2nd red herring I think people should just ignore unless there's a whole bunch close together all the time. In which case I think the microSD card is bad or your phone is bad. I think the phone being bad is very unlikely unless you bought a cheap counterfeit junk phone like..... "HTM Demon". Yes, "M", not "C". I have one from Aliexpress. It's junk.

Theory 3) For some reason unrelated to anything else, vold randomly decides the microsd is idle and tells the MountService to unmount it. When that happens, then you get:

....and these are serious errors, but these errors didn't cause the unmounting. It's the vold unmounting that happened first which then creates these errors.

So, now I have 2 scripts: stop_vold.sh & resume_vold.sh

#
#This script stops the vold process. Not kill it, just suspend it so it cannot do anything.
#
ps vold
VOLD_PID=$( ps vold | grep -v PID | busybox awk '{print $2}' )
echo "[*] Sending KILLSTOP signal to PID $VOLD_PID"
kill -STOP $VOLD_PID
if [ $? -eq 0 ]
then
echo "[*] Success"
else
echo "[*] Problem sending KILLSTOP"
exit 1
fi

Then resume_vold.sh

#
#This script resumes the vold process.
#
ps vold
VOLD_PID=$( ps vold | grep -v PID | busybox awk '{print $2}' )
echo "[*] Sending KILLCONT signal to PID $VOLD_PID"
kill -CONT $VOLD_PID
if [ $? -eq 0 ]
then
echo "[*] Success"
else
echo "[*] Problem sending KILLCONT"
exit 1
fi

You need to be root to have permissions to suspend the vold process.

Also, you need busybox to be installed for that "awk" command. Most of those rooting kits out there have the busybox binary. Just make sure it's in /system/bin or /system/xbin, owned by root with permissions rwxr-xr-x.

Side Effects of a stopped vold process:

Here's what I've noticed so far. To avoid these issues, make sure to resume vold before doing any of the following:

- Since the vold process, apparently responsible for important storage/volume changes, is stopped...... if you do anything that makes Android call to vold to update storage info... it'll hang and go into a soft-reboot cycle. Soft, because while it keeps rebooting itself trying to get unstuck you can be in an adb-shell and it won't disconnect. The restart-loop can be fixed by either sending a kill -CONT to the vold process or holding down the power button on your phone for 10 seconds to force it to power-down for real. Then on bootup everything will be back to normal. So, connecting the phone to a PC or attempting to mount or unmount the sdcard in Settings->Storage->Un/MountSdCard is probably going to lead to trouble if vold is stopped when you attempt them.

- App installs/updates will cause the phone to freeze for about 45 seconds.

That's it, I think I like this solution the most. No more file writing every 10 seconds and no problems leaving the device to play 6 hours of music uninterrupted then sit idle for another 4 hours. I'll update this post again if I find a problem, but if not then I'm happy with this solution. -^_^-

UPDATE#10

After about 2 days, this stopped working. Instead of the microSD card unmounting, all the content just becomes invisible and phone says the card is 0kb used and 0kb available. After resuming the vold process, Unmounting and remounting in the Settings->Storage will report damaged card. Rebooting the phone makes the card work again and show all its content. Coincidentally, this is also when I added a bunch more music beyond the 32gig used marked. I'm starting to think the reason phone manufactures say the phone can support up to 32GB when bigger cards are detectable by Android, is because they know anything more than 32gb is like overclocking a CPU. You might be able to get a bit more performance but you also might just run into more errors. None of these microSD card problems happen with my 32gb card. Maybe if I got a class 10 64gb card this would work better. The fact that my ls-la script is still a working solution gives me hope that there's a more elegant solution to be found.

dmesg:

Notice how the card disappears and apparently is re-detected after about 1 second, but it's empty and with 0kb capacity.... and during all this vold is still suspended so maybe that's why everything about the card is zero.

logcat:

I wish I could find whatever that "mmc" process is. Still looking for answers...

UPDATE#11 is below in another comment. http://xdaforums.com/showpost.php?p=64522019&postcount=4

That is all.