Aosp Recovery Rom Flasher V4 Download !!INSTALL!!
Lina Gullace
trying to flash my DragonBoard845c - RB3 QC Robotics Dev kit with AOSP Android-12 T and simply can not get it to work - I started here Using Reference Boards Android Open Source Project - I built my images no worries then "Installing local images Boot db845c into fastboot mode (see DragonBoard Recovery). Run following command: ./device/linaro/dragonboard/installer/db845c/flash-all-aosp.sh - when I run this script it fails when trying to flash vendor_boot.img. I can not find vendor_boot.img anywhere and can find no instructions to build it - where can I get this file? after this error the board is soft-bricked and I must put it into EDL mode and run ./device/linaro/dragonboard/installer/db845c/recovery.sh - to be able to get back to fastboot mode. I have tried going to AOSP/db845c - Linaro Wiki and trying Flash downloaded AOSP images by running following commands, while booted in fastboot mode: 1 fastboot flash userdata userdata.img 2 fastboot flash super super.img 3 fastboot flash boot boot.img - but this simply bricks it again. Can some one please help me to flash this board with Android 12 T? (edited)
Run following command: ./device/linaro/dragonboard/installer/db845c/flash-all-aosp.sh - when I run this script it fails when trying to flash vendor_boot.img. I can not find vendor_boot.img anywhere and can find no instructions to build it - where can I get this file?
when I run the flash-all-aosp.sh script is says it works and it is Rebooting - but it doesnt. It ends up with the blue led and the green led lit and steady with no fastboot device or edl mode. When I try to reboot it it goes directly to this state again. I am forced to put it into edl mode and run the recovery.sh script to get back to fastboot
Hey all, this is the third phone iv installed lineage on now. I just got a Pixel 6 and out of the box wanted to install lineage. I have followed all the instructions, unlocked the bootloader and downloaded and verified the custom recovery image files that i downloaded.
fastboot works to affect the device, so I should be able to get root by flashing a recovery-boot image that lets me modify the system. That's my goal. But ClockworkMod's recovery images are hosted on download2.clockworkmod.com and TWRP's on techerrata.com and neither has a valid TLS certificate, nor is PGP-signed, nor even has a SHA hash shown anywhere. I want to prevent any MITM from getting root access to my tablet.
There's a ROM Manager app on Google Play to install these images using a GUI, but I haven't found any evidence it does anything different than downloading those same recovery images over unauthenticated HTTP. If ROM Manager were in the F-Droid app store that'd be a modest sign of trustworthiness, but it isn't.
I think the least risky thing might be to build AOSP recovery (fewer non-security-conscious middlemen than the modded versions), from "source", downloaded via HTTPS, in a fresh VM. Except: unmodified AOSP recovery images don't grant root, and I haven't yet found out if there's a simple way to modify the source so that they would.
Replacing the OS with AOSP or CyanogenMod is fine if necessary and trustworthy, but as far as I can tell, I can't do that without first flashing a recovery image and/or getting root on the stock Google Android. Chicken and egg problem.
Due to changes in Android 4.3 the Superuser app on F-Droid won't work. They haven't published the working version because of a silly reboot binary blob: Since you have no real reason to trust f-droid.org either and since it is relatively simple, you may as well build the su/app yourself via the SDK/NDK or AOSP setup, following the recipe for the previous versions (see gitorious.org/f-droid) with the additional removal of the reboot binary beforehand (it should be as simple as that). Install via adb in recovery.
If you want to keep the current ROM the above path is best, though Google Play (now using https I think) could be used to download the Superuser app (which contains su). If you'd prefer to place your trust in another ROM, then it could be possible to create fastboot compatible images from a downloaded zip. I don't know of another way of rooting than going via recovery.
And now I flashed TWRP to the recovery partition, rebooted directly into recovery - resulting in getting into the flashed TWRP, then rebooted again into recovery - resulting in getting into the flashed TWRP, so success - TWRP is now the recovery, the procedure should work.
When running recovery image from debuggable builds (i.e. -eng or -userdebug build variants, or ro.debuggable=1 in /prop.default), adbd service is enabled and started by default, which allows adb communication. A device should be listed under adb devices, either in recovery or sideload state.
Although /system/bin/adbd is built from the same code base as the one in the normal boot, only a subset of adb commands are meaningful under recovery, such as adb root, adb shell, adb push, adb pull etc. Since Android Q, adb shell no longer requires manually mounting /system from recovery menu.
By default, adbd is always included into recovery image, as /system/bin/adbd. init starts adbd service automatically only in debuggable builds. This behavior is controlled by the recovery specific /init.rc, whose source code is at bootable/recovery/etc/init.rc.
bootable/recovery/etc/init.rc disables Android USB gadget (via sysfs) as part of the fs action trigger, and will only re-enable it in debuggable builds (the on property rule will always run after on fs).
The recovery image supports localization of several background texts, e.g. installing, error, factory reset warnings, etc. For devices using xxhdpi and xxxhdpi, the build system generates these localization images dynamically since android-10 when building the recovery image. While the static images under res-*dpi/images/ is used for other display resolutions and as a backup.
To fully grasp the role the Android boot and recovery images play, we first need to understand the general boot-up process of an Android phone. While embedded software is no longer part of my day-to-day work at TextNow, I used to wear the embedded-engineer hat in one of my previous jobs and I dabble with embedded electronics in my spare time, so I am intimately familiar with modern microprocessor boot-up routines. I must caution you that this is a very technical post, but one that is hopefully useful to somebody looking for a reference material on how this all fits together, with links to where to delve more in-depth if required. This type of post would have been very useful when I was learning it :)
Technically speaking, there are no structuraldifferences between boot and recovery images. The only difference is whichkernel and which initial ramdisk is loaded, but they are packaged the same. Wewill come back to how these are packaged to make a neat and tidy boot image.
So, since we have custom recovery and boot imagesfor our Android phones (such as TWRP, CWM, etc.), obviously, someone had tocreate their own recovery image or modify an already existing boot image. Mostof the work was done using the already open-sourced Google Android code, butthere only was code there to create a boot image from its components. There wasno tool to unpack a boot image for modification. Now, you can use a tool like topack and unpack boot images and change out the kernel, or modify the initialramdisk.
If you are going to dirty flash from OOS12 based build, you need to update your firmware first. Wishmasterflo has made a firmware flasher that checks the RAM type for you and flashes the firmware to both slots. You can download the firmwares from here:
Recovery is the bootable portion of the phone's system that allows data wipes and system updates. At its core, the stock recovery is fairly limited in the functions they can perform. This is where custom recoveries come in to play.
Most root methods will lead you to installing ClockWorkMod (CWM) recovery. CWM is easily the most popular recovery out there, but the version that comes with most root methods is dated, still utilizing the volume and power buttons for navigation.
df19127ead