jam97
Senior Member
- Mar 26, 2013
- 95
- 15
We really appreciate your efforts and your time no matter what happened.Okay, here's some problem analysis.
PROBLEM DESCRIPTION
@killer2020 and @johan111 report a hard brick after using my cm-12.1 upgrade package to upgrade an existing KitKat installation. After upgrade, the device seems to hang somewhere during andriod boot, the screen displaying a message such as "Android is upgrading app 9 of 89". When the user then powers off to reboot, the device does not boot anymore, but only powers up to apx mode. This suggests that either the bootloader became corrupt and/or the partition table.
PROBLEM ANALYSIS
I used the same package on my device, but I did not upgrade an existing KitKat install, since I had earlier flashed some lollipop system images using fastboot. I don't know in what ways these two approaches differ from what @johan111 and @killer2020. I currenlty assume that flashing a partition using fastboot first formats that partition, while using an upgrade package just overwrites those files that differ from previous versions. This would suggest that the problem is caused by packages and libraries that I removed since KitKat, such as nvcpud.
What I find strangest is that the upgrade package contains information for only two partitions, i.e., boot and system. It leaves other regular partitions (cache, user data and recovery) alone, and it certailnly shouldn't touch the more "exotic" partitions such as misc and staging, let alone the bootloader partition. Furthermore, the actual installation of the upgrade package apparently succeeds without problem, and the device reboots normally first, suggesting that, at that point, the bootloader, boot and system partitions are all still okay. Only later during the upgrade process, some android process apparently does things to partitions that it shouldn't do. (That even shouldn't be possible, especially not with selinux enforcing. I would personally expect that problems might arise with testing a new rom. In fact, developing can be seen as a long series of soft-bricking and unbricking one's device, going back and forth between recovery, fastboot and booting android, but since there is no reason to assume that anything would touch the bootloader, there is also no reason to assume that a hard brick would occur.)
Hypotheses:
1. Some package from KitKat that is no longer present in my Lollipop version goes ballistic during first android boot after updating.
2. The existing KitKat + Gapps combination leaves gapps in place upon upgrade, but that's too much data to also hold the Lollipop upgrade, which the updater script doesn't properly check, and then during conversion from dalvik to art this somehow takes too much space in system... Ehm, well, I don't really understand where this hypothesis is going...
My expectation is that, as a solution, the upgrade should format system as part of the upgrade process.
EXPERIMENTS
I'm thinking about a series of experiments to test these hypotheses, all using an existing KitKat installation as a starting point. I'll use my second A2109, which currently is on Lollipop as a test device, which I will first downgrade to a clean, running KitKat installation without gapps, and before each test I'll boot KitKat three times to verify that it works correctly.
1. Perform a factory reset (which, as far as I understand, formats cache, and user data partitions), format system, and install cm-12.1 using fastboot, with a boot.img and system.img.
2. Perform a factory reset (which, as far as I understand, formats cache, and user data partitions), format system, and install cm-12.1 using a regular update package with recovery.
3. Format system, and install cm-12.1 and then gapps using a regular update package with recovery.
4. Find all files in system that were removed after KitKat, erase them, reboot to recovery, and install cm-12.1 and gapps using a regular update package with recovery.
5. Install gapps for KitKat, find all files in system that were removed after KitKat, erase them, reboot to recovery, and install cm-12.1 and gapps using a regular update package with recovery
If a brick occurs after step 1 or 2 then I'm quitting android development, because that would be black magic to me.
If a brick occurs after step 3, then apparently something in cache is malfunctioning. Almost as bad as after step 1 or 2, but at least it offers a way forward using a normal system image.
If a brick occurs after step 4, then apparently the update script needs to format system.
If a brick occurs after step 5, then apparently apparently the update script needs to format system because gapps is too much or sth.
Any suggestions are very very very welcome!
Thanks a bunch PJBrs.
Sent from my SM-N910P using Tapatalk