Related
I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse
Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything
thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.
File under "I'm no expert but..."
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App
heyy, I'm not punchie, I've got what the doctor calls a relaxed brain
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck
deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.
Un-Bricking by Unlocking & Flashing CWM+CM7 (was: Accidentally deleted MediaProvider)
Hi!
When removing Bloatware with Titanium Backup a while ago, I accidentally missed a click (never used a touch screen...) and uninstalled MediaProvider, which I have not been able to recover since.
I tried putting the files back from a friend's HTC, which didn't work; after that I was told even the packages differ between manufacturers, so I tried getting them from a stock Bell Atrix .zip posted on these very forums, which didn't help either. Neither #android-root nor AndroidForums were able to help, thus I ask here: Can anyone tell me how to either make my system accept Bell's files, or where I can find a "vanilla" Motorola build?
(Problem is, the phone didn't come from a phone company, a friend of mine got it pre-release from his uncle who is with Motorola, so it may even be different from what hit the market later on...)
I guess the following information will help, it's a Titanium Backup info file for another componend I backupped shortly after:
#Titanium Backup
#Sat Feb 25 03:28:43 MEZ 2012
app_gui_icon=[...]
sys_ro.build.date.utc=1302536066
app_version_code=8
sys_ro.product.model=MB860
has_prefsdata_jpu=0
sys_ro.serialno=<xxx>
sys_ro.build.description=olympus-user 2.2.2 OLYEM_U4_0.44.0 578673 ota-rel-keys,release-keys
has_prefsdata=0
app_gui_label=com.android.providers.applications 2.2.2
sys_ro.build.version.release=2.2.2
app_apk_md5=1989ff2476ee73ad445760b9bef5f44e
has_dbdata=0
app_apk_codec=GZIP
app_is_forward_locked=0
app_is_system=1
app_label=com.android.providers.applications
app_version_name=2.2.2
generation=1
app_apk_location=internal
(Most of this is unnecessary, I guess, but I can't really be sure what you might need to judge what I would have to to...)
I would be very grateful for any help, it is extremely limiting not to be able to use any media capabilities.
So, thanks in advance,
David
maybe flash a new rom if your contacts are all backed up?
Hm, well, that would really be the last resort :\ In addition to losing all my data, I fear the risk of bricking it completely. Can't really be that I'd have to flash it just because two files are missing...?
Edit: I neglected to say that the files in question are MediaProvider.apk and MediaProvider.odex. I do only need to copy these to /system/app, right?
Intelensprotient said:
Hm, well, that would really be the last resort :\ In addition to losing all my data, I fear the risk of bricking it completely. Can't really be that I'd have to flash it just because two files are missing...?
Edit: I neglected to say that the files in question are MediaProvider.apk and MediaProvider.odex. I do only need to copy these to /system/app, right?
Click to expand...
Click to collapse
Yes, but you have to set the permissions same the other files in .system/app folder.
I have attached the missing files to this post. My gingerbread version is 2.3.4.
Good Luck!
Huh. Setting right permissions for the files from Bell had no effect; installing yours soft bricks it in an interesting way: Even with Early USB Enumeration, all I see is
# adb devices
List of devices attached
???????????? no permissions
Even with root. The LED flashes red, and after a minute it reboots. I had expected things not to work out, resulting in the deletion of your files, but that I screwed up _that_ bad after it didn't even seem to notice the right (?) files when they were there is kinda surprising.
The standard workarounds (adb kill/start server, MODE=0666 to udev or being root) change nothing about this. Time for hard reset?
Intelensprotient said:
Huh. Setting right permissions for the files from Bell had no effect; installing yours soft bricks it in an interesting way: Even with Early USB Enumeration, all I see is
# adb devices
List of devices attached
???????????? no permissions
Even with root. The LED flashes red, and after a minute it reboots. I had expected things not to work out, resulting in the deletion of your files, but that I screwed up _that_ bad after it didn't even seem to notice the right (?) files when they were there is kinda surprising.
The standard workarounds (adb kill/start server, MODE=0666 to udev or being root) change nothing about this. Time for hard reset?
Click to expand...
Click to collapse
I would hard reset too at this stage. I'm sorry it didn't work out.
Now, that's interesting. Factory reset didn't change anything.
Sorry for reply to self, but I was less than clear, so - help?
My next step would be to try to unlock the bootloader, then flash CWM and see if anything can be fixed that way; then, I would try flashing CM7 (or, more specifically, the Neutrino GT ROM) by CWM; then, I would try flashing it without. Is that a safe progression of attempts? Or have I possibly broken anything that would hard-brick it by any of these methods? And can you recommend any finer increments what I could do before / between / after those mentioned? I still have the option to apply an update in Recovery - is it possible, for instance, to put a .zip onto my SD that has 0 Byte MediaProvider files in it?
(I have thought about installing Neutrino for a while, and this seems to be a good time to flash it, as my data is cleared now anyways. To my understanding, this should not be any more dangerous than just re-flashing the Froyo that was there before, right?)
As an additional fact, ADB now doesn't detect any devices any more, even with Early USB. This could be because USB Debug is not a factory standard setting, though, as I reset it to factory defaults.
Also, the startup Moto screen behaves differently: It doesn't go to the point where the logo disappears in a flash, the background light switches off before that. As far as I can tell, the display still shows the animation, though, but it is not lit. Furthermore, the reboot seems to happen immediately after the animation has ended, and not 1-2 minutes later, like it was before the reset.
I would be grateful if anyone could explain what happened. To my understanding, a factory reset should clear /system, and the error started when I put some non-compatible .apks there, so I thought this would fix things. Is it possible something broke on the hardware side, when (for instance) 2.2.2 called a function that has had its parameters changes in 2.3.4?
[If a moderator reads this - does this qualify as a general Android question? I have no experience with different devices, so I'd be glad if you could decide if this thread has to stay here or if it can go to a sub-forum with a wider audience - General Android Q&A, for instance.]
Bump...
Success Neutrino up and running!
Well, my Nook appears to be in trouble.
The long and the short of it is that it got wet. Not too wet, but wet.
It boots but whatever I boot to crashes. This includes sdcard installs. The ROM completes the boot, and I can sometimes even open the app drawer, but it crashes before I can interact with it in any meaningful way.
All ROMs complain of "System process" and Wireless issues, with FCs.
I cannot get adb to recognize the device anymore. lsusb does find the Google Inc. entry, though. When I try and run adb devices (ubuntu), it returns ?????? and says insufficient permissions. I have, in response, set up the 99-android.rules in etc/udev/rules.d but it still cannot connect. I have also tried to quickly access the android terminal in the brief period I am allowed before the device crashes with no luck. My goal with this was to try fdisk -l.
The sdcard never mounts while in the ROM, and the emmc storage appears completely wiped.
However, I was able to see I had the correct files in /rom once, so those are there.
Thinking that the wireless chip might be the problem (as when even when I return to stock the set-up fails there, well, until it crashes again...) I tried to just turn off Wifi in 7.2. But as I unchecked the box, right under the setting just displayed "error"
CWM appears to be working EXACTLY as it should, including mounting the sdcard and allowing me to choose update zips.
The uboot and the uboot menu work as well.
I have tried flashing CM7, 9 and stock, as well as booting from sdcard in CM9. All flash and boot normally, but crash.
I have done the 8x reboots, succesully, but when the B&N set-up begins, I cannot connect to wireless. Which would be okay, in the long run, but it then crashes, which is not okay.
I was hesitant to reveal that it got wet, because I can see this being written off as a hardware issue (which it may be, don't get me wrong). But the fact that CWM works and the ROMs boot sure look like software problems to me.
I have tried flashing just about everything that looked promising. I have not dd any images, because I cannot get adb to work, and don't have any idea which partitions are in what shape.
Any suggestions?
Position the unit upside down with the SD flap open. Blowdry it from the bottom up on medium several times over a couple of days. If it's still doing it after that you can probably eliminate moisture as a cause.
old cell phone trick
Fill a bowl with rice (uncooked).....the rice will draw the moisture out.
you can also submerge it in ispropol rubbing alcohol... is what we use to clean electronic components... it will combine with the water... also used for water in gas on a car
Whoa, isopropyl alcohol. I feel like that would take some stones...
I have already put it through a 30 or so hour rice regimen (if that is true, even. It makes some kind of weird intuitive sense, which is usually the kiss of death...)
I have it standing up now and will see about a little air dry method while I investigate where to find the alcohol.
It didn't get submerged, it was lying on a counter and a glass got knocked over. I grabbed it right up, and then left it off like I said.
It boots, CWM works, but since it has been set all the way back to stock and all iterations have the same issue I am fearing the worst...
Thanks for the ideas...any and all welcome!
You can take the back off. I have not done it, but somebody just said they did it to disconnect the battery to reset. Look at that recent thread in q/a. Maybe he can tell you how he did it.
Attempt at your own risk, no support will be provided.
I'm not the battery guy leapinlar was talking about but,
Open the battery flap, remove SD card, remove the tape dots from the T-5 torque screws then remove the screws. Slowly and carefully so as not to break any of the hooky thingies that are holding the back on pry the cover up from that point moving slowly around the unit.
I've only done this once, it was a while back and I ended up breaking two of the little hooky thingies. That's why I suggested providing points for evaporation to escape and attempting to accelerate evaporation. Heck we don't even know if moisture is the issue anymore.
Thanks for the extra suggestions.
I tend to think at this point that whatever water got in there is gone. It's been four days, and it wasn't soaking. I may just go ahead and try and take out the battery, I don't know exactly why that would help, but what have I got to lose?
If I had to guess, I would think that the wifi chip might be shorted, as that is the only thing that doesn't seem to work at least for some period of time.
The FC's sure do look software related though. I fail to see how CWM could read and mount the sdcard while the ROM cannot as being anything other than sotware. Unless they use wildly different methods to do the same thing.
This nagging feeling that I should be able to at least fix that with some software methods keeps me thinking the same or the other problems. I'd be okay with an non-networked tablet, if it came to that. But maybe the thing has to have wifi as an option to work right. I don't know...
Two weeks ago my daughter managed to completely soak her nook.The nook would just constantly reboot with the stock os and system process would repeatedly fc with the cm7 sdcard. I pulled the back cover off and let it stand for a week. Today I pulled the battery and power button cable and it booted up just fine so far. So there is hope.
Malave said:
Two weeks ago my daughter managed to completely soak her nook.The nook would just constantly reboot with the stock os and system process would repeatedly fc with the cm7 sdcard. I pulled the back cover off and let it stand for a week. Today I pulled the battery and power button cable and it booted up just fine so far. So there is hope.
Click to expand...
Click to collapse
Considering that this is basically what is happening to me (but with some additional Wifi setting crashes) this gives me hope.
I had burned a bootable CWM card, from Leapinlar, which was a higher version than I usually used. I think 5.5.0.4 (?)
Anyway, of interest (before I shut it down 2 days ago):
internal sd card is not wiped, it can be explored in CWM.
The /ROM partition is at least somewhat functional, as battery stats can be wiped
When I request a log, I get:
Code:
Battery Stats
Block Groups: 3
reserved block group size: 23
Created filesystem with 11/22608 inodes
and 2883/90357 blocks
warning: wipe_block_device: Discard Failed
W: failed to mount /dev/block/mmcblk1p2 (no such file or dir)
also at one point:
Code:
make_ext4fs failed on /dev/block/mmcblk1p2
(note: both of the above from hastily scrawled notes)
It looks like mmcblk1p2 is related to system mounting, although I am not sure. Maybe that is why I am having trouble with ADB. It just kept saying insufficient permissions and ???????????. I tried setting up android-rules for udev with no luck.
Unless I hear anything else promising, I will go get the proper screwdriver and try the battery thing. It has been sitting off for a couple days now...
Thanks for all the ideas, people.
I'm confused... but trying to help you out... why are you trying that stuff on /dev/block/mmcblk1p2 when /dev/block/mmcblk0p2 is the ROM partition?
Try your edits to /rom... and if you have to try: mount /dev/block/mmcblk0p2 /rom
DizzyDen said:
I'm confused... but trying to help you out... why are you trying that stuff on /dev/block/mmcblk1p2 when /dev/block/mmcblk0p2 is the ROM partition?
Click to expand...
Click to collapse
I actually didn't try to do anything. I just wiped system, cache, davlik, battery stats and asked for a log prior to flashing a new zip in the hopes that the rom would work if provided a blank slate.
I wiped battery stats since the .bin that holds them is in /rom. The log was something I had never done before.
The notes from above were just the CWM output from the log.
edit: I just saw your second paragraph. Don't know how I missed it.
But I don't know what you mean by edits. I haven't been able to get ADB working. I have been able to mount and unmount through CWM that's it. Unless you might know anther way to resolve insufficient permissions with beaucoup question marks instead of device number?
Ok... sorry about my confusion on that... It appears that you are using a CWM that is modifid to work on SD... since it is trying to access /dev/block/mmcblk1p2 since the rom partition is on /dev/mmcblk0.
I would try a different version of recovery.
DizzyDen said:
Ok... sorry about my confusion on that... It appears that you are using a CWM that is modifid to work on SD... since it is trying to access /dev/block/mmcblk1p2 since the rom partition is on /dev/mmcblk0.
I would try a different version of recovery.
Click to expand...
Click to collapse
Which I was. I got it from Leapinlar, and was under the impression, since I had seen him warn that roms flashed from that recovery would go to emmc, that it would work.
I did make a regular 3.2.0.1 bootable, and tried again, but with the same result, so I don't know if that made a difference. But it did seem hopeful, so thanks for the response.
I am going to finally go get the torque screwdriver and take this battery off and give it some days. It's been almost a week already, but you never know.
Thanks a bunch for the reponses, Diz.
mateorod said:
I had burned a bootable CWM card, from Leapinlar, which was a higher version than I usually used. I think 5.5.0.4 (?)
warning: wipe_block_device: Discard Failed
W: failed to mount /dev/block/mmcblk1p2 (no such file or dir)[/CODE]
also at one point:
Code:
make_ext4fs failed on /dev/block/mmcblk1p2
(note: both of the above from hastily scrawled notes)
It looks like mmcblk1p2 is related to system mounting, although I am not sure.
Click to expand...
Click to collapse
Mateorod, if you got that log using my CWM boot SD version 5.5.0.4, the recovery.fstab lists /dev/block/mmcblk1p2 as SD-EXT, which for some devices is the extended partition on SD for storing additional apps to supplement /data. Our implementation of CM does not use that. So when recovery tries to do some wiping, formating, backing up, etc, it always fails when it looks for that partition. It has nothing to do with /system or /rom.
If you told it to do a factory reset, it tries to wipe /SD-EXT as part of that and it fails to wipe that because it cannot find that partition.
Edit: That CWM SD does do its modifications to emmc. It only referenced mmcblk1p2 because of sd-ext.
Here is the filesystem table from my log using it on SD:
0 /tmp ramdisk (null) (null) 0
1 /boot vfat /dev/block/mmcblk0p1 (null) 0
2 /system ext4 /dev/block/mmcblk0p5 (null) 0
3 /data ext4 /dev/block/mmcblk0p6 (null) 0
4 /cache ext4 /dev/block/mmcblk0p7 (null) 0
5 /emmc vfat /dev/block/mmcblk0p8 (null) 0
6 /sdcard vfat /dev/block/mmcblk1p1 (null) 0
7 /sd-ext ext4 /dev/block/mmcblk1p2 (null) 0
The alcohol trick does work, I did it on my old HTC Kaiser. I disassemble it as much as I was comfortable, and then completely submerged it in alcohol until It stopped throwing up air bubbles; Thus showing there was no air left in the unit. I then removed the pieces from the alcohol and put them in a bowl of rice. I let it stand for about a week. Once the time was up a reassembled and turned it on like nothing had happened.
Little note: I was in the possession of a AT&T Go Phone for use as a back up in case this destroyed the unit. If you feel that there might be another way to repair it, I would suggest you explore that option first as I do not know what a significant time in alcohol will do to the inner workings of the Nook. However if you are at the point of already replacing or upgrading to a different tablet, than you have nothing to lose and can only gain a working Tablet or fancy Paper-weight from this.
Okay, a little update.
I had taken apart the Nook and let it sit for almost a week. But upon reconnecting the battery and clearing system/cache/davlik and reflashing anything, it still wouldn't allow in-ROM mounting of sdcard or adb or wireless and I would still get some version of "process System not responding" and "Setting Wireless not responding" toasts and then a crash, either in CM7, CM9 or Stock. Unusable.
What I think I have is a totally borked wifi chip. Which is okay, in the long run, but the Nook kept crashing and I would have liked to use it in some capacity.
What I decided (which was difficult to diagnose with no terminal or no ADB) was that the Nook was crashing upon trying to access the network and the saved network info. (which I know is mad persistent, as the wifi network I used to originally register the device still shows up in the stats, even after many many system wipes and 8x reboots and so forth.)
I had never reset to factory from stock settings and I couldn't now completely erase and deregister because you need wifi to do so.
However, I found this (which I had never heard of, sounds like a boon to thieves everywhere). After skipping out-of-box experience I could boot into stock recovery and finally erase the wireless settings.
Now I have a stable (albeit un-registered) stock nook, where I can at least read the books I have on sdcard.
I will eventually reflash a CM build now that the network settings have been forgotten and see if that is usable, even if there is no wifi.
But I am pretty happy to have some semblance of the Nook back, even if it is just a neutered (literally) stock.
I'll let you know how CM goes one day soon.
Thanks for the help!
Excellent, (and powerful), link.
And by virtue of that link I will find a way to proclaim my absolute geekitude within the company by dropping Kate's name. :good:
Well, I finally tried flashing Cyanogen 7 and 9 to the thing, but as it crashes when it tries to access wifi, I can't get it stable.
Unless anyone knows a code edit (smali maybe? I know there are a bunch of boolean settings in the SystemUI.apk, maybe there) where I can change the default wifi setting, I may just be stuck with stock.
Which is way better than nothing, at least it has use. Skipping OOBE was a life-saver for getting to a place where I could erase the WiFi info.
Okay, here's another shot in the dark, still trying to get this thing to successfully boot in CM...
I am working on a little project for the Nook, which will be infinitely easier to debug if I can actually boot into CM.
Does anyone familiar with the source code know how to modify it so that WiFi is set to off by default? I am thinking about changing the 'true' to 'false' in the /device/bn/encore/overlay/frameworks/base/core/res/res/values/config.xml entry for wifi found here...
Code:
<!-- This string array should be overridden by the device to present a list of network
attributes. This is used by the connectivity manager to decide which networks can coexist
based on the hardware -->
<!-- An Array of "[Connection name],[ConnectivityManager connection type],
[associated radio-type],[priority],[restoral-timer(ms)],[dependencyMet] -->
<!-- the 5th element "resore-time" indicates the number of milliseconds to delay
before automatically restore the default connection. Set -1 if the connection
does not require auto-restore. -->
<!-- the 6th element indicates boot-time dependency-met value. -->
<string-array translatable="false" name="networkAttributes">
<item>"wifi,1,1,1,-1,true"</item>
<item>"bluetooth,7,7,0,-1,true"</item>
<!-- item>"ethernet,9,9,2,-1,true"</item -->
</string-array>
This looks like I am on the right track (this will eventually end up being compiled into the res folder of framework-res.apk) but I may need to track down the ConnectivityManager. Although the cursory look I have given this seems like I may be close to on the right track...
(The wifi being on at boot always crashes my CM installs due to shorted wifi chip, for those of you who may be new to the thread.)
I am asking here just in case someone knows, I may just go ahead and try it if no one chimes in. But better to ask than to blindly shoot in the dark, I figure...
Update: Success. I am back on CM9 (well, a hybrid, actually...HINT), without wifi.
Update 2: Due to the fact that this nook is now in a Cyanogen-usable state, a new rom will be posted in development tomorrow from eyeballer and I. Thanks for the suggestions, everyone. I wish I had dipped it in isopropyl alcohol, just so I could say I did it...
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Quick encryption guide (and more)
I won't go deep into useless details as everything has already been described about Android phone protection somewhere on the internet. I will just give some meaningful links and tips by illustrating how I have protected my phone. Really nothing new or innovative, just a compilation of a few hints that I have put in practice to protect the numerous pieces of information that are on my phone.
Step 0: awareness
----------------------------
Why bother with phone security?
In short, I am clearly paranoid. Well, in fact, I don’t really feel at ease when I know all the information, both personal and professional I have on my phone. Over the month, my Androphone has become a real digital Swiss-knife and personal secretary. This includes:
Personal and professional contacts
Personal and professional agendas
Personal and professional digital exchanges (SMS and email)
Personal and professional photos
Banking account information
Trails where I run
Etc… etc…
Don't want someone looks at them. Not you?
Fist step: on-line protection
----------------------------------------
The first step in protecting your data consists in making hard to access indirectly the data that lay on your phone memory. This access consists in using the system when the phone is on, either via the GUI and the phone controls, or remotely (essentially by network connections, or phone basic functionalities like sms). So, basically, you need to lock efficiently your phone from preventing someone else to unlock the user interface that allows interactions with the system, and protect all communication channels.
To lock efficiently your phone, you must use a pin code of at least 4 digits (6 is better) or a pass-phrase. The latter is much less practical without improving online security that much. Above all, you must avoid those silly locking solutions like face recognition unlocking, or pattern lock. Those are toys for naive young boys. Not for those concerned seriously by security.
For protecting remote access to your phone, I would suggest:
1) Double check that USB debugging is disabled. This a major security hole.
2) Turn on data connections (bluetooth, wifi and 2/G/3G/4G) only when required (email checking, web-surfing session, data synchronising), and off rest of the time.
3) Avoid install cracked unofficial apks, or applications that asks for permission far beyond their obvious and principal utility
4) Install a software security app, if possible, open source and recognised by xda members. Once an adept of Droiwall, I have switched to Avast mobile security because of its extra features. But it is not opensource and it is a question of taste. But do this carefully, see that for instance before making a choice: http://download.cnet.com/8301-2007_4-57391170-12/dont-get-faked-by-android-antivirus-apps/ and http://www.av-test.org/fileadmin/pdf/avtest_2012-02_android_anti-malware_report_english.pdf.
But, you must be rooted (which is in itself a security hole if not mastered) and one must have a kernel with netfilter functionalities activated. This is the case with the stock kernel of the phone I use at the present time (Lenovo A789). But was not the case of 2 Samsung phones I used before. You have to either install a custom kernel adapted to your phone, or make your own if you have access to its sources (see tutorials as: http://forum.xda-developers.com/showpost.php?p=22941057&postcount=1)
5) Personally, I would feel more at ease if I could find an easy to use firewall solution that could close, and better, make stealth all the local ports of my phone, especially when I am not behind a wifi router. But I haven’t found one yet. Droidwall, nor Avast, addresses this functionality, whereas it would be fairly easy to implement it with the netfilter system layer underneath.
Second step: offline protection
-------------------------------------------
Here we are. Now your phone is protected when it is on. But, what if you switch it off, or remove its sdcard? The data lay on the internal memory, unprotected (at best obfuscated). Really easy to find a custom recovery for almost all phones, write a script to dump /data on a sdcard and then make whatever you want with the copy.
Don’t like that? The only solution to prevent /data from being read by someone else is to encrypt the /data partition. To do that, your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. So beware, if you want encryption you need to buy a device that answers this requirement. This is not always true and almost never documented. Notes on the implementation of Android encryption are there: http://source.android.com/tech/encryption/android_crypto_implementation.html
Now, as me, if you are reading these lines, you are certainly looking for extra information about your Android device and probably extra functionalities.
Certainly, the most frequent way to install extra functionalities and custom ROMs to your phone is to use an update zip file. With stock recovery, this zip file needs to be signed, otherwise it is rejected. For maximum flexibility and ease of use, alternative boot recovery have been developed, of which CWRP is certainly the most famous.
Usually, for 99% of users and operations, CWRP operates great. Sometimes, as nothing is perfect, a bug may occur. This is the case for built in ICS encryption process. As Cybermaus indicates in the first post, to be able to perform this encryption the /data filesystem must be slightly smaller than the underlying partition. But CWRP, at least up to the version 5.5, formats all the corresponding partition leaving no place for Android to store the required information to be able to start the encryption process. This is clearly described in the following links: http://forum.xda-developers.com/showthread.php?t=1792101 and http://rootzwiki.com/topic/25652-fixing-galaxy-tab-2-encryption/
I have discovered that by using aLogcat to track down the origin of the failure. The interesting part revealed to be: E/Cryptfs ( 87): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
To circumvent this problem, you will find in Cybermaus first post, two CWM update zip files that will do the trick in a simple and secure way. After flashing your ROM and wiping data with CWM, apply them, go to system encryption as described here:http://support.google.com/android/bin/answer.py?hl=en&answer=1663755, and after waiting one or two minutes (not more), the system should restart automagically to encrypt your /data partition.
Third step: making your phone even more secure and practical at the same time
-------------------------------------------------------------------------------------------------------------------
Android built-in encryption is in fact more or less Linux LUKS (http://en.wikipedia.org/wiki/Linux_Unified_Key_Setup). Plus, it is open-source so that everyone with the required skills can make an audit of the code to see if no security hole is present in the Android implementation. The underlying mechanism is strong and secure, as long as you use a strong password. I mean by strong, at least 12 characters that includes at the same time lower-case letters, upper-case letters, numbers and symbols. And it must be something impossible to guess for others while easy to remember for yourself. You will find a lot of resources on the internet on how to create such a password. For instance: https://help.ubuntu.com/community/StrongPasswords .
The problem with Android, in its attempt to keep the system not too complicated to use, is that the GUI (I insist: only the GUI, not the system) does not distinguish between the PIN or passphrase that you use to lock your phone when it is on, and the password used to encrypt the data that lay physically on your phone storage. So the casual user is in front of a paradigm: either he chooses a strong password for its data, but this will rapidly become tedious to type at least 12 characters to unlock his device several times a day; or he decides to use a PIN code, which is more practical to unlock the phone, and consequently uses a really weak password to encrypt its data which contains only digits, and thus may be cracked in a breath by any PC.
Fortunately, this paradigm is addressed and solved by small tools like EncPassChanger or Cryptfs Password (both requiring that your phone be rooted, which is by the way, paradoxically, a security hole if not used with caution ). See: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html for complete notes about that. So for me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time.
Fourth step: increase security, without sacrifying practicability
-----------------------------------------------------------------------------------------
As I am paranoid, but at the same time don’t want my phone to become a source of annoyances, the previous “basic” steps were not enough for me.
So I decided to improve security in two ways:
1) By following the following tip, which I find great and is itself self-explaining: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2
2) By encrypting the photos I take with my phone, because these are linked with my private life and I won’t like that somebody gain access to them.
3) By encrypting documents I scan with CamScanner, for home and work, which may be sensitive.
4) By automating the action that disables USB debugging in case I forget to put it off after using it .
For point 2 and 3, documents lay on your sd card uncrypted. Android built-in encryption does not deal with both internal and external sdcard (just to be clear, by sdcards I mean partitions mounted as /mnt/scard or /mnt/scard2). To encrypt them you have to use once again an external tool. As I am an opensource fanatic for all that deal with security, I would recommend to use LUKS Manager (https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&feature=search_result and http://forum.xda-developers.com/showthread.php?t=1141467) which is based on dm-crypt module (yes, the same that Android uses for its build-in encryption), or Cryptonite (https://play.google.com/store/apps/details?id=csh.cryptonite&feature=search_result) which is completely open-source and implements the rock-solid Linux encfs on Android.
The latter is my personal choice. I do not use Crytonite in itself, except for creating the initial .encfs6.xml file. For everyday use, I use directly the Android port of the binary file encfs that comes with Cryptonite, and embed it into shell scripts. Up to now, no flaw, no problem. The password to open my encfs encrypted volumes is stored in a text file located on the /data partition. It is thus encrypted by Android and made accessible on boot when you decrypt this partition. So nothing more to remember.
To make things usable and practical, I use Tasker to automate the following things:
- Mount encfs volumes on start-up, by reading directly the password in the file located on /data
- Umount encfs volumes when usb is plugged
- Copy photos on a regular basis from the unencrypted /mnt/sdcard/DCIM to the safe place I created with encfs, delete AND wipe the original ones
Fifth step: be coherent about security
-----------------------------------------------------
Some people, torn apart by the paradigm described in Third step, by negligence or by lack of knowledge, strongly secure one part of the system, but make other parts big security holes.
Concretely, I am thinking about two examples: mixing encryption with pattern lock (or, even worse, with face unlock), or mixing encryption with usb debugging. Face recognition is just a jock. It is not reliable and fails very often. Moreover it is really easy to crack, with a photo for example. One of my colleague even achieved to unlock my phone with its own face, just because we are morphologically close enough. Pattern lock is not much better. (See: http://forum.xda-developers.com/showpost.php?p=37649447&postcount=6 and https://www.google.fr/search?q=smudge+attack).
So always ponder over (two times rather than one) each action you take that may touch system security.
Thanks lolo
I'm trying to use this on my VZW Galaxy S3 16Gb and this is what I'm seeing in TWRP v2.2.0:
Mounting System
Extracting system fixes
Update script starting...
Update script started
Disk /dev/block/mmcblk0p15: 13.1GB, 13140754432
4 heads, 10 sectors/track, 401024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
ERROR: unlikely size of KB
aborting operation!
Update script ended
Unmounting system...
Update Complete
Click to expand...
Click to collapse
edit: The same thing happens with both scripts.
I need to enable device encryption because my employer requires it for email and other Google Apps for Business apps. Thank you for your help!
Anyone know why full disk encryption isn't available on some (if not most roms)? Is it something that needs to be added with intent aside in the building process, or dependent on how the stock rom was set-up to work with?
I was hoping this would help get encryption working on an EVO ics rom which has encryption available, but when you click "encrypt phone" it just hangs on an android screen and doesn't actually do anything.
i was really happy to find your solution to enable encryption on my HTC desire S (ICS, rooted), but unfotunately it doesn't work. the same thing happen to me as it happened to mushu13, only different numbers in lines 5 and 6. same result whichever script i choose. please help, i really need system encryption.
thanky you very much!
First thing you should know, I am not an Android Guru. And unfortunately, if your phone is not an A789, I won't be able to help you deep in technical details. Cybermaus is the most skilled of the two of us, technically speaking, and he may lack time to answer correctly every request he is regurlarly faced with.
Okay, I do not know your phones and don't own them. So, distant debugging is much harder in these conditions. But the first things you should check, before applying Cybermaus' patches, are :
1) if encryption works with stock rom
2) follow thoroughly all steps I described in "Second step: offline protection" of the second post of this thread :
- your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. If you don't have this information from the manufacturer, install Terminal Emulator from the Play Store and type 'mount' in it. You should see lines beginning with /[email protected] and /[email protected] If this is not the case, I fear encryption won't be able to work on your device.
- use aLogcat to track down the origin of the failure (see resources on the internet to learn how to use it, and links I have put in the second post)
3) Be sure that required modules are built into the kernel you use, especially dm-crypt
4) Post your results and cross your fingers that either this is a problem I have already encountered (in this case I may help you further), or Cybermaus see your posts.
While this script did allow me to encrypt my phone, it also shrunk my /data partition to roughly 1.1 GB.
Any ideas on how to expand it back to a reasonable size? I supposedly have 4 GB of ROM, and I assume more than 1 GB ought to be available for data.
Sent from my HTC Sensation using xda app-developers app
Thank you for your nice guide.
Only one thing is missing: baseband security.
Attacks on the baseband system requires very skilled people. Such as government agencies. It is believed they use baseband attacks to break into almost every mobile device. And there is only little you can do. Some vendors like Cryptophone have mobile devices with a hardened Android system. All others have no way to protect their device against baseband attacks.
Is this patch and reasoning still valid for newer android releases.
I am running a custom kitkat rom and twrp on a note 3 and can't encrypt so im looking for a fix.
I have been looking around for fixes but different posts blame different things.
Sometimes its the fact its a custom recovery, sometimes its that root is on the device and then there is this reasoning
Is there a way to find out the cause and fix for kitkat?
Virus
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
u2funker said:
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
Click to expand...
Click to collapse
Maybe false alarm.
Lossyx said:
Maybe false alarm.
Click to expand...
Click to collapse
no, but if you search for these file, you will find some which work and which are without viruses. Check the link..it is not an zip file..it is an exe file
@cybermaus: just tried flashing the two *.zips on my Galaxy S 4 Mini running CM 12 (Android Lollipop) because my logcat tells me I'm getting the described cryptfs error. It seems my /data partition doesn't have that 1 MB of unused space needed for encryption. Now I would love to encrypt my phone using CM's integrated function without having to completely format the internal storage (because that's the other workaround I found: flash stock rom, wipe data (factory reset), flash Custom Recovery, flash CM again)
Do you have the time and device to update your script so it works with Android Lollipop as well? I see a lot of people come across this issue recently so there would be definetly use for such a nice script like yours!
Thanks for sharing this with us!
-Teutone
no available for download any mirror ?
Or write the script on the thread.
Thanks
Can you post the scripts? links are dead!
---------- Post added at 16:33 ---------- Previous post was at 16:32 ----------
cybermaus said:
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Click to expand...
Click to collapse
links are dead. Can you post the scripts?
Hi!
trying to fix my imei I accidentally wiped my "persist" partition
A2017 Chinese model convert to A2017u
twrp 3.2.3.0 bootloader unlocked
persist partition is missing in my twrp backup
error:failed to mount '/persist' (invalid argument)
realy need help
Regards!
@netphone: You can format the persist partition from TWRP, with mke2fs or mkfs.ext4, as ext4 filesystem. But then your device's auto-rotate, sensors, etc probably won't be working. This is because some of the persist partition's contents aren't automatically regenerated even after it is formatted.
Quite some time ago I made a backup of this partition in case of issues listed above, and then subsequently wiped it by accident. Luckily I had a backup I could restore. You can find it at:
https://forum.xda-developers.com/showpost.php?p=75981746&postcount=1844
Several members tried it and said it works fine. Just flash the zip in TWRP.
I have an A2017U, and since you are converting to A2017U from A2017, then it should work. It's not like you have anything to lose, your partition is already wrecked anyway, the most that happens is it doesn't work out. In the future, I would advise making your own backup. It (the partition) is only 32MB in size.
AnonVendetta said:
@netphone: You can format the persist partition from TWRP, with mke2fs or mkfs.ext4, as ext4 filesystem. But then your device's auto-rotate, sensors, etc probably won't be working. This is because some of the persist partition's contents aren't automatically regenerated even after it is formatted.
Quite some time ago I made a backup of this partition in case of issues listed above, and then subsequently wiped it by accident. Luckily I had a backup I could restore. You can find it at:
https://forum.xda-developers.com/showpost.php?p=75981746&postcount=1844
Several members tried it and said it works fine. Just flash the zip in TWRP.
I have an A2017U, and since you are converting to A2017U from A2017, then it should work. It's not like you have anything to lose, your partition is already wrecked anyway, the most that happens is it doesn't work out. In the future, I would advise making your own backup. It (the partition) is only 32MB in size.
Click to expand...
Click to collapse
can i also use it on G version? i think something messed up in my persist partition.
i have read this on xda:
PERSIST - contains data which shouldn't be changed after the device is shipped, e.g. DRM related files, sensor reg file (sns.reg) and calibration data of chips; wifi, bluetooth, camera etc.
Some package installers such as OpenGapps also make use of this partition to read configuration file.
also contains calibration data etc.I like to try this as i counter calibration issues.
If yes,any recommend on what OS i should flash this? And should i wipe my persist partition before flashing yours?
I try to backup my own persist partition in TWRP,but in backup it shows my perist partition is 0mb.On diskinfo it says my partition is 27,5mb in size,but others report theirs are 32mb in size.
EDIT; i still did a backup in twrp even though it says the size is 0mb.The backup map is like 300kb.
how did you wiped persist partition? In twrp wipe section persist is not showed
@Predatorhaze: My zip may work on G, or not, you can try and let me know.
You can "wipe" persist with the command:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/persist
And back it up with:
dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
Run these commands from TWRP terminal. dd is a famous Linux command line utility.
The partition is exactly 32MB in size.
AnonVendetta said:
@Predatorhaze: My zip may work on G, or not, you can try and let me know.
You can "wipe" persist with the command:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/persist
And back it up with:
dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist.img
Run these commands from TWRP terminal. dd is a famous Linux command line utility.
The partition is exactly 32MB in size.
Click to expand...
Click to collapse
and after the command,i mount persist and flash the zip?
thanks!
@Predatorhaze: If you wipe persist with my command, then it will be unmountable prior to flashing the zip. This is because dd destroys persist's ext4 filesystem by zeroing it out. After the zip is mounted TWRP should mount persist automatically, but if not you can do it manually.
You should Google the difference between partition, volume, and filesystem.
AnonVendetta said:
@Predatorhaze: If you wipe persist with my command, then it will be unmountable prior to flashing the zip. This is because dd destroys persist's ext4 filesystem by zeroing it out. After the zip is mounted TWRP should mount persist automatically, but if not you can do it manually.
You should Google the difference between partition, volume, and filesystem.
Click to expand...
Click to collapse
When i used your command it says no more space left,32mb copied,0mb.Then i flashed your persist zip and rebooted twrp.
Now i flashed ROM and gapps magisk etc.I see playstore mounts persist (dont know why),after flashing all files i manually wiped all folders and files from persist folder and flashed your persist zip again,then ive powered off my phone,turned on and booted.Thanks
I already noticed the size is different,my persist folder was smaller in size,and also the thermal kicked in when booted on os.Phone was warm and CPU limited to 1036mhz.I noticed this thermal kick in was gone since i complained about battery.
My battery was sitting on 12%,i run geekbench cpu bench...half way of the bench my phone shut down (shows 0% battery,but half way in bench it was still 12%).I decided to just power on my phone and boot.My phone booted the os and shows 10% battery.Dont know if this is a bug in geekbench or something else..
I reached 4+ hours sot with 2 hour of gaming (from 100% to 10%).
Also i charged my phone at night ( i do this rarely).when i woked up my battery was 100% and unplugged the charger,when i unplugged it droppped direct to 99%.Is this normal? I can remember with my previous devices when i charged at night,and unplugged in the morning,it sits on 100% for a while
@Predatorhaze: It is possible for a computer (which a phone is) to shut down while running stress testing software, if this happens then it means your setup is unstable and couldn't handle the tests. Sometimes the OS will intentionally crash itself (BSOD) to prevent damage to itself or hardware. I like to overclock PCs as a hobby, and while there's a lot I don't know, I've been at it long enough to master the basics. I regularly do benchmarking and stress testing to see if my setups are rock solid, or need more tuning.
AnonVendetta said:
@Predatorhaze: It is possible for a computer (which a phone is) to shut down while running stress testing software, if this happens then it means your setup is unstable and couldn't handle the tests. Sometimes the OS will intentionally crash itself (BSOD) to prevent damage to itself or hardware. I like to overclock PCs as a hobby, and while there's a lot I don't know, I've been at it long enough to master the basics. I regularly do benchmarking and stress testing to see if my setups are rock solid, or need more tuning.
Click to expand...
Click to collapse
Thanks.
Can you maybe share your stock /sys folder also?
@Predatorhaze: Why do you need my sys directory? I'm not running a stock ROM, BTW.
AnonVendetta said:
@Predatorhaze: Why do you need my sys directory? I'm not running a stock ROM, BTW.
Click to expand...
Click to collapse
To compare with mine and maybe replace it
@Predatorhaze: Umm...no. That directory contains thousands of subdirectories and quite a few files. As well as a bunch of symbolic links that point to other places. It wouldnt be quick or convenient to make a zip. Do you even know what Android/Linux use /sys for? I do, and I'm pretty sure you don't even understand what you're really asking for. In any case, sys won't hold the answer to your questions. It seems to me that you are off on a wild goose chase.
AnonVendetta said:
@Predatorhaze: Umm...no. That directory contains thousands of subdirectories and quite a few files. As well as a bunch of symbolic links that point to other places. It wouldnt be quick or convenient to make a zip. Do you even know what Android/Linux use /sys for? I do, and I'm pretty sure you don't even understand what you're really asking for. In any case, sys won't hold the answer to your questions. It seems to me that you are off on a wild goose chase.
Click to expand...
Click to collapse
No,i dont really know,and you are right.Im still trying to find out my battery % problems (And no,its not because my battery is degraded)
i used in terminal cat /sys/class/power_supply/bms/charge_full and it showed something with 29xxxxxx,where i think my battery cap is around 2900mah and i believe this,as i reach more than 4 hours sot with gaming included.
Thank anyway for all your help!
AnonVendetta said:
@Predatorhaze: It is possible for a computer (which a phone is) to shut down while running stress testing software, if this happens then it means your setup is unstable and couldn't handle the tests. Sometimes the OS will intentionally crash itself (BSOD) to prevent damage to itself or hardware. I like to overclock PCs as a hobby, and while there's a lot I don't know, I've been at it long enough to master the basics. I regularly do benchmarking and stress testing to see if my setups are rock solid, or need more tuning.
Click to expand...
Click to collapse
this shutdown only happens when its less than 20% or something.I also noticed when its less than 20%,geekbench shows 3 clusters where one of them is at 0.0ghz.
maybe some problem with fuel gauge.
i tried to reset the gauge at 100%,but sot is just worse now
@Predatorhaze: I recently received a private message from @Choose an username..., his unedited PM is below:
heads-up about ter
Just some info, do what you want with it:
This Predatorhaze guy is the most toxic user in our side of xda, he thinks his battery is pristine, asks for help, then refuses it and tries to find a culprit anywhere
A couple months ago he claimed that Oki's "Deep Wipe" function made his battery go bad (which he claimed beforehand too) and his explanation was that it made the system believe he had two batteries...
His shutdown problem when he ran a benchmark is not because of system instability or whatever, that's rather overclock/volt specific as we don't really have any oc kernel. The problem he has is that BCL acts when voltage goes below the safe threshold, because his battery is so wrecked that it can't withstand high current usage (i.e. high internal resistance and other stuff). I'm not going to tell this to him because he'll branch out as he usually does.
He's blaming the persist partition because his lockscreen says 5V charging speed, that's what he said in Telegram ? i mean we appreciate you keeping him busy, but you're just wasting your time. if anything just try to convince him that his battery is K.O., maybe he can change it and stop destroying whatever's left of this...
My response:
Re: heads-up about ter
I don't really need a heads up about anyone, although he is a waste of time. He doesn't know much of anything, but he is looking for any excuse at all that will explain his battery issues. If you ask me his battery is bad, I already tried telling him this. I only continue to try to help him because I figure he might listen at some point, but he's wearing my patience thin.
You dont need to tell him anything directly, I've decided I'm going to forward him a verbatim copy of your PM, and maybe my response as well. I really don't feel that it's OK to trash talk someone behind their back, especially when you wouldn't say the same things to them directly. If I have an issue with someone, then I take it to them direct, I'm not known for mincing words. Maybe he will just "lose it" on the forum and get himself permabanned. But then it will be his fault.
Mind if I ask what Telegram group you are a member of? Is it related to LOS?
His response:
Re: heads-up about ter
Who says I wouldn't say it to him directly? All of us did, he eventually got banned on the Schwifty group, made a different account, got banned again. It's borderline bullying on the GSI testing group. Now he's going around every old ROM thread commenting how they don't work
Also attach a verbatim copy of your comment, of course ?
Which has led up to now...honestly, your battery is going bad, you are just unwilling to accept it. Please stop wasting people's time, being antagonistic in general, and being more stubborn than a pack mule. Your request for my /sys directory is asinine, up until this point I've just been trying to help you, but you are deluding yourself. The sooner you replace your battery, the sooner your issues will be resolved. I will no longer continue to post in threads where you complain about your battery and post about weird off the wall **** that you think are supposedly causing your problems. Enough is enough.....
ok enough said.
i already told 100 times,these problem occurs on different setups,what they say is wrong.
that thing about geekbench,doesnt happen always.
and i have changed my battery...it sits on 50%.Doesnt chharge up,doesnt go down,just sits on 50%.
also sometimes when i change bootstack+vendor partition,my battery shows different % after.