[ERLEDIGT/DISKUSSION] Shell Script im Deep Sleep

Da wir ja unseren eigenen daemon in den kernel einsetzen hat das mit dem Life Cycle der Activitys von Java nix zu tun Das sind zwei verschiedene Baustellen.

BTW. ich selber würd den Wecker-apk-mod auch vorziehen ( weniger Zeitaufwendig in der Umsetzung)

@Cynob Ich fand es sehr lustig. Das passiert nur, wenn einen der Kaffee fehlt. @K11 war eigentlich der Adressat, nicht du.

Der Androidcode, denn du kopiert hast, hat nichts mit den eigentlichen Problem zu tun (Da steht nur wie man ein Handy vibrieren lässt und den Medienplayer startet). Wenn du ihm erklären wolltest, dass er dort seine Code einfügen kann, der beim Auslösen des Alarms ausgelöst wird, dann fehlt etwas.

Die Anleitung für das Script fand ich sehr informativ. Nur das mit den Serivce hast du recht knapp erklärt.

Also so wie ich es verstanden habe wollte er nur den Vibrationsalarm mit längeren Intervallen ansteuern. Wenn er unbedingt sein Script ausführen muss fehlt da irgendwo was mit
Runtime.getRuntime().exec... Naja er meldet sich anscheinend ja nichtmehr

meinst du mit Service den daemon Eintrag in der init.rc? und wo ist was unklar? Ich für dir das gern noch weiter aus

Mir ist das soweit klar. Wenn er es nicht verstanden hat, soll er fragen. Und sonst können wir hier das Thema schließen.
(PS: Mir fehlt schon wieder ein Kaffee. Muss jetzt Schluss machen. )

Hallo,
doch ich melde mich schon, danke für eure Hilfe.

Also zu allen Antworten:
@markus.tullius du meinst sicher mich mit @Cynob und @K11 . Ich wollte auch nicht mehr Strom sparen als Android im Sparmodus kann, nur einfach in den Sparmodus können damit ich das Handy nicht immer eingeschaltet lassen muss wenn Scripte weiter laufen sollen. Und ich weiss, man sollte nicht einfach blind etwas am Handy machen wenn man nicht draus kommt, vorallem mit root nicht
[doublepost=1481395226,1481395199][/doublepost]ups...
[doublepost=1481398598][/doublepost]...
und ich muss mir das später einmal genauer anschauen wie man in Android Apps programmiert.

@Cynob hab ich mir schon gedacht mit /etc/passwd. Der Fehler unknown uid 0 brachte mich zu dieser Datei (weil cron in Android irgendwie darauf zugreifen soll).
Ja stimmt, das ist dann wieder genau das gleiche Problem, ich dachte zwar cron wird automatisch zum Service oder Daemon.
Und init.rc sollte wahrscheinlich automatisch diverse Sachen ausführen nach Start, und desshalb da cron eintragen meinst du oder? Ich glaube ich weiss was ich machen müsste, aber könnte ich auch einfach ans Ende von einer /init.???.sh Datei "sh /Pfad/zu/mein/Script" schreiben?
Und Backups sind nützlich ja, ich mach glaube ich wieder mal eins aus dem Recovery.
Danke für die ausführliche Anleitung zum init.rc


Und ich habe nachher über die Shell gelesen: Shell . Dorte steht mit der Shell sollte man eigentlich alle Funktionen vom System ausführen können. Das klingt nach genau der Sprache die ich will Und es steht auch dass man mit der Shell nur über adb oder über eine App (zb Terminal Emulator) interagieren kann. Das erklärt dann auch (so halb) dass es immer anhält wenn man den Display ausschaltet.
Danach habe ich es mit adb versucht und es funktioniert!!! Ich muss nur alle Scripts mit adb und "nohup sh /mein/Script" starten, danach kann ich das Kabel ausstecken und es funktioniert auch noch mit ausgeschaltetem Display.
Dazu hätte ich ein paar Fragen:

1. Geht so Android immer noch in den Sparmodus? Es ist nicht so das jetzt einfach das ganze System nie mehr richtig schläft oder?

2. Gibt es wirklich keine Möglichkeit auf meinem Handy so mit der Shell zu interagieren wie es adb tut? Oder müsste man dann gleich eine neue Funktion zu Android hinzufügen?

3. Wenn ich so ein Script mit sh starte sehe ich nacher keinen eindeutigen namen mehr für killall, und die PID verändert sich irgendwie nach einer Zeit. Weiss jemand vielleicht wie ich einem Prozess einen eigenen Namen geben kann, oder wie ich das Script dann wieder schliessen kann?

4. Wenn ich zu cron einen neuen cronjob hinzufüge muss ich danach crond wieder neustarten damit es diesen Job auch ausführt. Weis vielleicht gerade jemand wieso das ist? Es ist zwar nicht mehr so wichtig weil ich jetzt ja auch direkt ein Script ausführen kann.

5. Wie mache ich dass auf eine Datei nur root alle Rechte für die Datei hat? chmod +x geht nicht, es gibt keinen Fehler aus aber es wird nie geändert wenn ich mit ls -la schaue.

6. Wäre crond mit root ein Sicherheitsrisiko wenn jeder auf die Datei in der die Cronjobs stehen zugreifen kann? Oder ist es das sowieso? Bekommt eigentlich jeder gleich root Rechte wenn ich ein gerootetes Handy habe weil man kein Passwort eingeben muss oder ist das manuelle Bestätigen wirklich eine grosse Hürde?

Hallo ka

bevor wir ganz wirre werden : Meine Antworten beziehen sich auf ein Standard Android Image -
weder verbogen , noch getuned !
Desweiteren versuche ich mich bewusst einfach auszudrücken. (bevor meine Aussagen seziert werden)

Dorte steht mit der Shell sollte man eigentlich alle Funktionen vom System ausführen können.

Zum Vergrößern anklicken....

Negativ - nur auch das, was du als root/unroot zugelassen bekommst - auch als Shell befehl aus einer App heraus
Beispiel :

1. Geht so Android immer noch in den Sparmodus? Es ist nicht so das jetzt einfach das ganze System nie mehr richtig schläft oder?

Zum Vergrößern anklicken....

An der Stelle jetzt die kompletten Eigenschaften von Android zu erklären , würde natürlich den Rahmen sprengen.

Das System schläft nie, allerdings führt es im "Schlafmodus" in der Hauptsache Services aus.
Apps werden dann in den HIntergrund geschickt und erhalten ein "Pause-Trigger" - die Entwickler haben sich dann selbst drum zu kümmern,
dass alles gesichert wird und Processe resp. Threads beendet sind etc etc

Android kann/wird dann danach die App komplett beenden.

Wenn die App wieder durch den Nutzer/Powertaste in den Vordergund genommen wird, erhält diese vom System wieder ein "Resume-Trigger"
Erst ab dieser Stelle erwacht die App und der Entwickler kann alles wieder weiterführen.

Das gleiche passiert auch mit deinem Terminal

Nur Services laufen (unter Umständen) weiter - vielmals sind diese auch noch Alarm getriggert , weil diese auch
von Android beendet werden können.

Android verwaltet sich selbst , Du musst vom Gedanken wegkommen, es würde sich wie eine Linux/Windows büchse verhalten.
Frage 2 bis 6 sind also eher Linux spezifisch , nicht Android

Als Lösung gehst du dann eher den Weg eines eigenen Images oder du setzt dich mit der Programmierung (Service)auseinander.

chmod +x gilt für alle user. Hierbei werden keine Rechte entfernt. chmod – Wikipedia

Der Rest hängt vom Handy ab. Leider ist das Linux auf den Android Handys nachträglich an die Anforderungen eines Handys angepasst worden. Und die Hersteller passen ihr System noch mal zusätzlich an. Sprich es existieren nicht alle Linux - Befehle (Auf Custom Roms ist normalerweise mehr möglich.) Auch einer der Gründe warum es solche Probleme mit regelmäßigen Updates auf den Handys gibt.

Was funktioniert, hängt vom Handy und der installierten Programme ab. Shell

Den Ansatz über die adb bridge find ich lustig irgendwie
Die Idee ist gar nicht mal soo schlecht - wenn auch nicht gerade Anwenderfreundlich. man müsste mal schauen ob man die adbd auf dem Gerät nicht frisieren kann.

Auch kannst du mal deine build.prop durchlesen - dort könnte auch noch was geblockt sein.

>>> zu der init.rc: Es hat schon n Grund warum ich da so einen Aufriss drum gemacht hat. Das ist keine Scriptdatei welche von oben nach unten durchgearbeitet wird sondern eher ne Einstellungsdatei im weitesten Sinne.
Android gibt auch gewisse Regeln vor wie die Datei auszusehen hat.
Wenn du nur dein sh bla ans Ende dranhängst landest du ziemlich warscheinlich innem Bootloop.

Anstelle das jetzt alles zu erklären zeig ich dir n Bild

The Android Booting process | NXP Community

So mit dem Eintrag in der Init.rc klemmen wir uns bei Punkt 3/4 in das System und bringen das crond als Daemon bis zu Punkt 5

Das ganze Geraffel mit den Lifecycles von der Android Software wird von Zygote verwaltet welches wir somit umgehen.
Ich find auf der Seite ist der Startprozess ganz gut erklärt find ich - wenn man sich dann noch n bisl was über Zygote,Dalvik und System Server durchliest kann man sich für den Anfang n ganz gutes Bild machen wie Android funktioniert.

So jetzt mal noch zu deinen Fragen:
zu 1: Ich könnt jetzt ausholen aber kurz und bündig: Pfeiff mal auf das Strom sparen. Was Strom braucht: Display und jegliche Datenverbindung nach aussen ( Wlan, GSM, BT) - der Prozessor in deinem Gerät läuft wenn er schläft ja immer noch auf sagen wir mal 700Mhz - der lacht sich über dein Script immer noch schlapp (das du was zum vergleichen hast: ein 8Mhz Arduino würde auch noch gähnen)! Das heißt er läuft eh und ob er jetzt dein Code mit durchackert merkt der nichtmal wirklich. Dann gibts da so Dinge wie interrupts ( ich denk cron arbeitet damit oder wie implementieren die das? )...das würde jetzt aber zu weit gehn

zu 2: Gehen tut das bestimmt - die Frage ist nur wie sinnvoll es ist.

zu 3: Dein Terminal spawnt ja auch das sh - Das läuft als Teil vom Terminal Emulator - du müsstest diesen abschiessen. Oder du baust dir irgendwie was damit du mit deinem Script interagieren kannst.

zu 4: weil cron nur beim starten die Einstellungen einliest.

zu 5: Rechte › Wiki › ubuntuusers.de und um Dateieigenschaften zu ändern muss die Partition auf welcher die Datei liegt rw gemountet sein

zu 6: root macht so ein phone prinzipiell auf wie ein Scheunentor - ganz einfach ist es nicht aber man kann mit genug Wissen schon einiges anstellen. Wobei da immer noch der Benutzer der größte Faktor ist ( er müsste die Schadsoftware erstmal installieren z.B.)

So das war jetzt mal mein Senf dazu
Guten Morgen

@Cynob
init.rc wird von oben bis unten durchgearbeitet. Der Kernel hat erst nach dem Bootvorgang Zugriff auf die Systempartition. In der Datei steht, welche Kerndienste gestartet werden sollen. Und ist mit Abstand die interessanteste Datei. Es ist keine Einstellungsdatei.

@ka111, @swa00
Zygote, Dalvik bzw ART sind nicht mehr Teil von Linux. Hier sind Java-Kenntnisse gefragt. Ich versuche es mal hier aufzuschlüsseln.
Zygote ist ein Daemon, welcher die erste Java-Laufzeitumgebung startet. Als erste Methode wird in der VM die Methode Zygnote.main() aufgerufen. Von hier aus wird der ganze Java-Foobar gestartet. D.h die einzige Aufgabe von Zygote ist das Starten der (Java) Apps.

Die Methode, die den System Server startet, wird direkt in der main() von Zygnote aufgerufen. Sie heißt Zygnote.startSystemServer(), und sie startet die System Apps. Hier werden auch die Service gestartet, die @swa00 erwähnt hat.

Java Programme laufen in einer VM. Davlik und ART sind solche virtuelle Ausführungsumgebungen für Android.

@ka111
zu 3) Da solltest du sehr vorsichtig vorgehen, weil zygnote da fleißig mit mischt. Die VM der Apps laufen in eigenen Prozessen.
Jeder Prozess hat seine eigne pid. Beenden tut man den Prozess mit kill -9 <pid>. Die PID muss du mit grep suchen.

Ja klar nur werden ja z.B. Dienste samt start Attributen ja z.b. wie eine funktion eingelesen und von woanders aus gestartet - da kann man nicht einfach so am Ende was ranhängen.
Zu meiner Verteidigung mit der Einstellungsdatei > die rc Dateien beschreiben ja nur den Aufbau und was wann wo gestartet wird ( die wird ja nur interpretiert und berrechnet von selber ja nix - das meinte ich damit)

@swa00
Ja ich gehe auch immer von einem Standard Android aus, ausser es ist offensichtlich.

Hmm... Könnte man dann einen User machen der alles zugelassen bekommt und überall alle Rechte hat? Ich dachte root hat alle Rechte überall..

Ach so, dann ist gut mit dem Schlafmodus. Da müsste ich mich auch mal genauer damit befassen..

Ja irgendwie ist Android schon ganz anders als Linux, Windows ... .


@markus.tullius
Ach ja, das habe ich auch noch übersehen dass chmod +x nicht nur für root gilt. Aber es funktioniert irgendwie nicht damit Ausführrechte zu bekommen, es wird einfach nie etwas geändert. (Auch mit / als rw nicht)
Vielleicht ist da ja etwas nicht richtig angepasst. Sh script funktioniert ja noch.


@Cynob
Ach so, dann versuche ich es irgendwann mal besser so wie du es geschrieben hast mit der init.rc.
Ja die Seite mit dem Bild erklärt es ziemlich gut, danke.

1. Ja das stimmt eigentlich auch mit dem Prozessor der immer einen minimum Takt hat. Ich habe mal geschaut wegen der CPU Last mit einer App, und das einzige was ich merke ist das Live Hintergrundbild, wenn ich sonnst nichts mache.

2. Für mich wäre es nützlich mit der Shell so zu interagieren wie es adb tut und nicht über eine App.

3. Ja stimmt, das habe ich vergessen. Ich musste nur eine beenden Funktion einbauen die wieder aus allen while Schleifen kommt.

4. Ach so, ok

5. Also wenn ich nach "mount -o remount,rw /" versuche ein Script mit "chmod +x" ausführbar zu machen, sehe ich mit "ls -la" nachher nur -rw-rw---- und kann es nicht mit ./script ausführen.
Aber sh script geht ja noch.

6. Ok, habe ich mir auch irgendwie gedacht.
Ja aber vielleicht merkt man es gar nicht direkt wenn beim surfen etwas im Hintergrund kurz aufgeht oder so.


@ wieder markus.tullius
Aha, ok. Danke für die Erklärung mit der Zygote und so.

3. Wenn ich Prozesse abschiesse passiert nichts schlimmes wenn ich wieder neustarte, oder? (Notfalls mit Tastenkombination Power lauter bei mir). Ausser wenn ich etwas wie zB Überhitzunsschutz abschiesse.



Also ich habe mich ein bisschen über abd informiert.
So wie es geheissen hatte sollte doch das Einte (auf dem Pc normalerweise) über einen ~Port mit dem Anderen (auf dem Handy normalerweise) kommunizieren. Und beide sollten automatisch die passenden Ports ~belauschen.

Die App GNURoot Debian habe ich sowieso auf dem Handy. Die macht irgendwie eine ~Debian-Umgebung. Dort konnte ich adb installieren, aber es findet mit "adb devices" kein Gerät. Ob die Umgebung sich irgendwie abkapselt vom Rest vom System weiss ich nicht.

Könnte man so nicht etwas machen damit ich adb Kommandos auf dem Handy ausführen kann?

Manchmal verrennt man sich in eine mögliche Umsetzung und sieht dann den Wald vor lauter Bäumen nicht.... Will heißen, man versucht mit den falschen Werkzeugen etwas zu basteln, was hierfür einfach nicht ausgelegt wurde. Ausgehend von deiner Anforderung eine Aktion zeitgesteuert zu starten (Wecker mit langem VibrationsIntervall) ist die korrekte Umsetzung ganz einfach. Du benötigst keine Shell, kein Script, keinen Service, kein Root sondern nur den Alarmmanager (.set oder .setExact je nach API level),einen PendingIntent und einen dazugehörigen BroadcastReceiver. Bin immer offen für alternative Lösungsansätze, aber in deinem Fall wirst du, wenn du eine stabile und performante Lösunge implementieren möchtest nicht um eine simple App herumkommen. Mit etwas Ahnung in der Androidentwicklung, sollte das in 1-2 Stunden erledigt sein.

Das Thema hatten wir schon weiter oben geklärt. Und den gleichen Ratschlag hat er auch schon bekommen (#10 und folgende).
Außerdem geht es auch ohne PendingIntent.
Ich glaube auch nicht, dass es in 1-2 Stunden erledigt ist, wenn man vorher Java und dann noch Android lernen muss.

Und manchmal möchte man einfach nur sehen, ob etwas funktioniert. Ich fand das Thema sehr interessant, und denke, dass es eine sehr stabile Lösung ist.

@safa : Wie markus.tullius schon schrieb wollen wir ja nicht den effizientesten Weg nehmen sondern mit dem "Linux" Teil des Betriebsystems rumspielen.

@ka111 Ich habe gerade das hier gefunden: die adb und fastboot kompilliert für android Das Problem wie vorher - der Aufruf erfolgt über ein Terminal welches ja wieder mit dem Java Zeugs zu tun hat.... doof...[Guide] Use your tablet/phone as PC for Fastboot and ADB

Um das jetzt weiterzutreiben: Man könnte doch sowas wie einen Service schreiben welcher mit dem System startet und Skripte im "hintergrund" laufen lässt. Mit bash oder C müsste man da doch was hinbekommen?!?

Gruß Cynob

Ich hatte am Schluss einfach ein Shell Script erstellt das immer wieder prüft ob es ein Script ausführen soll, und es mit adb und nohup gestartet. Das ist doch etwa so wie du meinst cynob?
Ich habe es danach nicht mehr so richtig weiter verfolgt...