[ROM][5.1.1] AOSP-5.1.1 / CM-12.1 for Lenovo a2109 (20160901)

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!
We really appreciate your efforts and your time no matter what happened.
Thanks a bunch PJBrs.

Sent from my SM-N910P using Tapatalk
 
FIRST TWO EXPERIMENTS

I started every experiment by booting recovery, doing a factory reset, formating system, installing cm-11 using the upgrade package, booting cm-11 and rebooting cm-11.

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.

Success.

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.

Success.
 
Hi, @PJBrs, I want to test new rom. Before I flash it, I wipe cash & dalvik cash. What about factory reset, do or not? Now I am on 6.0.5.1 cwm & cm11 rom (build 01.10.15)
And where I can check md5 sum?

Big big thanks for new rom.

So, my question is right - for successfully update, factory reset is a must.
 
So, my question is right - for successfully update, factory reset is a must.
No, that's not yet a valid conclusion! In fact, my hunch is that formating the system partition is the essential bit, but I haven't gotten to that point yet....
 
FURTHER EXPERIMENTS
I started every experiment by booting recovery, doing a factory reset, formating system, installing cm-11 using the upgrade package.

Code:
Experiment 3
Format system, and install cm-12.1 using a regular update package with recovery.

Success. This shows that a factory reset is not necessary when upgrading on a clean, new kitkat install (no apps installed, no gapps installed, just a little internet browsing.

For the further experiments, I used a back-up image instead of a clean KitKat installed. I produced this back-up image as follows:
  • Boot recovery, do a factory reset, format system, and installing cm-11 using the cm-11 upgrade package
  • Install opengapps-4.4.4-nano and boot in my clean KitKat install
  • After boot, I add my Google account upon login and let it install all available updates and let it automatically download my settings and apps from my device backup (see below for a list).
  • Do a little bit of web-surfing
  • Reboot cm-11 twice
Before each experiment, I did a factory reset and formated system before installing this back-up image. This might not represent a completely typical installation, but it certainly does not qualify as clean :)

Code:
Experiment 4
Format system, and install cm-12.1 using a regular update package with recovery.

Success. This shows that a factory reset need not be necessary even when upgrading a non-clean install.

Code:
Experiment 5
Format system, install cm-12.1 using a regular update package with recovery, and install opengapps-5.1-nano.

Success.

In sum, the most probable source of bricking the tablet when upgrading from kitkat to lollipop resides somewhere on the system partition, and is either part of upgrading gapps or resides in files that I removed from lollipop that stay in place when upgrading from kitkat.

I'm now quite sure that doing an upgrade after first formating system, cache and dalvik cache is possible. A full factory reset probably offers a bit more security. Then again, in my testing I didn't have to format cache and dalvik cache for a succesful upgrade. So -- DON'T upgrade to lollipop without formating system.

One final test consist of me upgrading my existing kitkat, that I didn't use with lollipop yet. After that, who dares to test?

Code:
App list:
3DRating for OpenGL ES 2.0
Andro Sensor
Chrome-browser - Google
File Explorer
File Explorer (Plus Add-On)
Gmail
Google
Google Agenda
Google Documents
Google Text-to-speech
Osmos HD
Super Hexagon
Terminal Emulator for Android
Wakelock Detector [FULL PACK]
 
Last edited:
Final experiment was successful as well, I upgraded my primary device to lollipop. I first formatted the system partition, then I installed the cm-12.1 updater and after that I installed opengapps-5.1-nano. No need for a factory reset, or even formatting cache and dalvik cache. Who would like to step forward for further testing? The ideal tester knows his way around adb and fastboot, and is capable of changing a system board in case of emergency. After two or three successful replications of my results I think I'm sufficiently certain to put the ROM back up, with the added warning that formatting the system partition is essential before installing lollipop.
 
so what about our bricked devices what to do about them ??

There's always chances to get problems when installing new ROMs on a device. To root a device is not recommanded by Lenovo and void warranty. By doing this you accept the chances to brick your device.

PJBrs is trying to find a way to fix that and already sent some infos about brick devices. We all hope to find a way to fix that but there also some chances that there is no way to fix it and you'l have to change your M/B.

Sorry about that.
 
Final experiment was successful as well, I upgraded my primary device to lollipop. I first formatted the system partition, then I installed the cm-12.1 updater and after that I installed opengapps-5.1-nano. No need for a factory reset, or even formatting cache and dalvik cache. Who would like to step forward for further testing? The ideal tester knows his way around adb and fastboot, and is capable of changing a system board in case of emergency. After two or three successful replications of my results I think I'm sufficiently certain to put the ROM back up, with the added warning that formatting the system partition is essential before installing lollipop.

So it is very possible that something wrong went in system partition since I did factory reset (wipe data, cache and dalvik) without touching system, which resulted in a brick. It might be an important note for cm12.1 installation process.
 
So it is very possible that something wrong went in system partition since I did factory reset (wipe data, cache and dalvik) without touching system, which resulted in a brick. It might be an important note for cm12.1 installation process.
Indeed. In fact I'm going to see whether I can automate formatting system in the update package, so that users cannot shot themselves in the foot during install.

so what about our bricked devices what to do about them ??

Patience please :)

As I let you know already, I'm unable to solve this problem without help from others, of the androidroot.mobi people. I've contacted them, but I have yet to hear from them. In the meantime, I'm preparing a little fundraiser here for you and @johan111 to an amount of €30 per person, and I'm pledging €10 myself. But not before Monday, I don't have time earlier to find out how.
 
Indeed. In fact I'm going to see whether I can automate formatting system in the update package, so that users cannot shot themselves in the foot during install.

You can format /system in the update_script. It's actually rather simple, if I do recall.
 
You can format /system in the update_script. It's actually rather simple, if I do recall.
I hope so! Do you know the location of the source that builds the update_script?
 
Back
Top