Wie starte ich einen bestimmten Service einer App?

[Foh]

Hi,

ich möchte über mein Task-Automationstool (E-Robot) einen bestimmten Service einer bestimmten App starten.
Dazu muss ich die Parameter des Service in das Automationstool eintragen.
Wie finde ich nun diese Parameter heraus? Und was muss ich wo eintragen? (s.Screenshot)
Als Beispiel können wir gerne den GCMService der Google Dienste nehmen ...

 

[swa00]

ich möchte über mein Task-Automationstool (E-Robot) einen bestimmten Service einer bestimmten App starten.
...... Wie finde ich nun diese Parameter heraus?

Ob der App-Entwickler überhaupt die Möglichkeit eingebaut hat, explizit seinen Service mit einem Intent zu starten,
kann nur der Entwickler selbst beantworten. Es ist Bestandteil des Source -Codes der Main-App.

Normalerweise wird dies auch nicht umgesetzt - würde auch keinen Sinn machen, denn irgendwo müssen ja die Meldungen initiiert/ausgewertet/angezeigt/verarbeitet werden und das macht/kann seltenst ein Service-Part alleine.
(ausser z.b DB - Logging oder der ContentResolver)

 

[Foh]

OK, verstehe ich nicht.
Z.B. der GCM Service wird durch bestimmte Aktionen eingeschaltet. Z.B. bei einer Änderung des Netzwerkstatus, oder wenn eine App startet die diesen Service nutzt.
D.h. der Service ist von extern ansprechbar und er reagiert.
Die App muss also bestimmte receiver haben auf die sie anspricht.
Also muss es doch möglich sein, diese gezielt anzusprechen um den Service zu starten.

E-Robot hat dafür ja nun den Service Starter (wie oben im Screeshot zu sehen) und den hätte der Entwickler da doch sicherlich nicht eingebaut wenn es nicht möglich wäre den auch praktisch anzuwenden.

Außerdem ... jede Menge Apps starten ihre Hintergrundaktivitäten nach "Boot complete".
Auf der Nutzerebene scheint es aber nicht möglich zu sein eine App im Hintergrund zu starten. Blöde is das.
Zumindest müsste es doch möglich sein, einer bestimmten App "boot complete" vorzugaukeln, damit sie im Hintergrund startet. Oder nicht?

Ebenso meine ich, sollte es doch möglich sein den running state eines Service zu überwachen, um ihn ggf. zu starten oder zu stoppen, wenn das nach dem Wunsch des Users nötig ist. Das System, oder die Apps selber scheitern da ja leider häufig.
Eine Task-Automationsapp könnte dazu hilfreich sein, wenn es gehen würde.

Normalerweise wird dies auch nicht umgesetzt - würde auch keinen Sinn machen, denn irgendwo müssen ja die Meldungen initiiert/ausgewertet/angezeigt/verarbeitet werden

Die App muss vorher natürlich gestartet werden, zusammen mit dem Service. Meistens laufen die Apps aber ohnehin schon im Hintergrund, nur der Service den man braucht eben nicht. Der Google GCM Service ist dafür das beste schlechte Beispiel.

 

[swa00]

Grundsätzlich sind Deine Überlegungen nicht so ganz verkehrt

Du lässt jedoch einen wesentlichen Gesichtspunkt ausser Acht :

Android ist im Kern ein LinuxSystem und das was Services, Apps und UI ausmacht, eine VM ( Java/Dalvik/Zygote)
Also zwei völlig unterschiedliche voneinander unabhängige Blöcke.

Hier mal etwas für die erweiterte Info :
Android OS boot process with focus on Zygote - codecentric AG Blog
Die Kommunikation beider Blöcke untereinander erfolgt hauptsächlich Messageorientiert auf TCP/IP Basis (Socket)

Z.B. der GCM Service wird durch bestimmte Aktionen eingeschaltet. Z.B. bei einer Änderung des Netzwerkstatus, oder wenn eine App startet die diesen Service nutzt.

Nein, weil : FCM/GCM ist ein Linux Daemon (C/C++ Server) und läuft i.d.R immer - ist also KEIN Java Service und
damit ausserhalb der VM.

Ein VM-Java Service ( so wie du ihn kennst) bedient sich i.d.R nur einem laufenden Daemon im Kernel und kommuniziert mit Diesem.
Ein Java-Service kann jederzeit vom Betriebssystem beendet werden und läuft auch nicht 24/7. Landläufig wird immer wieder
fälschlicherweise angenommen, ein Service kann rund um die Uhr laufen.

DEM IST NICHT SO - Siehe auch LifeCycle / GarbageCollector
Ein 24/7 Service muss von jedem guten Entwickler immer wieder beobachtet und bei Bedarf neu gestartet werden.
Selbst dann, wenn ein "Service" nicht mehr läuft, so ist dennoch der dazu gehörige Daemon im Kernel lustig aktiv.

Und damit nicht jeder Java Service alles aus dem Kernel verarbeitet, registriert er sich mit für Ihn wichtigen Funktionalitäten.
Ein Java Service ist also nichts Weiteres , als ein stummer Kollege, der sich im Hintergrund im Kernel registriert und
mit Teilen von Diesem quatscht. (Ähnlich vergleichbar mit der Subscription bei MQTT)

Wie finde ich nun diese Parameter heraus? Und was muss ich wo eintragen? (s.Screenshot)

Und was der stumme Package-Kollege machen/registrieren soll und vor allem , wann/wie er gestartet werden soll, entscheidet
der Entwickler der App. Du müsstest also die Info vom Entwickler der App haben, um einen Service gesondert vom Hauptrumpf
via Parameter (Intent) zu starten. (Das ist hier leider nicht genormt - Da kann jeder tun und lassen, was er mag)

Zumindest müsste es doch möglich sein, einer bestimmten App "boot complete" vorzugaukeln, damit sie im Hintergrund startet. Oder nicht?

Viele systemübergreifende Broadcasts werden auch nur vom Kernel aus an die VM geschickt und dort verarbeitet.
Anders würde es ja auch keinen Sinn machen, denn der Kernel entscheidet, wann er mit dem Bootvorgang fertig ist.
Wenn du also einen BOOT_COMPLETED an die VM absetzen möchtest, so solltest du den Umweg über den Linux Kern gehen.

[adb shell] am broadcast -a android.intent.action.BOOT_COMPLETED {Opt :} [-c android.intent.category.HOME ]

Damit sagst Du also dem Kernel, er soll ein BOOT_COMPLETE an die VM senden.
Die App, die BOOT_COMPLETED bei der Installation dann für sich registriert hat wird dann von der VM gelauncht.
(Dafür ist kein App-Service notwendig)

Auch eine App innerhalb der VM wird dies nicht bewerkstelligen können, Es sei denn, sie setzt den gleichen Shell
erst mal an den Kernel ab. (Meist nur als Rootuser) - Dieser Umweg ist also hier bei den neueren Versionen zwingend notwendig.

FCM :
Eine App, die FCM benutzen will, registriert sich dann auch mit ihrem Service quasi beim Linux FCM Daemon.
Auch hier sendet der FCM Daemon nach Empfang eine BroadcastMessage mit einem JSONBlock an das registrierte Java-Package.

Beispiel für eine simulierte FCM - Message:

[adb shell] am broadcast -n your.package.name/com.google.firebase.iid.FirebaseInstanceIdReceiver -c your.package.name -a com.google.android.c2dm.intent.RECEIVE .........

.
Anmerkung : Und der Austausch des FCM Daemon ist genau das , was im zweiten Schritt mit der Corona App passieren soll.
Es wird keine App/Service mehr notwendig sein, um Warnhinweise vom RKI zu empfangen. Der Kernel wird dies dann tun.
Das Gleiche passiert dann vermutlich mit dem NEAR/NFC und BT Daemon.

 

[Foh]

Nein, weil : FCM/GCM ist ein Linux Daemon (C/C++ Server) und läuft i.d.R immer - ist also KEIN Java Service und
damit ausserhalb der VM.

Dann meinen wir wohl unterschiedliche Dinge.
Ich meine den Google Service "GCMService". Dieser ist Teil der App "GoogleDienste"
Wenn dieser immer laufen würde, dann gäbe es keine Pushprobleme.
Dieser GoogleService stellt sich aber gerne mal ab, und wird dann nur durch bestimmte Aktionen wieder in den running state versetzt. (z.B. ein Netzwerkwechsel, oder Starten einer App die diesen Service nutzt)
Das kann ich auf meinem OS 4.1.2 ganz einfach mit der App "DisableService" erkennen.
Die App zeigt an, ob der Service aktiviert, oder deaktiviert ist, und auch, ob er gerade idle ist, oder im running state.
Ist er idle, kommen keine Push.
Mit dieser App kann ich den Service auch komplett deaktivieren. Dann gibt's Push natürlich überhaupt nicht mehr.
Es gibt auch andere Apps für neuere OS die das auch können. Z.B. "Servicely".
Der Pfad, oder String, oder whatever das ist, steht auch dabei. Ich hätte nun gehofft, dass das ein Teil der Parameter ist, die ich brauche um den Service via intent zu starten. (so meine laienhafte Wunschvorstellung)

Der GCMService kann z.B. auch durch eine GoogleActivity wieder in den running state versetzt werden.
Diese nennt sich GCMDiagnistics. Das geschieht nur leider nicht im Hintergrund, sondern ist quasi wohl ein Hilfsprogramm der Googleservices.
Hingegen durch das ab- oder einschalten des Netzwerks, wird der GCMService IM HINTERGRUND in den running state versetzt.
Es muss also eine Möglichkeit geben den Service im Hintergrund zum laufen zu bringen.

Dass das auf der normalen Userebene nicht geht ist klar, aber dafür gibt es ja root access. Damit sollte es doch irgendwie möglich sein, oder? Oder zur Not auch ein Xposed Modul.

Ein 24/7 Service muss von jedem guten Entwickler immer wieder beobachtet und bei Bedarf neu gestartet werden.

Wird aber oft nicht, oder diese Observierung scheitert eben, bzw. das restarten in den running state scheitert.
Daher will ich ja mit dem Servicestarter nachhelfen.

Du müsstest also die Info vom Entwickler der App haben, um einen Service gesondert vom Hauptrumpf
via Parameter (Intent) zu starten.

Gibt es denn kein Analysetool um die intent Parameter aufzuspüren?
Und vor allem beim GCMService müssten diese doch offen liegen, denn viele Entwickler greifen ja darauf zu.
Wenn ich z.B. EbayKleinanzeigen, oder WhatsApp starte, wird der eingeschlafene GCMService sofort in den runnig state gesetzt.
Tja, und das Aufwecken des GCM Service über die Netzwerkumschaltung (dabei spring er ja auch an) müsste sich doch auch simulieren lassen. (Das Netzwerk dürfte dabei aber nicht tatsächlich aus/angeschaltet werden)

Wenn du also einen BOOT_COMPLETED an die VM absetzen möchtest, so solltest du den Umweg über den Linux Kern gehen.
Code:
[adb shell] am broadcast -n your.package.name/com.google.firebase.iid.FirebaseInstanceIdReceiver -c your.package.name -a com.google.andro

Wie und wo gebe ich diesen Code ein? Und wie kann ich den BootComplete sender dann so filtern, dass nur die eine App darauf anspricht, aber nicht alle Apps plötzlich im Hintergund neustarten?
Und wieso gibt es dafür noch kein Tool, oder TaskerPlugin um solche Befehle auszuführen? Oder gibts?

Es wird keine App/Service mehr notwendig sein, um Warnhinweise vom RKI zu empfangen.

Sind das dann sogenannte CellBroadcasts?
Solchen nervigen Müll hatte ich jedenfalls zeitweise auf meinem Android9 Gerät. Da hieß es ständig in den Benachrichtigungen "CellBrodcast reveived". Mit den Nachrichten konnte ich rein gar nichts anfangen, als kämen sie vom Mars.
Wie es dann kam, dass das irgendwann aufgehört hat, weiß ich nicht.

Die CoronaApp wird auf meinem i9100 ohnehin nicht behilflich sein. Mit BT und GPS ständig an, wäre mein Akku spätestens nach 3 Stunden am Ende. Und was dann kommen wird, wenn die feststellen, dass ihre App auf vielen Geräten nicht funktioniert, möchte ich lieber nicht spekulieren.

 

[jogimuc]

Hallo Foh
Dir wurde doch schon im anderen thread gesagt das gcm durch FCM ersetzt wurde.

Zu dem Punkt wo kann der Code eingegeben werden.
Das ist eine commando Befehl den du über die Adb Verbindung eingegeben kannst. Es wurde auch sagt das du damit eine simulation auslösen kannst.
Also einer app die du gerade testes debuggst diese Nachricht schickst ohne das das Handy neu starten muss. Die app empfängt die Nachricht und du kannst schauen ob dein Code deiner app das macht was er soll.
Für viel mehr ist das nicht gedacht.
Am Anfang steht auch Adb Shell in klammer. Was dir eigentlich sagen müßte das es ein Adb Komando Befehl ist.

Adb ist eine Verbindung meist über USB mit dem Rechner, um mit dem Handy zu kommunizieren. Auch logcat nust diese Verbindung.

Der Code ist und geht auch nicht im Java Code.

 

[swa00]

@Foh

Gibt es denn kein Analysetool um die intent Parameter aufzuspüren?

Ich wiederhole mich ungerne das dritte Mal - NEIN ! - Kontaktiere den jeweiligen Entwickler.

Wie und wo gebe ich diesen Code ein?

Das habe ich bereits ausgeführt = ADB SHELL oder über eine App per root shell command

ADB ist das MUST-HAVE Tool für Diejenigen, die an ihrem System herumspielen möchten.
Die Foren sind voll mit Anleitungen dazu - Offizielle Literatur : Android Debug Bridge (adb) | Android Developers

Und wie kann ich den BootComplete sender dann so filtern, dass nur die eine App darauf anspricht, aber nicht alle Apps plötzlich im Hintergund neustarten?

Auch das ist von mir angegeben worden = siehe adb - option "your.package.name"



Desweiteren würfelst du meine adb shell kommandos in deinen Zitaten durcheinander.
Boot_completed hat nichts mit Firebase zu tun.

Anmerkung : Deine grundsätzliche Auffassung , wie das System ansich funktioniert scheint leider rudimentär falsch
zu sein - und vor allem obsolet.

Mit einem GCM basierenden 4.2.1 Stock (8 Jahre alt) wirst du auch nicht weltbewegend weiterkommen , sämtliche Libraries
und Apps haben sich über die Jahre geändert. GCM wird seit 2 Jahren nicht mehr unterstützt und wurde eliminiert
egal ob dein System dies noch installiert hat. Die Server dazu wurden nun abgeschaltet.
(Das habe ich dir bereits im letzten Jahr schon mal geschrieben)

Es ist mir also völlig rätselhaft, weshalb du immer noch diesen GCM-Service krampfhaft zum laufen bekommen möchtest,
obwohl er brav und vor allem korrekt vom System beendet wird, da durch FCM ersetzt

Daher habe ich mir auch nochmals die Mühe gemacht, die obige Antwort minutiös zu gestalten
Mehr kann - und werde ich auch nicht tun - auch wenn du gerne mit dem Kopf durch die Wand möchtest
.

 

[Foh]

Dir wurde doch schon im anderen thread gesagt das gcm durch FCM ersetzt wurde.

Es ist mir also völlig rätselhaft, weshalb du immer noch diesen GCM-Service krampfhaft zum laufen bekommen möchtest

Wie bereits gesagt, einen FCMService gibt es unter den Google Diensten nicht. Der heißt dort nach wie vor GCMService.
Das ist sowohl auf meine Android4.1.2 als auch auf meinem Android9.0 Gerät so.
Ich wüsste nicht, wieso das bei euch anders sein sollte. Ceck it out!

Ich gehe davon aus, dass der GCMService unter den GoogleDiensten ganz einfach nicht umbenannt wurde, und nun unter dem alten Namen "GCMService "die Aufgaben für FCM übernimmt. Zumal dies jawohl ein JAVA basierter Dienst ist, und, wie Du sagst, der eigentliche FCM Server 24/7 immer auf Kernelebene läuft, kann ich nun nur vermuten, dass der GCMService nach wie vor die PushSignale des FCMServers an die Apps weiterleitet, die diesen FCM Push Service nutzen.
Wenn ihr es nicht glaubt, deaktiviert doch mal den GCMService der GoogleDiensteApp, dann werdet ihr feststellen, dass z.B. WhatsAPP nicht mehr auf eingehende FCM Push reagiert. (jedenfalls ab dem Moment, wenn WhatsApp sich schlafen legt. Also so ca. paar Minuten. Solange WhatsApp noch wach ist, nutz die App eine eigene Pushverbindung)

Und wie bereits gesagt, dass ist bei JellyBean und bei Pie das selbe.
Deshalb "versuche ich krampfhaft den GCMService am laufen zu halten". Weil er den FCMService handelt.

Die GCM Server dazu wurden nun abgeschaltet.

Jaaaaaaa, ich weiß. Das ändert aber rein garnix daran, dass der GCMDienst der GoogleDienste App weiterhin die Signale des FCMServers verarbeitet. Solange der GCMService im running state ist, funktionieren alle FCM Push Benachrichtigungen einwandfrei. Auch auf meinen 8 Jahre alten System.

Das soweit dazu.
Mit dem Rest muss ich mich erst noch genauer beschäftigen ...
Solong.

 

[Foh]

@Foh
Auch das ist von mir angegeben worden = siehe adb - option "your.package.name"

Desweiteren würfelst du meine adb shell kommandos in deinen Zitaten durcheinander.
Boot_completed hat nichts mit Firebase zu tun.
.

Wenn ich das jetzt richtig verstehe, und mir den Command mal anschaue, dann bedeutet das, dass die App "your.package.name"
dann nicht im Hintergrund startet, sondern zunächst im Fordergrund startet und dann in den Hintergrund versetz wird. Richtig?
Zweimal "your.package.name" (am Ende und am Anfang) lässt mich das vermuten.
Wenn ich damit richtig liege, wäre das nicht die Lösung nach der ich suche, denn das ist ja schon seit langem mein Workaround.
Dieser hat den Nachteil, dass die App kurz aufgpoppt, unschön, und dass viele Automationsevents bei mir reagieren, wenn eine bestimmte App Focus erlangt. Das möchte ich in bestimmten Situationen vermeiden. Die Automationscommands, die auf den Event "App received Focus" reagieren, sollen nur reagieren, wenn ich eine App manuell, oder via Tasker Automation öffne, aber nicht, wenn z.B. ein Dienst einer App einschläft, und ich ihn daher durch erneutes starten der App aufwecken muss.

Die einzig saubere Lösung wäre also nur den bestimmten Dienst zu starten.
Geht aber nicht, sagste.
Und die Parameter für den Google Intent des GCMService sind nicht OpenSource?
Tja, dann werde ich den Dienst auch weiterhin über die GoogleActivity "GCM.Diagnostics" starten müssen.
Ziemlich blöde programmiert dieses Android.

Zu der Corona App habe ich jetzt übrigens auch detaillierte Infos gefunden:
>>>
In 2 Wochen gibt es eine App, die Sie nächste Woche installieren können, und dann wieder ein normales Leben ermöglichen wird, die aber frühestens fertig gestellt sein wird, wenn Sie wahrscheinlich schon tot sind, vielleicht aber nicht. Dann wird die App sie schützen, indem Sie sofort informiert werden, wenn Sie sich infiziert haben. Die App ist anonym und speichert keine Daten. Sie bekommen aber eine Warnung, dass Sie in Quarantäne müssen wenn Sie infiziert sein könnten, oder sie machen sich strafbar, freiwillig.
Die App ist kostenlos und funktioniert auf jedem Smartphone, es sei denn Sie haben keins, es ist inkompatibel, oder Sie haben es nicht am Ladegerät angeschlossen. Sollte die App bei ihnen nicht funktionieren, können Sie sich auch den Corona Chip implantieren, das ist auch freiwillig, ohne dürfen sie allerdings das Haus nicht mehr verlassen, das wird über die App kontrolliert.
<<<
Aloha ;-)