Root Proposal/Theory for External SD storage solution on F6

[WarrantyVoider]

OK, some people have been waiting for a sensor fix and a file system checker. I rarely encounter the sensor issue and I haven't run into the file system error issue. I was trying to reproduce those problems for testing, but it'd take some time. So instead, if some testers want to try these out and let me know if they fix the problems, it'd save me a lot of time. Thanks.

Four files:
-sensorfix.zip
You don't need this if your sensors work after a reboot. This is for people whose sensors only work sometimes or not at all after reboots. Flash once to install a script. The script should automatically run at every boot.

I think I've said there might be a cleaner solution to the sensor issue. Well, it turns out to be a complicated situation. It'd make the solution a lot more complex. So this file is based on the workaround proposed by likwid2 (#234). It simply restarts sensord if it's already loaded. Now, sensord isn't universal (doesn't exist on all phones/tablets) but for this phone it probably exists on all roms. Let me know if this is not the case.

-fsck-ondemand.zip
This simply checks the 2nd partition (with ext4) on the SD. You run it manually when your file system has errors so that the partition can't be mounted. It does not install anything. This basically runs "e2fsck -y /dev/block/mmcblk1p2" which is the way Android checks the internal partition. It will force-correct file system errors, but understand that there might be data loss.

It might be possible to make a file system check at every boot or when mounting fails. But really file system errors should not occur frequently at all, or otherwise you're at constant risk of data loss. So if an on-demand checker is not enough, perhaps let me know your situation so I may understand why file system errors occur more than they are supposed to. Maybe the way ext4 writes journal+data causes problems with SD's large erase blocks or something.

-uninstall.zip
The uninstaller is updated to also remove the sensor fix if that's installed. So if you use the sensor fix, replace the old -uninstall.zip with this. I forgot to test this. I will fix it if I discover a mistake later.

-restore.zip
This is an update to the -restore.zip in #460. There was a minor bug in the old one. I mistakenly used a default command (Android toolbox's "chcon") instead of the busybox version. The effect was that the selinux label (so only for KK) for one particular directory would be set incorrectly after a restore. Sorry about that.

Edit: Check the -sensorfix version in #505, which adds a 1-second delay between stopping and starting sensord.

 

[WarrantyVoider]

I've successfully utilized these scripts and zips on multiple handsets, several ROMs and stock systems.

If you don't mind letting me know which devices and roms you've successfully used the scripts/zips, it'd be great to know what systems are compatible. Thanks.

 

[catchingup]

awesome work. I'll test those scripts on my old class 4 card for giggles, but after I play with the class 10 I'm getting tomorrow.

One question.... If I want to restore the phone back to bone stock, do I have to uninstall this hack first?
Or can I just do the Power+Volume and it will wipe out the hack ?

 

[mightyman620]

I tried the init.d script on both CM11 and hroark13's D505-based KK. I saw increased /data, but I didn't test anything else. If it doesn't work for you, check to see if you have a folder /cache/DataOnSD. Delete it if you do. Or just wipe cache. Anyway, while looking at it, I changed two minor things. 1) The new /data now gets the same selinux context as the old /data and 2) the new /data gets the same mount options as the old /data. I don't think these changes matter too much, but what the script does is now more correct, so to speak.

The script you showed tries to mount the same thing directly to /data twice (/dev/block/vold/179:34 and /dev/block/mmcblk1p2 refer to the same thing). I didn't choose to mount directly because I don't want to ignore the possibility the partition is not the right one (i.e. no tag file). If I mount the partition, find no tag, then unmount, there's a chance, even if a very tiny one, that another process accesses /data between the mounting and unmounting. What I do is to mount at a temporary mount point, do a bind mount to /data, and then unmount the temporary mount point. So functionally, there isn't too big of a difference.

As for the binary method, I'm glad to report that with your help, I got it working as well. There were two major issues. One is that partition didn't mount, even when using debuggerd. It turns out selinux has labels that my old code didn't expect. Once I understood how my code reacted to the labels, it was an easy fix. The other issue is using vold prevented booting. Like we've discussed, targeting debuggerd, which would be less restricted than vold, was an alternative. But I wanted to do it the hard way so that future, more locked-down versions can't stop me. So I figured out the proper permissions to get vold to load. From there, I operated within the rules that vold must follow and things worked as they should.

The init.d script is loaded quite early in the two roms I tried so it should hopefully not cause issues with other processes. For roms without init.d support, the binary method hopefully provides the same result. I did not have time to test compatibility with other hw/sw components or apps, or to try these new files on any JB roms. I'm not as proficient in testing, so if you or anyone feels like doing that, let me know your findings. Thanks.

Note: for SELinux-enabled (say, KK) roms, use TWRP to flash. For other (e.g. 4.1.2) roms, either CWM or TWRP should be okay. As before, -initd.zip includes file copying but no uninstaller. Its file copying method is the same as the one used by -copy.zip so the files are compatible. To uninstall the init.d script, just delete /system/etc/init.d/00DataOnSD. To wipe "data" (files on external partition) between different roms, format the partition or remove all files. Alternatively, remove the tag file, let the rom sets up its /data on internal storage, and then use the copier script.

WOW man you are a genius it worked . I just flashed the init.d zip now I have over 10 GB internal storage Thank you you are the man

 

[crutchcorn]

I tried the init.d script on both CM11 and hroark13's D505-based KK. I saw increased /data, but I didn't test anything else. If it doesn't work for you, check to see if you have a folder /cache/DataOnSD. Delete it if you do. Or just wipe cache. Anyway, while looking at it, I changed two minor things. 1) The new /data now gets the same selinux context as the old /data and 2) the new /data gets the same mount options as the old /data. I don't think these changes matter too much, but what the script does is now more correct, so to speak.

The script you showed tries to mount the same thing directly to /data twice (/dev/block/vold/179:34 and /dev/block/mmcblk1p2 refer to the same thing). I didn't choose to mount directly because I don't want to ignore the possibility the partition is not the right one (i.e. no tag file). If I mount the partition, find no tag, then unmount, there's a chance, even if a very tiny one, that another process accesses /data between the mounting and unmounting. What I do is to mount at a temporary mount point, do a bind mount to /data, and then unmount the temporary mount point. So functionally, there isn't too big of a difference.

As for the binary method, I'm glad to report that with your help, I got it working as well. There were two major issues. One is that partition didn't mount, even when using debuggerd. It turns out selinux has labels that my old code didn't expect. Once I understood how my code reacted to the labels, it was an easy fix. The other issue is using vold prevented booting. Like we've discussed, targeting debuggerd, which would be less restricted than vold, was an alternative. But I wanted to do it the hard way so that future, more locked-down versions can't stop me. So I figured out the proper permissions to get vold to load. From there, I operated within the rules that vold must follow and things worked as they should.

The init.d script is loaded quite early in the two roms I tried so it should hopefully not cause issues with other processes. For roms without init.d support, the binary method hopefully provides the same result. I did not have time to test compatibility with other hw/sw components or apps, or to try these new files on any JB roms. I'm not as proficient in testing, so if you or anyone feels like doing that, let me know your findings. Thanks.

Note: for SELinux-enabled (say, KK) roms, use TWRP to flash. For other (e.g. 4.1.2) roms, either CWM or TWRP should be okay. As before, -initd.zip includes file copying but no uninstaller. Its file copying method is the same as the one used by -copy.zip so the files are compatible. To uninstall the init.d script, just delete /system/etc/init.d/00DataOnSD. To wipe "data" (files on external partition) between different roms, format the partition or remove all files. Alternatively, remove the tag file, let the rom sets up its /data on internal storage, and then use the copier script.

Will this work on CM12 (we have a guy from the L70 group claiming it works; however our storage issue is more predominant in CM12)

 

[WarrantyVoider]

One question.... If I want to restore the phone back to bone stock, do I have to uninstall this hack first?
Or can I just do the Power+Volume and it will wipe out the hack ?

Well, let me explain it this way. In terms of effects to the internal storage, this hack only makes changes to the /system partition (and depending on which version, maybe temporarily to /cache as well).

Normally when you restore a CWM/TWRP backup (a full restore) or flash a new rom, you would replace all files on the /system partition. Everything including this hack would be replaced. So no, you don't technically need to uninstall the hack if you're going to replace all files by restoring anyway.

Power+Volume down lets you enter recovery. On this phone, it first wipes /data before entering recovery. Since this hack resides in /system and not in /data, wiping "data" technically won't remove the hack.

 

[WarrantyVoider]

Will this work on CM12 (we have a guy from the L70 group claiming it works; however our storage issue is more predominant in CM12)

Honestly, I don't know right now because I don't have experience with Lollipop yet.

I think there are two potential issues based on what little bit I know. Please do let me know if I'm wrong. One, L enforces even more SELinux restrictions. Well, KK already enforces vold's access rights and I use vold as my entry point in my binary implementation. So I think this one might be okay, unless Google has changed access rights of vold in L. And doesn't CM12 support init.d? The init.d implementation shouldn't have to deal with SELinux because init.d scripts should already have the proper rights.

Two, L uses full disk encryption for the internal /data partition. I think this technically offers a clean way for the hack to do its thing, but it would remain an issue until an implementation is created or updated to deal with it.

Now, I don't know how CM12 implements Lollipop. Maybe it is less of a challenge than the official Lollipop. If I have access to a Lollipop or CM12 device/rom, I'd welcome that challenge. In the meantime, if you're building the rom, you can easily edit the init.*.rc scripts to mount an external partition at the desired mount point. And if your phone has an unlocked bootloader, a loki'able boot image, or a kexec-enabled kernel, an external mod to trigger mounting of an external partition might be possible.

 

[crutchcorn]

Honestly, I don't know right now because I don't have experience with Lollipop yet.

I think there are two potential issues based on what little bit I know. Please do let me know if I'm wrong. One, L enforces even more SELinux restrictions. Well, KK already enforces vold's access rights and I use vold as my entry point in my binary implementation. So I think this one might be okay, unless Google has changed access rights of vold in L. And doesn't CM12 support init.d? The init.d implementation shouldn't have to deal with SELinux because init.d scripts should already have the proper rights.

Two, L uses full disk encryption for the internal /data partition. I think this technically offers a clean way for the hack to do its thing, but it would remain an issue until an implementation is created or updated to deal with it.

Now, I don't know how CM12 implements Lollipop. Maybe it is less of a challenge than the official Lollipop. If I have access to a Lollipop or CM12 device/rom, I'd welcome that challenge. In the meantime, if you're building the rom, you can easily edit the init.*.rc scripts to mount an external partition at the desired mount point. And if your phone has an unlocked bootloader, a loki'able boot image, or a kexec-enabled kernel, an external mod to trigger mounting of an external partition might be possible.

Actually, turns out that it does indeed work. x) SELinux is disabled on our build so yeah.

 

[Raptor_Jesus]

If you don't mind letting me know which devices and roms you've successfully used the scripts/zips, it'd be great to know what systems are compatible. Thanks.

I've been using this hack on LG F6/CarbonRom for the past month or so, has been stable for most of the time. Had a couple of filesystem corruption (and subsequent failure to mount), once after an unexpected crash, and once infact after a manual reboot. But both times the ext4 journal itself was corrupt, so had to fsck on my linux desktop. Your new fsck-ondemand.zip is godsent!

BTW, are you aware of Mount2SD ? How is different is it from your solution. I really like the idea of doing all this in an Android app, instead of from within recovery. Is it possible to package all of your scripts into an apk?

 

[WarrantyVoider]

I've been using this hack on LG F6/CarbonRom for the past month or so, has been stable for most of the time. Had a couple of filesystem corruption (and subsequent failure to mount), once after an unexpected crash, and once infact after a manual reboot. But both times the ext4 journal itself was corrupt, so had to fsck on my linux desktop. Your new fsck-ondemand.zip is godsent!

BTW, are you aware of Mount2SD ? How is different is it from your solution. I really like the idea of doing all this in an Android app, instead of from within recovery. Is it possible to package all of your scripts into an apk?

ext4 supports journal checksums and metadata checksums. I don't know if those features would help with the file system corruption issues in our cases. How did you partition and format your SD card? Like I've said before, if this problem turns out to be more widespread and I can collect some data from people who've experienced this, then maybe I can investigate whether there are workarounds to avoid file system errors in the first place (assuming it's not due to a bad card).

crm701 first brought Mounts2SD to my attention back in #191. You can go back and read our discussion if you'd like. I've subsequently mentioned it in other posts as well. I have not tried it personally though. If you do try it, let me know how it works. If it's more reliable or better for other users, I have no problem with people choosing that option instead. Personally, I prefer doing things my way, but I am probably a little biased.

As for putting things in an apk, people have asked for that in the past. The other request was to make an Aroma installer. In terms of Android development, I'm just a beginner. So there's a lot of things to learn first. Like I've said before, I'd consider but right now my time is mostly spent on another project. I figure this hack should only need to be installed once, so the installer or whatever scripts wouldn't be used much after things are working. Anyway, after I achieve my goal with my current project, I'll revisit this topic.

 

[catchingup]

BTW, are you aware of Mount2SD ?

at quick glance, WV hack seems like a much cleaner solution than mount2sd because Mounts2sd still modifies the eMMC during operation.

WV hack is seamless with a fast enough sd card, and if sd card fails, you still have a fully working backup on the eMMC.
With m2sd, if your card fails, you'd have a bunch of broken apps and who knows what else...

 

[sporto]

I just want to say a very big thank you to WarrantyVoider and all of the others that worked on this project. I have this working on two phones now, and is a simple and effective way to turn a mediocre phone into a good one. Thanks again. Much appreciated.

 

[dublus]

I would like to add my thanks to WarrantyVoider as well. Before Christmas we had two f6's in the family, now we have five. All running this memory hack and all working quite well.

One of the phones did start to bootloop and I could not get into recovery except by pressing power/volume down combo which, of course wiped /data. Got me wondering, will this hack work on a phone that also has pressy4pie's CWM recovery installed? For those that don't know, with pressy4pie's recovery /data is not wiped by pressing the power/volume down combo (even though it says it will).

 

[RelZeshi]

I'm still getting some apps installed after the hack, that refuse to function properly. Examples are Hangouts being unable to save photos, games downloading additional content, and other apps failing to initialize when data connection is required (Slack Radio). I'm on the Carbon Rom with Metro POS.

 

[WarrantyVoider]

One of the phones did start to bootloop and I could not get into recovery except by pressing power/volume down combo which, of course wiped /data. Got me wondering, will this hack work on a phone that also has pressy4pie's CWM recovery installed? For those that don't know, with pressy4pie's recovery /data is not wiped by pressing the power/volume down combo (even though it says it will).

Are you still on stock or a JB rom? If so, then CWM should be fine. I originally tested my zips on a Nook Color with CWM and no one has complained that they won't install using CWM. If you're on a KK rom, then no. As far as I know, pressy4pie's CWM was built with JB's environment and it lacks some tools needed to properly install security contexts required by KK's selinux. Right now the only way to properly install my hack on a KK rom is to use a custom recovery capable of dealing with selinux contexts, like hroark13's TWRP. I suppose it's possible for me to include an updated busybox or other tools in my zips so they can be used in any reasonable custom recoveries, but oh well, I didn't do that.

As for the power+volume down entry method, I think the bootloader zeros internal data partition before entering recovery. Normally, if you just boot the rom (the stock rom, at least), it should set up the file system for you. So are you sure /data is actually preserved? Or is it just recreated (i.e. factory reset, no user data)?

 

[WarrantyVoider]

I'm still getting some apps installed after the hack, that refuse to function properly. Examples are Hangouts being unable to save photos, games downloading additional content, and other apps failing to initialize when data connection is required (Slack Radio). I'm on the Carbon Rom with Metro POS.

Not sure what the cause of problems is in your situation. Issues with permissions? Conflicts with other mods/hacks you've installed? It's difficult to say without seeing the problem myself or without more debugging info. I'm not suggesting you do this, but if you have everything properly backed up, you could try to install everything from scratch (just rom+hack+app) and see if those apps still misbehave. If you notice some conflict with the rom caused by mounting of the external partition in the middle of the booting process (like the sensor issue), let me know and I'll take a look. And if this method doesn't work for you for whatever reason, there are other ways like manually editing the boot image. Good luck.

 

[RelZeshi]

Not sure what the cause of problems is in your situation. Issues with permissions? Conflicts with other mods/hacks you've installed? It's difficult to say without seeing the problem myself or without more debugging info. I'm not suggesting you do this, but if you have everything properly backed up, you could try to install everything from scratch (just rom+hack+app) and see if those apps still misbehave. If you notice some conflict with the rom caused by mounting of the external partition in the middle of the booting process (like the sensor issue), let me know and I'll take a look. And if this method doesn't work for you for whatever reason, there are other ways like manually editing the boot image. Good luck.

Yeah, I've tried that. It seems any app installed before applying hack will work correctly. Some apps, like Slacker, I occasionally would get fixed by uninstalling them and rebooting the phone (3C toolbox automatically trimmed partition on boot at the time). I would then reinstall and there was a 50/50 chance they'd work. Only think that guarantees that the apps will work is if they're installed before applying the hack and using the copy script.

I used Linux to format by second partition to Ext4. I know at one point I had used Aparted to format the partition and it did it as Ext2, and somehow the hack was working that way for awhile. Oh, I even tried fixing permissions in recovery, that doesn't seem to fix it either.

 

[dublus]

Are you still on stock or a JB rom? If so, then CWM should be fine. I originally tested my zips on a Nook Color with CWM and no one has complained that they won't install using CWM. If you're on a KK rom, then no. As far as I know, pressy4pie's CWM was built with JB's environment and it lacks some tools needed to properly install security contexts required by KK's selinux. Right now the only way to properly install my hack on a KK rom is to use a custom recovery capable of dealing with selinux contexts, like hroark13's TWRP. I suppose it's possible for me to include an updated busybox or other tools in my zips so they can be used in any reasonable custom recoveries, but oh well, I didn't do that.

As for the power+volume down entry method, I think the bootloader zeros internal data partition before entering recovery. Normally, if you just boot the rom (the stock rom, at least), it should set up the file system for you. So are you sure /data is actually preserved? Or is it just recreated (i.e. factory reset, no user data)?

Hah, yeah, I should have mentioned all 5 f6's are running Xperion with Freedom kernel.

I just re-read pressy4pie's CWM recovery thread and it's more complicated than I thought. With his f6utilities2.apk app there is an option to enable a similar sd card hack as well as an option to install his CWM recovery. If BOTH are done the way he instructs (in an entirely different thread) then the /data in the phone is wiped but the /data on the sd card remains intact which is what lead to my misunderstanding. I know this works because I experimented with it a bit before trying out yours. Pressing power+volume down still warns about factory reset but it doesn't. Everything is still there after booting. However, after a week or so my daughter said there was something wrong with her phone and when I checked it out something had gone wrong and the sd card hack had been lost. That's when I started looking for another, hopefully more reliable, alternative and found yours.

So, I guess I'm still wondering if only the internal /data is wiped, why does that have any effect on your sd hack? I'm guessing there's still something in internal /data that is needed?

Again, thank you for making a $40 phone into a $200+ phone. My daughter likes it better than her Note2.

 

[WarrantyVoider]

Yeah, I've tried that. It seems any app installed before applying hack will work correctly. Some apps, like Slacker, I occasionally would get fixed by uninstalling them and rebooting the phone (3C toolbox automatically trimmed partition on boot at the time). I would then reinstall and there was a 50/50 chance they'd work. Only think that guarantees that the apps will work is if they're installed before applying the hack and using the copy script.

I used Linux to format by second partition to Ext4. I know at one point I had used Aparted to format the partition and it did it as Ext2, and somehow the hack was working that way for awhile. Oh, I even tried fixing permissions in recovery, that doesn't seem to fix it either.

Not sure, but it does sound like some kind of permission problem if you only have issues with certain apps and those apps are not FC'ing. Normally I expect new installs to be okay, but it's the opposite in your case. Do you have remnants of old app data (like in fat32 or if you've previously moved/linked the app to "SD" before using my hack)? Fixing permissions in recovery doesn't always work and could even mess things up more. And the recovery would only be trying to fix permissions in internal storage anyway. Probably not what you want.

Don't know how good you are with technical stuff, but you can manually take a look inside /data/system/packages.xml and look for info about an offending app. In particular, find its assigned uid and directory path and such. Then check all paths to which the app has access have the correct ownership and file/directory permissions. File permissions on fat32 probably use a different mechanism and would need to be checked separately. This is assuming the issue is caused by permissions. I wouldn't recommend poking around unless you know what you're doing. So perhaps start with a logcat and see if the apps themselves tell you what the problem might be.

 

[WarrantyVoider]

So, I guess I'm still wondering if only the internal /data is wiped, why does that have any effect on your sd hack? I'm guessing there's still something in internal /data that is needed?

It wouldn't and nothing in internal /data is needed once all files are copied. The data on the SD card would remain as is unless you (or some program) alter it. The phone's built-in data wiper doesn't know about data being on the SD. It wouldn't and shouldn't touch the SD anyway. So in this sense, this is similar to what you said about pressy4pie's SD mod, that your actual data on SD remain intact.

Now, if your data on the SD card got wiped when using TWRP's factory reset (maybe that's what prompted you to say CWM doesn't wipe the SD data?), that could be because TWRP wipes "sd-ext" which is the 2nd partition on the SD, where your SD data would reside. So obviously if you don't want TWRP to wipe it, don't let TWRP wipe it. In fact, you should never let TWRP's default wiper wipe "sd-ext" because TWRP would format it as ext3 (at least in hroark13's version). Ext3 and 4 are supposedly compatible, but you'd lose some features so I don't recommend it. I don't know if TWRP wipes "sd-ext" by default when you do a factory reset with it (I remember it saying so) as I've never tried it, but you can manually choose what TWRP wipes. In my instructions for TWRP, I've said to use the "rm -rf" setting instead when you do want to wipe "sd-ext." So for sd-ext, you would do that instead of formatting.

Don't worry about factory reset and data wipe unless you think you actually need it. Let's discuss the situation your daughter ran into. The SD partition has an error and can't be mounted. With pressy4pie's mod, you can't boot (not sure, just based on my understanding) because the rom doesn't know where to find data. My hack has a fallback to mount the internal data. Then you just enter CWM/TWRP without using the button combo. To fix the SD card, try flashing -fsck-ondemand.zip. If the error is fixed, reboot into rom and hope all data are still there.

I hope that made some sense. Ask if you need more info. Anyway, if your daughter doesn't want her Note2, can I have it? No, I'm just kidding. Your appreciation is enough.

 

[dublus]

OK, I didn't mention that when I was trying to do something about my daughter's bootlooping phone I entered recovery through power+volume down and wiped cache and Dalvik cache. I didn't wipe or clear anything else and after rebooting the phone it was as if the phone had been wiped. No apps, no google account, start up wizard upon boot - AND - the memory mod was lost. I'm not really sure what went wrong. At that time I assumed pressy4pie might have done something "magic" since with his mod the phone could survive entering recovery through hardware buttons. I'm guessing your mod would survive as well since, as you said, the sd card /data remains untouched.

If it happens again I will try flashing -fsck-ondemand.zip.

Funny thing about the note2 - it's not my daughter's anymore. My wife decided to jump into Lake Powell with her note2 in her pocket (didn't even notice for an hour). Once my daughter started using the f6 with your mod she decided to make it her daily driver and gave her note2 to my wife. So, thanks again for saving the replacement cost of my wife's phone. When Best Buy was unloading the f6's for $40 I got 3 more to add to the 2 we already had and, like I said earlier, they are all humming along with your mod.

 

[radicalbiscuit]

Warranty, I come to you with 1) a statement of gratitude, 2) a question of installation source, and 3) a possible bug.

Thank you very much for the work you've done. The features the phone offers are mostly useless with such a limited default data partition. Your ingenuity has allowed the phone to fulfill its potential, giving the masses like me a cheap phone that is now also quite capable.

I recently installed the hack on two LG F6 devices from the sources in #251. Should I not have done this? I only just became aware of the versions in #309 and #319. Should I have used one of those? If so, how might I "update" to one of them? Simply reinstall, and if so, do I need to do it from the stock ROM (with the SD pulled) or can I do it with my SD's data partition active?

Finally, I'm experiencing a problem about once a day where my phone doesn't recognize any touches. I use the hard power button on the side to wake the phone up and the lock screen doesn't respond to my touch. When the screen finally turns off (or if I force it off by again pressing the power button), the screen will no longer wake up. I then have to restart the phone by holding down the power button. When it reboots, everything seems to be fine.

I'm not doing anything funky with the phone (other than this hack) so I don't expect anything else to be the cause, though I can't entirely rule it out. I have also occasionally experienced the sensor issue, randomly. It was my understanding that the sensor issue usually only happens immediately after installing the hack, but this has happened at various times long after many reboots since installing the hack. I should note that I have not yet tried your sensor fix, so I can't speak to its effectiveness in that problem, but I thought I would describe all the symptoms in case anything is related.

 

[RelZeshi]

Don't know how good you are with technical stuff, but you can manually take a look inside /data/system/packages.xml and look for info about an offending app. In particular, find its assigned uid and directory path and such. Then check all paths to which the app has access have the correct ownership and file/directory permissions. File permissions on fat32 probably use a different mechanism and would need to be checked separately. This is assuming the issue is caused by permissions. I wouldn't recommend poking around unless you know what you're doing. So perhaps start with a logcat and see if the apps themselves tell you what the problem might be.

I'm fairly good with technical stuff, but I haven't begun going through files like that. I'll start with logcat and see if I can figure it out. I even did a full wipe, reinstall the rom, and then the hack. Still same issue. I might try starting over 100% from scratch again, but will give logcat a try first. I'm hoping it's some weird thing I managed to do.

 

[WarrantyVoider]

@dublus
I just realized last night there are two versions of pressy4pie's CWM. One version is the regular one, which I know about, and the other is specially made for pressy4pie's SD mod, which I've never used. So now your original question whether my hack works with CWM takes on a new meaning. So let me try again. For the regular CWM, installing my hack with it on a JB rom should be fine. Backup/restore of "data," however, would only apply to internal /data partition. As for the SD-mod CWM, I'm not sure. But if my guess about how it works is correct, -install.zip would work but -copy.zip wouldn't. If you already have your data (or a copy) on the SD (say, from previously using pressy4pie's SD-mod), then in theory you don't need to do -copy.zip. You just need to create the tag file so my binary would mount the partition at boot. And with this version of CWM, I'd assume backup/restore of "data" refers to the external /data partition. Anyway, no one should be mixing mods/hacks that achieve the same goal, so I won't elaborate unless you or someone else specifically asks about it.

It's wise to understand how to deal with potential problems just in case, especially when you have 5 phones to support. I don't know what happened to your daughter's phone with the other mod, but it doesn't quite make sense that the phone was factory-reset AND the mod was lost. I can see what might have happened if the phone was reset but the mod was still working (increased storage but wiped data). Maybe I'm missing some information or I'm misunderstanding how pressy4pie's mod works. So unless you want to know more, I'll just leave it at that.

Let me know if anything isn't clear to you. Anyway, hope you never need anyone's help resolving boot problems because you never run into them.

 

[WarrantyVoider]

Warranty, I come to you with 1) a statement of gratitude, 2) a question of installation source, and 3) a possible bug.

1) You're welcome.

2) It's been a while and I've gone through a lot of versions that were never released. But if I remember correctly, #251 and #309 are functionally equivalent. Changes in the #309 version were needed to make the hack installable with TWRP. Then the version in #319 was made to make the hack usable with KitKat roms. I'm not gonna check now, but I think #251 and #309 use the same binary. #319 has a different, updated binary and the changes I made to the binary are just to make it run under KK. The binary I'm talking about is the change made to the system that allows the external partition to mount. Now, when you say #251, I don't know which installation method you are referring to. If it works for you, you don't need to change it. If you want to uninstall, just use the uninstallation instructions within the set of installation instructions you've used. You can reinstall the hack, skipping the file copying part if you haven't messed up your data on your SD. #309 and #319 are flashable zips. You use them in custom recovery like TWRP. And in TWRP, your data partition on the SD is not active unless you mount it (it's referred to as "sd-ext"). Since TWRP can access that partition, be careful not to wipe it. You don't need to worry about that if you're just using it to flash my zips. If you actually want to know the technical differences between those versions, I can elaborate and make a even longer post.

3) My binary runs early in the boot process. Its job is to mount the external partition. Once it's done that, it's not running anymore and has no control over what happens afterward. In fact, it's not even sitting in memory somewhere. Technically, it's not causing the issues you are describing.

First, the sensors. The issue could be triggered by use of the hack. If there's a problem, it happens after a reboot. If it works after a reboot, it should work until you reboot. Basically, during boot, it's a race between sensord (the daemon responsible for the sensors) and my binary to see which gets to /data first. My binary is trying to replace the /data partition before other programs need to use it. Under normal conditions, my binary wins and there's no issue. But in some cases, when the external partition is not ready, sensord wins but really loses because it can't access the right files once /data is replaced. My understanding is the issue occurs when the external partition is not ready for action quickly enough. For example, when some cache files need to be rebuilt at boot (so the OS is slow at getting the partition mounted and ready in time) or if the SD card is slow to initialize (slow card or access issues). On my phone with a Samsung card I've rebooted numerous times and sensors work fine every time without any workaround. catchingup said in another thread that with a faster card the sensor issue doesn't seem to appear. Anyway, there's a workaround to restart sensord already. So even if sensord wins, make it run the race again.

As for the lockup issue, no one has reported that problem. Again, my hack is not running at that point. So if it's a problem you don't experience with internal storage, it could be caused by the use of the SD card. If your touchscreen becomes unresponsive, often it's because some process is hogging the CPU cycles so the touch events don't get processed. The question is whether the system actually freezes or crashes. So if you have some background process like music playing, does it stop? If you wait a while without doing anything to it, does the system come back? Does your phone lag often or even occasionally? What SD card do you use?