Wie überprüfe ich, ob das Skript ausgeführt wird, nachdem das Gerät gestartet wurde?

Ich habe ein Skript, das ich einmal ausführen muss, und zwar nur, wenn das Telefon hochgefahren ist.

Ich habe es mit init.qcom.post_boot.sh, init.sec.boot.sh, debuggerd und schließlich mkshrc versucht

Während mein Skript mit Debuggerd ausgeführt wurde, stellte ich fest, dass es jedes Mal ausgeführt wurde, wenn Debuggerd ausgeführt wurde, was nicht etwas ist, was ich tun muss ... also, als ich darauf stieß /system/etc/mkshrc(die anderen 2 funktionierten einfach nicht)

Was ich gefunden habe, war, dass das Skript einmal beim Booten ausgeführt wird ... es scheint jedoch auch jedes Mal ausgeführt zu werden adb shell, wenn es ausgeführt wird, zusammen mit (ich nehme an) jedes Mal, wenn die Shell gestartet wird ... was auch unerwünscht ist.

Was kann ich also tun, /system/etc/mkshrcum sicherzustellen, dass mein Aufruf meines Skripts nur einmal ausgeführt wird ... beim Booten?

Ich dachte darüber nach, eine whileSchleife auszuführen, um nach dem zu suchen , getprop sys.boot_completedwenn es ==1 dann eine Datei irgendwo ausgibt, und durch eine ifAnweisung innerhalb der Schleife, um nach dieser Datei zu suchen, wenn sie existiert, dann zu beenden, wenn nicht, dann den nächsten Befehl auszuführen ... jedoch überall Ich darf diese Datei ausgeben, sie bleibt zwischen den Startvorgängen bestehen, sodass sie next commandnie wieder ausgeführt wird.

HINWEIS Benötigt weder root, noch benötigt mein Skript root, um ausgeführt zu werden (ja, ich habe es bestätigt)

CODE

BB=/system/xbin/busybox
MYPID=/mnt/sdcard/.kev-run

while [ `getprop init.svc.bootanim` == "stopped" ] ; do 
    # if the run file does not exist, and we are stopped
    if [ ! -e $MYPID ]; then
        # run the scripts, then create the run file
        LOG=/mnt/sdcard/Download/kevs-scripts.log
        $BB rm -f $LOG;
        $BB echo "Launching Kevs Scripts" >> $LOG;
        MY_SCRIPT
        # write the run file so we aren't running this everytime this file runs
        touch $MYPID;
        sleep 1;
    fi
done

# if we are still booting, delete the run file
while [ `getprop init.svc.bootanim` != "stopped" ] ; do
    # we're not done booting, remove our makeshift pid file and sleep a second
    $BB rm -f $MYPID;
    sleep 1;
done

Scheint mir abzugehen

Antworten (1)

mkshrcwird per Definition jedes Mal ausgeführt, wenn eine interaktive Shell gestartet wird, also ist es der falsche Ort.

Sie sollten Ihr Skript stattdessen wirklich mit dem Init-System von Android verbinden. (Entschuldigung, ich kann keine Details dazu geben; ich kenne das Android-Ökosystem nicht gut, ich bin nur der mkshEntwickler von .)

Das Schreiben in eine Datei tmpfs(damit sie beim Ausschalten automatisch entfernt wird) ist normalerweise ein guter Ansatz, damit ein Skript nur einmal ausgeführt wird. Ich wäre jedoch überrascht, wenn das Init-System von Android keine solche Möglichkeit bieten würde; Es ist das ideale Werkzeug für Ihre Arbeit.

ja, das ist mir aufgefallen. Ich schließe mich debuggerdwieder an und verwende setpropjetzt, um ein nicht dauerhaftes "Flag" zu setzen
Ich wünschte, ich könnte mich in init einklinken. oder sogar einen Kernel dafür kompilieren (was viel viel besser wäre), aber leider ... es ist ein Verizon mit einem gesperrten Bootloader, also bin ich eingeschränkt, LOL
Nun, das gibt es , aber die akzeptierte Antwort funktioniert nicht auf allen Telefonen, da die /system/etc/init.d/Unterstützung eine CM (IIRC?)-Ergänzung ist. Patchen scheint die init.rcallgemein richtige Lösung zu sein . Im Allgemeinen service …\n\tdisabled\n\toneshot scheint zu funktionieren ; nicht vergessen chmod +xund vorher auf die richtige Partition kopieren.
Ich wünschte, ich könnte. auf einem G935V, und der Bootloader ist gesperrt, also ist root das einzige, was wir wirklich haben. Am Ende habe ich Debuggerd als meinen "Zündungs" -Mechanismus verwendet und ein "Flag" über gesetzt, setpropaber was ich jetzt finde, ist, sobald rootes entfernt wird, setpropfunktioniert es nicht mehr. Mein Ziel ist es, einige Optimierungen zum Laufen zu bringen, ohne rooten zu müssen. Ich habe bestätigt, dass einige tatsächlich funktionieren, während andere nicht (was erwartet wird), aber der Trick besteht darin, sie dazu zu bringen, beim Booten abzufeuern ... einmal :)
Ich habe vergessen zu erwähnen, dass ich mein Gerät nach Belieben rooten/unrooten kann. Rooted, alles funktioniert einwandfrei. Unrooted, debuggerdwirft eine verweigerte Berechtigung, also denke ich, was ich tun muss, ist, den richtigen Besitz, die Separität und den Kontext dafür herauszufinden, um die Berechtigungen richtig zu machen ... fast da, LOL