This will probably not compile and may need additional work.
For tracking purposes so we know what might still need looking at
as none of this has been compiled and tested, here is a list of
the merge conflicts that I attempted to fix before pushing this
set of changes:
git pull aosp lollipop-release
remote: Finding sources: 100% (992/992)
remote: Total 992 (delta 473), reused 992 (delta 473)
Receiving objects: 100% (992/992), 1.51 MiB | 516.00 KiB/s, done.
Resolving deltas: 100% (473/473), completed with 42 local objects.
From https://android.googlesource.com/platform/bootable/recovery
* branch lollipop-release -> FETCH_HEAD
* [new branch] lollipop-release -> aosp/lollipop-release
Auto-merging verifier_test.cpp
CONFLICT (content): Merge conflict in verifier_test.cpp
Auto-merging verifier.h
CONFLICT (content): Merge conflict in verifier.h
Auto-merging verifier.cpp
CONFLICT (content): Merge conflict in verifier.cpp
Auto-merging updater/updater.c
Auto-merging updater/install.c
CONFLICT (content): Merge conflict in updater/install.c
Auto-merging updater/Android.mk
CONFLICT (content): Merge conflict in updater/Android.mk
Auto-merging uncrypt/Android.mk
CONFLICT (content): Merge conflict in uncrypt/Android.mk
Auto-merging ui.cpp
CONFLICT (content): Merge conflict in ui.cpp
Auto-merging screen_ui.cpp
Auto-merging roots.cpp
CONFLICT (content): Merge conflict in roots.cpp
CONFLICT (rename/delete): res-hdpi/images/progress_fill.png deleted
in HEAD and renamed in cddb68b5ea.
Version cddb68b5ea of
res-hdpi/images/progress_fill.png left in tree.
CONFLICT (rename/delete): res-hdpi/images/progress_empty.png deleted
in HEAD and renamed in cddb68b5ea.
Version cddb68b5ea of
res-hdpi/images/progress_empty.png left in tree.
CONFLICT (rename/delete): res-hdpi/images/icon_error.png deleted
in HEAD and renamed in cddb68b5ea.
Version cddb68b5ea of
res-hdpi/images/icon_error.png left in tree.
Auto-merging recovery.cpp
CONFLICT (content): Merge conflict in recovery.cpp
Auto-merging minui/resources.c
CONFLICT (content): Merge conflict in minui/resources.c
Auto-merging minui/minui.h
CONFLICT (content): Merge conflict in minui/minui.h
Auto-merging minui/graphics.c
CONFLICT (content): Merge conflict in minui/graphics.c
Auto-merging minui/Android.mk
CONFLICT (content): Merge conflict in minui/Android.mk
Removing minelf/Retouch.h
Removing minelf/Retouch.c
Auto-merging minadbd/usb_linux_client.c
CONFLICT (content): Merge conflict in minadbd/usb_linux_client.c
Auto-merging minadbd/adb.h
CONFLICT (content): Merge conflict in minadbd/adb.h
Auto-merging minadbd/adb.c
CONFLICT (content): Merge conflict in minadbd/adb.c
Auto-merging minadbd/Android.mk
CONFLICT (content): Merge conflict in minadbd/Android.mk
Removing make-overlay.py
Auto-merging install.h
CONFLICT (content): Merge conflict in install.h
Auto-merging etc/init.rc
CONFLICT (content): Merge conflict in etc/init.rc
Auto-merging bootloader.h
Auto-merging applypatch/applypatch.c
Auto-merging applypatch/Android.mk
CONFLICT (content): Merge conflict in applypatch/Android.mk
Auto-merging adb_install.cpp
CONFLICT (content): Merge conflict in adb_install.cpp
Auto-merging Android.mk
CONFLICT (content): Merge conflict in Android.mk
Automatic merge failed; fix conflicts and then commit the result.
Change-Id: I3e0e03e48ad8550912111c7a5c9a140ed0267e2c
Enable TWRP to reside alongside other recoveries with the naming
convention: bootable/recovery(-flag). If TWRP resides at
bootable/recovery and a device does not specify RECOVERY_VARIANT, then
it will build like normal. If TWRP resides at bootable/recovery-twrp,
then its makefiles will only be parsed if a device specifies
'RECOVERY_VARIANT := twrp'. This prevents TWRP specific makefile
warnings/errors (notably, missing DEVICE_RESOLUTION) when another
recovery is being built.
Change-Id: I8f02fffcd79c309c7123b9428eedc69af02e126e
Recovery now draws directly to the framebuffer by rolling its own
graphics code, rather than depending on libpixelflinger.
The recovery UI is modified slightly to eliminate operations that are
slow with the software implementation: when the text display / menu is
turned on, it now appears on a black background instead of a dimmed
version of the recovery icon.
There's probably substantial room for optimization of the graphics
operations.
Bug: 12131110
Change-Id: Iab6520e0a7aaec39e2ce39377c10aef82ae0c595
Make a copy of libmincrypt in TWRP source so we do not have to
ifdef verifier.cpp for various versions of mincrypt.
Remove reboot tool from toolbox (it was removed from 4.4 and did
not compile properly on some devices in older trees)
Recovery currently has a random mix of messages printed to stdout and
messages printed to stderr, which can make logs hard to read. Move
everything to stdout.
Change-Id: Ie33bd4a9e1272e731302569cdec918e0534c48a6
Due to a kernel bug and no available sources we have to work around the
MEMERASE ioctl - if used, it hangs and never returns. I straced the original
recovery executable and could see that it is simply calling write() with a
bunch of zeroes instead of using MEMERASE.
Added a hack that does the same and now the resulting TWRP recovery image works.
Change-Id: I1b1c1c9e870e350776346bdca5d442c7ef565aa0
A few signed/unsigned comparison warnings were all that stood in the way
of a clean clang build.
Change-Id: Id8c47fcfa500a6ac164bddb855831cdc17d99847
Author: Edwin Vane <edwin.vane@intel.com>
Reviewed-by: Tareq A Siraj <tareq.a.siraj@intel.com>
ECC errors are found by comparing the result of ioctl(ECCGETSTATS)
before and after the read. But if an error was found causing us to go
to the next block, we'd compare the stats before the *first* read to
the stats after the second (third, fourth, etc.) reads, so we'd read
to the end of the partition without ever succeeding. Fix logic so we
compare the values before and after each read independently.
Bug: 3162777
Change-Id: I5a13abd7243d2afd1d21bd98cbb233e5124b2e80
Close the update package before invoking the binary, to allow the
installer to unmount /cache if it wants to. Add a function to allow
remounting of a mount as read-only.
Change-Id: Idfcc96c3da66083295177f729263560be58034e4
hboot will apparently fail to install if the first block of the image
(the one pointed to by the offset in the block 0 header) is a bad
block. (Hopefully it handles subsequent bad blocks.)
This change makes the MTD write code keep track of the bad blocks it
has skipped over, so that the offset in the header can be adjusted to
be the address of the first successfully written block.
Change-Id: I45d58e32a36d0c1dbc0a7f871bd5985b6c8ff524
http://b/2358012 - passion: failure to flash hboot (bad blocks?)
With the recovery image being installed by applypatch, the flash_image
tool isn't needed any more. Continue to build it for eng just in case
it's handy for debugging.
We fail to detect certain bad blocks (marked in the factory as bad, I
think?) when reading mtd partitions. These come back as a block of
all zeros. Since it's fairly unlikely a legitimate boot or recovery
block will contain 128k of zeros, change mtdutils to skip over such
blocks.
Arve says https://review.source.android.com/10535 may be a long-term
fix for this, but he isn't yet sure.
