Users who took the most recent update for the CM Installer channel for d2 (Galaxy S3) and jf (Galaxy S4) devices may have seen their devices reboot into a broken state. We take full responsibility for this issue. Items such as non-boots are to be expected to occur in nightly or ‘experimental’ builds, not the stable channel of the installer – the issues were simply unacceptable.
What happened?
Last week, we made the preparations to generate new incremental over the air updates (OTAs) and full builds for the CM installer release channel. Test builds were generated early in the week and QA tested against all of the Nexus devices and a couple other devices. Builds were cleared for release and regenerated on Friday, for a roll-out on Saturday.
The failures seen arise from unaccounted for repercussions of the recent effort to unify the d2 and jf device trees. The unification process itself was a success, the need for variant builds has been eliminated on these devices. When we went to roll the builds for release on Friday, we took into account that the unification process was still new, only being tested against the nightlies for 3 days at that point; as such the CM Installer releases generated on Friday were on the non-unified type (ie, individual builds for each d2 and jf variant).
This all should have been perfectly fine and is representative of our previous installer rollouts. However, due to the unification process, the special system files that allow your phone to boot shifted locations in a way our Installer buildbot failed to account for – essentially making the d2 and jf builds that went out to users non-bootable.
On Monday, when user feedback of these issues came pouring in, we took immediate action to remove the affected builds and address the root cause in both our source (to prevent this in the future) and to enhance our QA and release processes.
No one wants to see this happen again and we are embarrassed that did in the first place.
I’m affected, what now?
Our support staff on the forums has jumped into action and provided manual and automated fixes for those affected. The simplest solution is to use the ‘adb sideload’ tool to flash a working build. As the installer itself is meant for non-technical users, we have created standalone executables (.exe) for each affected device. For those more keen on flashing the fix themselves, individual zips are also available.
Instructions and downloads for the fixes are available on our Forum support page for this issue.
Our deepest apologies for all the trouble that this has caused those affected, it won’t happen again.