Integrieren Sie beim Kompilieren des Android-Systems eine benutzerdefinierte Wiederherstellung

Mobile 2023-12-17 00:20:48 views: null

RecoveryDer -Modus ist ein spezieller Modus des Android-Systems, der es dem Benutzer ermöglicht, einige Vorgänge auszuführen, die im normalen Modus nicht ausgeführt werden können, wie zum Beispiel:

  • System Android installieren oder aktualisieren
  • zurücksetzen
  • Cache leeren
  • SD-Karte formatieren
  • Flash-ROMs von Drittanbietern

RecoveryDer -Modus besteht aus einem Kernel mit RAM Festplatten auf einem anderen System als dem Hauptsystem Auf der Partition. LinuxAndroid

Wenn Sie weitere Funktionen wünschen, wie etwa das Flashen von Drittanbietern ROM, können Sie Drittanbieter flashen Recovery. Drittanbieter Recovery verfügen normalerweise über mehr Funktionen als native Recovery, können aber auch instabil sein.

Vorwort

Nachdem wir die Kompilierung des Drittanbietersystems abgeschlossen haben, müssen wir häufig einen Drittanbieter verwenden Recovery, um das System zu flashen.

Gleichzeitig müssen wir, da die integrierten Recovery Funktionen der meisten Systeme relativ einfach sind, oft auf Drittanbieter Recovery zurückgreifen unsere Geräte. , um den nächsten Flash des neuen Systems zu erleichtern.

Gibt es also eine Möglichkeit, Dritte Recovery direkt in unser kompiliertes System zu integrieren?

Nachdem ich viele Online-Informationen konsultiert hatte, stellte ich fest, dass die TWRP alte Version eine Zeit lang existierte und zusammen mit der Omini System und direkt in das System integriert. Aber für die aktuellen neuen Systeme und neuen Geräte scheint dies nicht machbar zu sein, da ich die ursprüngliche Methode nicht verwenden kann, um es beim Kompilieren direkt in mein System-Image und Flash-Paket zu integrieren.

Gleichzeitig habe ich versucht, die Zusammenstellung und Verwendung von TWRPs BrüdernOrangeFox zu studieren. Zuerst verwies ich auf die offizielle Dokumentation Building OrangeFox hat eine Kopie kompiliertRecovery und temporäres Startup< verwendet a i=7> und In das Flash-Paket einpinseln und verfestigenEs werden zwei Methoden verwendetOrangeFox Recovery.

Nachdem ich das Verfestigungsskript von OrangeFox Recovery studiert und mit dem Kompilierungs- und Verpackungsprozess von Android kombiniert hatte, fand ich einen neuen Weg, die Funktion zum Anpassen des Flash-Pakets zu implementieren Recovery.

Umsetzungsideen

Beim Android Systemkompilierungsprozess wird normalerweise jeder Teil des Systems zuerst in Images kompiliert. Anschließend werden diese Images zusammengestellt und in ein vollständiges Flash-Paket gepackt. Unser Recovery ist normalerweise eine separate Partition oder in die Boot-Partition integriert, sodass wir nur diesen Teil ersetzen müssen.

Dieser Abschnitt implementiert nur die Anpassung von Recovery während der Systemkompilierung in der Boot-Partition.

Aber normalerweiseBoot.img enthält nicht nur Recovery, sondern auch einige andere Inhalte, die für den Systemstart und -start verwendet werden, daher müssen wir die Paketänderung beheben .

auspacken, einpacken

Zuerst müssen wir das Verfestigungsskript von OrangeFox Recovery überprüfen, wobei unser entsprechendes ist und der heilende Teil des Codes lautet wie folgt: Bild, das verwendete Entpack- und Verpackungstool ist Recoveryrecovery.imgRecoveryMagiskBoot

# a/META-INF/com/google/android/update-binary
magiskboot unpack -n recovery.img

# deal with ramdisk cpio
if [ ! -f "ramdisk.cpio" ]; then
    abort "- Error extracting the OrangeFox ramdisk. Quitting!"
fi
cp -f ramdisk.cpio ramdisk-ofrp.cpio
rm -f ramdisk.cpio
rm -f kernel dtb kernel_dtb

# deal with both slots
for slot in _a _b; do
    ui_print "- Running boot image patcher on slot $name$slot..."

    # dump the partition and unpack
    dd bs=1048576 if=$target$slot of=boot.img
    magiskboot unpack -h -n boot.img

    # 其他步骤

    cp -f ramdisk-ofrp.cpio ramdisk.cpio
    magiskboot repack -n boot.img

    blockdev --setrw $target$slot
    cat new-boot.img /dev/zero > $target$slot 2>/dev/null || true
    rm -f boot.img dtb kernel new-boot.img ramdisk.cpio header
    magiskboot cleanup
done

Anhand dieses Codes können wir sehen, dass der Verfestigungsprozess von OrangeFox Recovery wie folgt aussieht:

    1. Verwenden Sie MagiskBoot Allgemeine dritte Seite Recovery Auspacken, halten Sie einfach ramdisk.cpio Satz;
    1. Abruf der Systemübermittlung boot.img;
    1. Entpacken Sie das extrahierte boot.img;
    1. Verwenden Sie einen DrittanbieterRecovery, um die ramdisk.cpio-Datei zu entpacken und zu extrahieren und die boot.img entpackte zu ersetzen < a i=4> Datei;ramdisk.cpio
    1. Neu verpackenboot.img Spiegeln;
    1. Zurück zur ursprünglichen Partition schreiben

Spezifische Operationen

Verpackungsprozess ändern

Wenn die Analogie des Verfestigungsschritts zu unserem Systemkompilierungsprozess hinzugefügt wird und der Ersatz im vorherigen Schritt des Zusammenstellens der kompilierten Bilder zum Zusammenstellen des Flash-Pakets implementiert wird, kann eine Anpassung erreicht werden < eine i=1> Funktion. Recovery

Durch einen Blick auf den LineageOS-Quellcode habe ich schließlich einen Teil des Codes in LineageOS gefunden, der das Bild zum Flash-Paket hinzufügt, Datei:boot.img Der relevante Code befindet sich in der build/make/tools/releasetools/add_img_to_target_files.py

boot_image = None
if has_boot:
    banner("boot")
    boot_images = OPTIONS.info_dict.get("boot_images")
    if boot_images is None:
        boot_images = "boot.img"
    for index, b in enumerate(boot_images.split()):
        boot_image = common.GetBootableImage("IMAGES/" + b, b, OPTIONS.input_tmp, "BOOT")
        if boot_image:
            boot_image_path = os.path.join(OPTIONS.input_tmp, "IMAGES", b)
        if index == 0:
            partitions['boot'] = boot_image_path
        if not os.path.exists(boot_image_path):
            boot_image.WriteToDir(OPTIONS.input_tmp)
            if output_zip:
                boot_image.AddToZip(output_zip)

Sie können sehen, dass es in diesem Absatz darum geht, boot.img in das Flash-Paket zu packen. Tatsächlich ähnelt es in gewisser Weise dem Heilungsskript von OrangeFox Recovery . wird die beiden Partitionen a und b durchqueren und verwandte Operationen ausführen, also imitieren wir den Verfestigungsprozess von OrangeFox Recovery und schreiben Folgendes Funktion, wobei die Eingabe Der Parameter ist der Pfad von boot.img, der Code lautet wie folgt: 

def useCustomRecovery(boot_image_path):
    magiskboot = os.getenv('CUSTOM_MAGISKBOOT')
    recovery = os.getenv('CUSTOM_TWRP')
    if not magiskboot or not recovery: return
    origin_pwd = os.getcwd()
    new_pwd = os.path.join(os.getcwd(), "tmp")
    common.RunAndCheckOutput(["mkdir", "-p", new_pwd])
    os.chdir(new_pwd)
    common.RunAndCheckOutput([magiskboot, "unpack", "-n", recovery])
    if not os.path.exists("ramdisk.cpio"):
        common.RunAndCheckOutput(["rm", "-rf", new_pwd])
        os.chdir(origin_pwd)
        return
    common.RunAndCheckOutput(["cp", "-f", "ramdisk.cpio", "ramdisk-ofrp.cpio"])
    common.RunAndCheckOutput(["rm", "-f", "ramdisk.cpio"])
    common.RunAndCheckOutput(["rm", "-f", "kernel", "dtb", "kernel_dtb"])
    common.RunAndCheckOutput([magiskboot, "unpack", "-h", "-n", boot_image_path])
    common.RunAndCheckOutput(["cp", "-f", "ramdisk-ofrp.cpio", "ramdisk.cpio"])
    common.RunAndCheckOutput([magiskboot, "repack", "-n", boot_image_path])
    common.RunAndCheckOutput(["mv", "-f", "new-boot.img", boot_image_path])
    common.RunAndCheckOutput(["rm", "-rf", new_pwd])
    common.RunAndCheckOutput([magiskboot, "cleanup"])
    os.chdir(origin_pwd)

Dieser Teil ist derselbe wie der Verfestigungsvorgang von OrangeFox Recovery, bei dem es sich um Auspack-, Ersetzungs- und Neupackvorgänge handelt. Mit dieser Funktion ändern wir direkt den ursprünglichen Quellcode:

boot_image = None
if has_boot:
    banner("boot")
    boot_images = OPTIONS.info_dict.get("boot_images")
    if boot_images is None:
        boot_images = "boot.img"
    for index, b in enumerate(boot_images.split()):
        boot_image = common.GetBootableImage("IMAGES/" + b, b, OPTIONS.input_tmp, "BOOT")
        if boot_image:
            boot_image_path = os.path.join(OPTIONS.input_tmp, "IMAGES", b)
            if index == 0:
                partitions['boot'] = boot_image_path
            if not os.path.exists(boot_image_path):
                boot_image.WriteToDir(OPTIONS.input_tmp)
                if output_zip:
                    boot_image.AddToZip(output_zip)
        useCustomRecovery(boot_image_path)

Vergessen Sie nicht, die Funktion gerade zu dieser Datei hinzuzufügen. Gleichzeitig müssen wir beachten, dass wir in der Funktion useCustomRecovery zwei Umgebungsvariablen lesen müssen:< /span>

  • CUSTOM_MAGISKBOOT: Absoluter Pfad zum MagiskBootTool zum Entpacken;
  • CUSTOM_TWRP: Der Dritte, den wir einbinden müssenRecovery

Umgebungsvariablen öffnen

Mit den folgenden Befehlen können wir Umgebungsvariablen festlegen:

export CUSTOM_MAGISKBOOT=<指向您使用的 MagiskBoot 工具的绝对路径>
export CUSTOM_TWRP=<指向您需要替换的 Recovery 镜像的绝对路径>

Nachdem die Einstellungen abgeschlossen hatte, kompilierten wir das System neu und stellten fest, dass es immer noch nicht in das System gepackt war. Dies liegt daran, dass das Lesen von Umgebungsvariablen während des Kompilierungsprozesses eingeschränkt ist. Nur bestimmte Umgebungsvariablen werden an den Kompilierungsprozess übergeben, daher müssen wir auch unsere eigenen CUSTOM_MAGISKBOOT und < hinzufügen a i=2> wird zur Whitelist hinzugefügt. CUSTOM_TWRP

Der entsprechende Dateispeicherort, der geändert werden muss, befindet sich unter dem Pfad build/soong/ui/build/ninja.go. Der geänderte Code lautet wie folgt:

func runNinjaForBuild(ctx Context, config Config) {
    // 其它代码
	if cmd.Environment.IsEnvTrue("ALLOW_NINJA_ENV") {
		ctx.Println("Allowing all environment variables during ninja; incremental builds may be unsafe.")
	} else {
		cmd.Environment.Allow(append([]string{
			/*
                其它参数
            */
			"PYTHONDONTWRITEBYTECODE",
			"TMPDIR",
			"USER",

			// Custom TWRP
			"CUSTOM_MAGISKBOOT",
			"CUSTOM_TWRP",

			// TODO: remove these carefully
			// Options for the address sanitizer.
			"ASAN_OPTIONS",
			/*
                其它参数
            */
		}, config.BuildBrokenNinjaUsesEnvVars()...)...)
	}
    // 其它代码
}

Wir müssen nur CUSTOM_MAGISKBOOT und CUSTOM_TWRP zur Whitelist hinzufügen und dann die Kompilierung neu starten. Mit anderen Worten, Sie Der Kompilierungsprozess ist jetzt: 

source build/envsetup.sh
export CUSTOM_MAGISKBOOT="<指向您使用的 MagiskBoot 工具的绝对路径>"
export CUSTOM_TWRP="<指向您需要替换的 Recovery 镜像的绝对路径>"
lunch lineage_[设备代号]-userdebug
croot
mka bacon

Git-Patch

Gleichzeitig habe ich einen praktischen Git Patch zur einfachen Änderung erstellt. Sie können DogDayAndroid/Android-Builder< eingeben a i =3> Schauen Sie sich meinen Patch an.

Verweise

Haben Sie nach dem Studium dieses Artikels etwas gewonnen? Das Lernen hat kein Ende und Lernen ist wie Segeln gegen den Strom. Wenn Sie nicht vorankommen, werden Sie zurückfallen. Zusätzlich zu den oben genannten Inhalten wurden in diesem Artikel auch viele relevante Informationen zu fortgeschrittenen Android-Übungen zusammengestellt wird Ihnen, die hart arbeiten, kostenlos zur Verfügung gestellt. Ich hoffe, es kann Ihnen helfen!

Scannen Sie den Code, um ihn zu erhalten! Wesentliche fortgeschrittene Materialien für die Android-Entwicklung

Fügen Sie hier eine Bildbeschreibung ein

Supongo que te gusta

Origin blog.csdn.net/m0_56255097/article/details/134507398
Recomendado
Clasificación
Diario
Más
2024-06-02(0)
2024-06-01(2)
2024-05-31(0)
2024-05-30(0)
2024-05-29(1)
2024-05-28(0)
2024-05-27(1)
2024-05-26(1)
2024-05-25(0)
2024-05-24(13)

Code World

© 2018 codetd.com