Related
Hi there, since I updated (manually) to 4.2 I have noticed that my Nexus keeps giving me a message randomly Saying "Your Device Appears to be running Extremely Slow" or something along those lines?
I have also noticed abit of a laggy experience and the device struggling a little since the update
I updated manually using adb using:
adb sideload 094f6629314a.signed-nakasi-JOP40C-from-JZO54K.094f6629.zip
Which is the update I flashed.
After noticing the Message and the lag issue, I went back into recovery and tried to wipe cache.
Which changed nothing
Also, I now have no root and both toolkits report a successful root but it isnt.
What should I do?
Would a factory reset help? (Last resort? :/)
Thanks all, any answers appreciated !
Here's what I've done so far and info relating to my setup
Phone: klte - G900T (T-Mobile Samsung Galaxy S5). I'm not on SafeStrap, I'm installing to system. I'm running TWRP recovery 2.8.4.0.
I first installed the CyanogenMod 12 nightly for 20150204 with Paranoid Android GApps 5.0.1RC3. All good there. I then went to "Security" and clicked "Encrypt Phone." It didn't ask me to set a password, so I assumed it'd generate a random key for LUKS and encrypt it with the default password. All good there. It rebooted into the "Encryption Wizard," and went through encrypting the phone. Cool, I thought.
It then boot-looped on start, seemingly because it didn't yet understand how to decrypt using the default password. TWRP decrypted data on startup of the recovery just fine, so that's cool. Okay, so maybe the nightly doesn't support decrypting on boot yet. Fine. I upgraded to CM 12 20150208 (today's) and tried again. Nothing.
I then did a factory reset and wiped system, reinstalling CyanogenMod from scratch. No joy either, couldn't boot. What was weird was that I still noticed that it was mounting /dev/dm-0 at /data, so my data was still encrypted. Shoot. How to get rid of encryption? I wrote a ton of zeroes to the beginning of data to wipe out the LUKS header:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=4096
I terminated this process a while in (probably should have been more exact by specifying how much to zero, but laziness). I then ran
Code:
make_ext4fs /dev/block/platform/msm_sdcc.1/by-name/userdata
Next, reboot recovery, and all is well. Install ROM, and try encrypting again, this time setting an unlock code so that it actually uses a real encryption key instead of default. It reboots, takes a really long time, and then just continues into regular boot, no encrypting taking place, it seems to bypass that. Dangit.
I then tried switching off and on again the set_encrypted_filesystem flag to recovery:
Code:
adb shell recovery --wipe_data --set_encrypted_filesystem=off
adb shell recovery --set_encrypted_filesystem on
No joy, when I try to encrypt it still just reboots regular (albeit really slowly) into regular system and doesn't encrypt. Ugh, I feel like I've lost all progress. I've made sure to clear Dalvik and regular caches on each try, so things shouldn't be persisting. I had an old backup of the stock T-Mobile ROM, so I flashed back to that, and then tried installing CM 12 again and encrypting, and no matter what I do, I can't get to that encryption screen. (my original T-Mobile backup had EFS, Modem, etc. basically everything that TWRP would let me include) [email protected]##$!!! Y U NO ENCRYPT!?
What are my next steps? How can I see what happens in that boot, ie what fails, so I can fix it and get onto my lovely life outdoors?
Shoot, logcat shows the following
Code:
E/Cryptfs ( 241): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
I'd better just zero out the entire thing to bypass this madness. Maybe that's what I screwed up?
I wrote all zeroes to the data partition to clear it out completely:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=512
Then, encrypt, and fail to encrypt. Output from logcat:
Code:
E/Cryptfs ( 242): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 242): Error getting crypt footer and key
I'm now going to try again by doing
Code:
adb shell dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=512
adb shell recovery --set_encrypted_filesystem=on
We'll see what happens. This is a weird process.
I am no expert but I had trouble with encryption on my s3 with cm rom a while back.
What eventually helped was to flash official ROM and recovery using Odin, which brought the phone back to life. and then flashing whatever you need.
Hope it helps you.
I'll have to try that. I'm compiling a list of what to try next. This is a bit of a nightmare, but I'm convinced that eventually I can get back to the way it was originally.
Okay, so all this is pretty spooky stuff, but here's what actually worked.
Grab the latest stock ROM. This will take you forever trying to find it on a stupid pay-per-download website and you'll have to hack your way around or through it to get to the download (which won't complete if you have a free account because it's too big, be forewarned). After your (premium!) download completes after 3 hours, use Odin and flash. Once your phone reboots, it'll see something's wrong with /data and will fix it. I'm not sure what fixing it entails, but I have to imagine it's something like wiping the LUKS header/footer (yes, there actually is something called a LUKS footer, as I discovered through this process) and reformatting the partition. It'll reboot again, and you'll be in happy stock land.
Next, install your recovery weapon of choice using Odin (reboot bootloader, flash, reboot recovery).
Next, wipe system and install CM 12. (20150204 works for me) Boot into CyanogenMod, and go to encrypt the phone. Here's the catch: you must use a PIN that's longer than 4 characters. I found this out the hard way. I'm not sure if six characters are required, but my four-character PIN simply didn't work and was the source of so much frustration. Give a good PIN or passphrase (passphrase is obviously better) and go forward with the encryption. My device rebooted a bunch of times and seemed to get into a boot loop. However, on each boot, it'd ask for the PIN, so I knew I was getting somewhere. Unplug it from the wall, and it should boot into the ROM.
Thank goodness, I lost a lot of time on this today.
An interesting aside: it seems that now in Android you can set a different disk encryption passphrase than your screen unlock pattern. FINALLY! Android Lollipop is awesome!
Having the exact same issue with multiple devices!!!
it is always the same! if a device was encrypted on cm12 and you wipe out everything, you will run into that problem again.
So, if a device is used and you want to format it and reuse it, the encryption will always fail! That can not be the right approach!
Understand the problem.
CyanogenMod 12 as of this point doesn't support the default encryption password, which is why it fails to boot. If the encryption password gets set to the default password, like if you change your screen pattern and not specify it for encryption also, it will fail to boot. This is a bug in CyanogenMod 12.
Your recovery also has a bug. If and when you factory reset, if the device is encrypted, the recovery should overwrite the encrypted filesystem footer with zeroes and then recreate an ext4 filesystem there and configure it properly. It doesn't, which leads to this annoying problem of not being able to boot.
rfkrocktk said:
Understand the problem.
CyanogenMod 12 as of this point doesn't support the default encryption password, which is why it fails to boot. If the encryption password gets set to the default password, like if you change your screen pattern and not specify it for encryption also, it will fail to boot. This is a bug in CyanogenMod 12.
Your recovery also has a bug. If and when you factory reset, if the device is encrypted, the recovery should overwrite the encrypted filesystem footer with zeroes and then recreate an ext4 filesystem there and configure it properly. It doesn't, which leads to this annoying problem of not being able to boot.
Click to expand...
Click to collapse
Still struggling with an S4 mini, going back to stock and reflashing again works, but after encryption i have a lot of FCs and clearing cache etc. does not help @ all
So you mean, setting a pin BEFORE encryting will cause this fault?
Cheers,
saint
saintxseiya said:
Still struggling with an S4 mini, going back to stock and reflashing again works, but after encryption i have a lot of FCs and clearing cache etc. does not help @ all
So you mean, setting a pin BEFORE encryting will cause this fault?
Cheers,
saint
Click to expand...
Click to collapse
Not exactly. If you setup encryption with a password or PIN, the encryption should more or less work. If you then change your PIN or password and that change doesn't hit the disk (ie: you elect not to use your screen unlock password as your encryption pasword), the default password will be used, which will fail on boot.
rfkrocktk said:
I wrote all zeroes to the data partition to clear it out completely:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=512
Click to expand...
Click to collapse
This is gonna be hella necroposting, but I did the same thing on different device and I know what I did wrongly. You can't just blow away the entire partition because the last 16KB needs to be dedicated to the crypto footer. Without that, Android has nowhere to store the encrypted key, "magic" header, etc. it needs to process the rest of the partition. That's also why FDE that isn't hardware-backed isn't a great idea. Anyway, that's all. Time to reformat using a slightly smaller filesystem size.
LUKS AFAIK typically uses a header and not a footer on these volumes, which is why I was confused. No idea why the logic is better to store these things at the end of the disk, it makes it much more difficult to target easily.
My N910F started being unstable about 6 months ago, with stock firmware.
At first it was clearable with a factory reset so I assumed it was a bad app, but it's now at the point where it bootloops even after reformatting all partitions and reinstalling roms+kernels (it happens with stock or custom roms/kernels)
To cap it off, it's even possible to provoke a crash inside TWRP 2.8.1.0 by issuing a simple "dmesg" command in the terminal
Does anyone have suggestions?
Turno off finge print scanner and android encryptation
just updated to twrp 2.8.7.0 and having the same problem.
EclipseX said:
Turno off finge print scanner and android encryptation
Click to expand...
Click to collapse
It's not getting past the bootup screen on any rom to be able to do either - and I've never enabled encryption anyway - not that it matters as both are disabled on a factory-fresh installation of any rom (stock or modified)
The crash on dmesg is one thing that I'm particularly worried about. Can anyone else replicate this behaviour in recovery?
It's really too bad that CWM or TWRP don't contain badblock and memory testers.
After writing zeros to the entire /cache /system and /data partitions (dd if=/dev/zero of=/filesystem/dummy), the phone finally stabilised.
My hypothesis at the moment is that there's a SSD badblock lurking somewhere. It'd be interesting to know if there are any tools which can analyse the flash chips (on par with smartctl)
I need help getting a logcat while my phone is shutting down and also while it is booting up.
Here is some history of my problems which will explain why I need to do this.
Note 3 sm-n900v
Currently running OF1 firmware and Alliance t-mobile rom
Rooted and unlocked bootloader TWRP recovery
I got this phone used for cheap and thought it would be an easy fix. I started with a clean odin of the stock OF1 firmware to put it in factory condition. Everything went great and had good signal and 4G LTE ran smooth and set up with no problems.
After the first time I rebooted the phone I had no signal. Checked About phone and my IMEI, baseband and serial number were gone.
I reflashed the phone in odin and everything was back. Another reboot and all is gone again.
I have tried different roms after rooting including some AOSP roms and always the same result.
I have checked to make sure that the phone wasen't a victim of the "NVbackup/restore" bomb and my NV partitions do not seem to be corrupted.
When I power off the phone it seems to take a long time to shut down (1-2 min.) so I suspect that something is being rewritten on the phone during a reboot. This is why I need to get the logcats so I can have some wizard/guru/hero/Android God read them for me and hopefully tell me what is happening to the phone and how to fix it.
I can work in ADB if someone would be kind enough to give me the commands needed to get the logs and where to post them or who to send them to for help.
I'm old but not stupid. Just an old fart that needs some help getting across the Android freeway.
Thanks in advance to anyone that can help.
Loaderboy
"got the phone for cheap" - did you call Verizon and inquire if the ESN was blacklisted?
If not, I would inquire before trying anything else.
(for shutdown; assumes you are rooted.)
Code:
adb shell
su
cd /data/local/tmp
cat > watcher.sh
#!/system/bin/sh
cd /data/local/tmp
logcat -c
logcat -v threadtime > watch_shutdown_logcat.txt 2>&1
^D
chmod 755 watcher.sh
./watcher.sh 2>>/dev/null &
exit
then reboot.
I know it's a pain in the butt to re-Odin the phone & re-root in order to run a single experiment, but you might also try the reboot cycle with the phone in airplane mode (or better yet in a location where you know you do not have a cell signal) to see if that has an effect.
Does the rooting process require a reboot? If so that would seem to be a chicken-and-egg problem - if your IMEI gets wiped on the first shutdown, then it would be hard to install a new ROM to find out whether it is carrier ROM software that is performing the changes.
Other possibilities: an intermittent hardware problem that is being mis-diagnosed as software behavior. If this were the case, occasionally the problem would appear even after a fresh Odin flash.
Other ideas include performing checksum (md5) signature comparisons on the stuff in /firmware and /firmware-modem before and after reboot to see if anything is changing, e.g.
find /firmware /firmware-modem -type f -exec md5sum {} \;
PS This advice doesn't mean I'm planning on helping you examine your logcats, but you should feel free to put them in a pastebin and provide the link here. You might want to scrub the file of any personal or device identifier information before you do that.
No the phone is not blacklisted, first thing I thought of. The problem happens on Verizon and Tmo roms alike.
The last time it lost the IMEI and baseband I got it back when I flashed Alliance rom but I havent rebooted since. The phone didn't lose root so I think I can experiment without odining the stock firmware and rerooting.
I will get the shutdown logcat and see if I can find anything before posting it.
Thanks so much for your quick reply.
The observation that it is ROM-independant is significant.
That would suggest that it is less likely to be due to a piece of application software unless all the ROMs carried the same application/code, or the functionality was coming from the TrustZone, or perhaps code in a kernel shared in common between ROMs exhibiting the behavior.
You seem to be suggesting that it can be corrected by simply flashing a new ROM. Normally that only involves the /system, /cache, and /data (when you wipe) partitions not the /firmware or /firmware-modem partitions.
It's just one hypothesis, but my money is on flaky hardware that causes a failed initialization during boot up. Evidence for that might be:
(1) boot the phone several times after you lose IMEI, both warm reboots as well as shutdown/boot and shutdown/battery pull&reinsert/boot. If it comes back up during any cycle... flaky hardware. (Note also that if you put the phone on the charger when it is "off" it actually performs a "silent boot"... I think the bootloader does this by providing the kernel with an alternate (skinny) ramdisk. In any event, many pieces of hardware could be fully powered up & kernel initialized when doing this, so potentially this could affect flaky hardware. Just be aware of it so you are correctly appraised of "how many time did I boot this thing?")
(2) Alternatively, NOT recovering service in a reproducible manner (e.g. flash & boot a ROM 4 or 5 times using the exact same procedure and one of those times service is not restored) also would be indicative of intermittent hardware troubles.
(3) if you have TWRP installed and the problem was due to some stateful behavior (e.g. something recorded into a file on the previous boot), performing a full wipe of /data might alter the behavior as that is the most likely place for it (esp. since you say that ROM flashing cures the problem). Try wiping & booting several times - does the problem come & go?
well I rebooted and lost signal. I then booted to TWRP and wiped data and still no signal.
I did this 3 times and no signal. Then I wiped dalvik /art cache and cache without wiping data and signal is back.
Getting closer. I will reboot to lose signal and then reboot to TWRP and wipe each one seperatly to see if I can narrow it down.
Stay tuned.
Wiped dalvik/art cache and signal is back. Tomorrow I will restore my stock backup and see if it works on that as well.
Thanks for giving me the tips on where to look. If it works on the stock rom I will then have to try to find out what is causing this to happen.
... and the result is?
.
bftb0 said:
... and the result is?
.
Click to expand...
Click to collapse
Flashed stock backup and everything was there. reboot and it's all gone. Boot to recovery and wipe dalvik cache and baseband IMEI etc. all back.
Sorry for the long break but spent the weekend moving a friend.
Sent from my SM-N910P using Tapatalk
loaderboy said:
Flashed stock backup and everything was there. reboot and it's all gone. Boot to recovery and wipe dalvik cache and baseband IMEI etc. all back.
Sorry for the long break but spent the weekend moving a friend.
Sent from my SM-N910P using Tapatalk
Click to expand...
Click to collapse
Looks like you have your work cut out for you. Somehow I doubt you are going to find something meaningful inside of /cache, but I'd look there first since that is likely to be the simplest in terms of effort.
I suppose you could try a binary division method of manually deleting half of the .dex files and the corresponding entries in places like
/data/system/packages.xml
/data/system/packages.list
/data/system/install
/data/system/users/0/package-restrictions.xml
/data/system/users/0/runtime-permissions.xml
and then iterating (the divide the right group by half) but thats gonna get tedious fast - and possibly just cause bootloops or hangs.
Frankly, I still think there is an underlying bit of flaky hardware - if the ESN was clean, what would be the point of software being intentionally coded to "turn off the phone" on an otherwise clean ESN device, and a completely vanilla ROM (i.e. no personalization by initialization of a Google account credential, no market apps, etc).
If you decide to use logcat and you discover that you need to launch on boot because the logs are rolling over before you can manually run a logcat (very likely because of the long Dalvik rebuild times), you will either have to choose a ROM which has a hook for auto-starting a script (e.g. CM13 userinit.sh files), or you have to re-pack the boot image to execute a one-shot service during late boot (customizing init.rc), making sure to put the logcat invocation into the background so the service doesn't block init. In both those cases, make sure you write the log to someplace like /data/local/tmp - you can't use /sdcard as the automounter tends to mount it quite late in the boot.
good luck
Hello, guys and gals!
I think that I may have messed my only phone up too much. My phone is a Samsung Galaxy Grand 2 Duos SM-G7102 ms013g that was bought around 2014.
Some background info (very long, if you don't want to waste your time reading all this, skip all the grey parts until you reach "The Problem"):
It was originally owned by my mother. It all started when my local carrier decided back in around 2015 or 2016 that my Windows Mobile phone that was running Windows Mobile 6.0 until it hard bricked itself that their network is no longer compatible, I waited patiently until my mother had been gifted a completely new phone in 2019. This resulted in my mother giving me her old phone with my SIM card in.
In late 2020, I started using my phone for hanging out with my friends, but I also started charging it with the power brick that I have until I finished all my conversations each day. It was performant at the time.
When I started using Instagram, I realized that I couldn't post pictures, so I started investigating the app info and found that it's running a version which was released in 2018. The newer updates required running Android Lollipop or greater, so I installed custom ROMs that allowed me to run the latest version of Android. The last ROM that I flashed was Resurrection Remix Nougat.
Because I bought a Samsung Galaxy Tab S8 that came with Android 12 back in June 2021, I decided to update my phone to LineageOS 19.1 with Android 12L obtained from this thread: https://forum.xda-developers.com/t/rom-unofficial-ms013g-12-lineageos-19-1-stable.4516799/ on November 2022. Everything went fine until 2023 started.
The Problem
-----------
My phone was running Android 12 in a semi-stable fashion, with the following issues discovered:
- Taking very long to boot up because it was showing the Samsung logo for around 2-3 minutes
- Some of the UI is not running at 60 FPS, especially when scrolling down the notification bar
Now, it was suffering from a major problem, which made me have to update the time and the date each time my phone booted up. Upon reboot or a cold boot, the phone would reset its time and date to a date and time that I've installed Android 12 on back then. This resulted in my phone not connecting to WiFi until I set the date and the time back to today's date.
Thinking that it's from LineageOS 19.0, I proceeded to download LineageOS 18 Android 11 Go (https://forum.xda-developers.com/t/rom-android-11-go-ms013g-lineageos-18-1.4512867/) and TWRP 3.7.0-9 (https://forum.xda-developers.com/t/recovery-ms013g-twrp-3-7-0_9-0-for-ms013g.4514667/), fully understanding the warnings that may have come with both the threads. Then, I rebooted my device to recovery.
First, I ran a backup of my device, but I saw that everytime I make a complete backup off TWRP, the compressed size was actually bigger than the total size by around 40 MB. When that finished, I proceeded to install TWRP to the recovery partition by clicking on the Install Image button and selecting the TWRP image. I then rebooted into recovery again and saw that it's running the updated version.
I proceeded to wipe the device completely (dalvik, system, cache, data) except the external SD card that was holding the ROM files, which went fine. I then went ahead to install the Go version of the ROM as per the thread's direction that tols me not to flash Gapps as MicroG was already included, which made the ROM lighter.
When that finished, I rebooted the phone to find that it successfully booted to Android 11, with the setup wizard showing up. It even detected my SIM card that was inserted to my phone. All went fine until I tried to access the Aurora Store, and saw that it couldn't find any application, resulting in the store only showing "No available apps" or something like that.
Next, I proceeded to download the Windscribe VPN, and saw that while the browser was loading sites fast, the download was very slow. It said that it's going to take one hour, which I wasn't going to wait for because it was too late. All that despite having an 8 Mbps connection supported by the fiber optic and not the copper ADSL wires.
As a result, I thought that maybe it was the system, so I rebooted Android.
The date and the time reset again back to when I first installed Android 12 (November 2022), but now it showed me a completely new issue. I wasn't prompted for the SIM unlock code as it used to prompt me for each time I reboot. Even worse, when I opened my phone, it no longer detected my SIM card!
When I checked the system information, I saw that the IMEI numbers went to Unknown for both my SIM card slots. My SIM card was placed on the first SIM slot. I decided that enough was enough and rebooted my phone to the TWRP recovery.
I wiped everything again (dalvik, system, cache, data) and tried to restore the phone from backup, but at the end of restoring the system, the recovery turned itself off, flashed the black screen for a millisecond, then went back to the main home screen for the recovery. I tried again, but it's the same.
So, I decided to re-install the whole Android 12 ROM from scratch, but instead of installing Gapps, I installed MicroG. I then rebooted the phone to see that instead of booting up, it's now stuck in a reboot loop.
The Samsung logo showed up for around 2 minutes and then the LineageOS boot animation showed up. After another 2 minutes, I saw that the backlights turned on. However, it kept on instead of turning off. As a result, my phone kept trying to boot until the screen went darker and the backlight turned off. After few seconds, the phone rebooted and it kept doing this cycle.
I rebooted the phone to the recovery, thinking that it might have been a compatibility issue with the recovery that I've installed, to wipe everything again. I restored the earlier working recovery, and installed Android 12 and MicroG. I rebooted, but the problem still persisted.
I rebooted the phone again to the recovery, and, this time, I reinstalled Android 12 with the Gapps package made for Android 12L. I rebooted the phone to finally see the setup wizard, but when I clicked on Start, the "Factory data reset" popup appeared with "Rebooting" underneath it. This caused my phone to reboot continuously.
I rebooted the phone to recovery to reinstall the latest recovery available for my phone. I think I may have killed my phone's software while trying to restore the Android 12 software. The time was too late, so I left my phone in the recovery mode at 100% battery charge.
I did the factory reset, but when I rebooted the phone, the "Factory data reset" popup still didn't go away. This time, when I rebooted to recovery, it showed 4% battery.
Below shots in the attachments are trying to describe what I'm seeing in my phone, the /system partition, and the /system_root partition before and after wipes as I thought that the /system_root might be the cause.
https://imgur.com/OEHsRgh
https://imgur.com/1yoGdLt
https://imgur.com/eihrtwW
https://imgur.com/J7YWkct
https://imgur.com/tafl3CY
I currently restored the recovery partition to go back to the older TWRP that didn't have /system_root.
I can't afford to buy another phone, even the mid-range ones like the Samsung Galaxy A53 or the upcoming A54, because the prices in our country recently had a huge inflation. Also, this is my only phone because my last phone, Windows Mobile, hard bricked itself.
Despite my 10 years experience with dealing with Android tablets and phones, this is my first time experiencing a problem that I can't seem to fix. I'm at a loss as to what to do now, so any kind of help would be appreciated.
Also, what caused my phone to behave like this? Should I start over by flashing the latest stock Samsung firmware from Odin?
I finally managed to get out of the "Factory data reset" loop! Here's how.
When I had a chance to discover why this factory reset loop is occurring, I proceeded to reinstall the entire system with Android 12 LineageOS 19.1 using the older TWRP 3.2.3 recovery. I also restored the data partition from the backup that I made before installing LineageOS 18.1 Go. However, it didn't fix the problem, which is strange, considering that the data partition in the backup was supposed to be pristine.
I went ahead to spin up the terminal from within the TWRP recovery to find any possible variables in default.prop that caused this to happen, but I found nothing. Then, I looked at the hexdump of a fota partition (/dev/block/bootdevices/by-name/fota) and wrapped its output using the "more" command, and saw something I've never seen before. It said something along the lines of "prepareUserData failed for system user" and "recovery".
Confused, I went as far as to open the source code of Android as found in this link (https://cs.android.com/android/platform/superproject/+/master:frameworks/base/services/core/java/com/android/server/pm/UserDataPreparer.java;l=128?q="userdata failed"&ss=android/platform/superproject) and saw something about user data preparation, so I went to turning on the USB debugging using TWRP because Android won't let me in because of the "Factory data reset" loop by appending the following properties to the build.prop file:
Code:
persist.service.adb.enable=1
persist.service.debuggable=1
My file already had the "persist.sys.usb.config=adb" line.
Upon rebooting to Android, I turned my old PC on and plugged my phone in to my PC. Then, I installed ADB using "sudo apt install adb" and executed the "adb devices" command to find that it found a device with "no permissions", so I added my device to my udev configuration. When I plugged my phone back in, I tested the command again, and saw "device".
I went ahead to test running Android again, and upon encountering the "Factory data reset" problem, I immediately took a snapshot of the Logcat of my device from my computer. When my phone rebooted to the recovery, I opened the text editor on my computer to look for potential problems. As I scrolled down, I saw the following:
Code:
11-09 09:56:17.500 245 257 E cutils : Failed to chmod(/data/media/0, 1528): Permission denied
11-09 09:56:17.500 245 257 E vold : Failed to prepare /data/media/0: Permission denied
Weird!
My phone was still in the recovery mode at the time. I rolled up my terminal emulator from my phone and checked the permission of the affected folder using "ls /data/media -l" and saw something that is beyond imagination. The user and group permissions for the "0" folder was set to "root"! I wrote the "chown -R media_rw:media_rw /data/media/" command thinking that it'll fix the factory reset loop. Upon rebooting, same issue occurred!
Thinking that I may have missed something, I proceeded to look for possible solutions to this debacle, until I found a viable solution. I captured the Logcat, looked for the error, and found this:
Code:
11-09 09:56:18.189 245 257 E cutils : Failed to chmod(/data/media/0, 1528): Permission denied
11-09 09:56:18.186 257 257 W Binder:245_3: type=1400 audit(0.0:112): avc: denied { setattr } for name="0" dev="mmcblk0p25" ino=129282 scontext=u:r:vold:s0 tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0
11-09 09:56:18.189 245 257 E vold : Failed to prepare /data/media/0: Permission denied
11-09 09:56:18.186 257 257 W Binder:245_3: type=1300 audit(0.0:112): arch=40000028 syscall=333 per=800008 success=no exit=-13 a0=ffffff9c a1=b24c88e0 a2=5f8 a3=0 items=1 ppid=1 ppcomm=init auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 exe="/system/bin/vold" subj=u:r:vold:s0 key=(null)
In my phone, I opened the terminal, and wrote the following commands:
Code:
chown -R media_rw:media_rw /data/media/
find /data/media/ -type d -exec chmod 775 {} ';'
find /data/media/ -type f -exec chmod 664 {} ';'
restorecon -FR /data/media/
When I rebooted my phone, the "Factory reset" issue went away! My SIM is now seen by my phone! The only thing now is that I'll have to set all my applications up, as even Windscribe, Instagram, and all apps are now prompting me to provide login details or configure them. The phone still works smoothly, but still suffers from the date and the time problem.
I prefer to have the date and time problem fixed. Any advice?