Android App Entwicklung unter Ubuntu

Für ein Heimautomatisierungsprojekt wollte ich "mal eben schnell" eine kleine Android app machen die ein paar http requests abschickt und sich danach über SSH mit dem System verbindet.

Ja, da habe ich mich massiv verschätzt. Offenbar ist man sich da noch nicht so ganz einig ob man dieses experimentelle http Protokoll unterstützen soll...

Oder mein Ansatz war komplett verkehrt. ich gebe auf und muss nachfragen...

Okay, was ich will:

Startup:
(Erstmal alles statisch hardcoded um die minimal Funktionlalität zu testen)
http request machen
Antwort abwarten
mit den Daten aus der Antwort einen SSH Verbindung starten (Antwort abwarten...)

Oberfläche mit einem Button:
Button schickt ein command via SSH (und erwartet antwort)


Bisher habe ich versucht:
Android Studio

http request
Und in den letzten Stunden musste ich festetellen das da wohl alles wahnsinnig veraltet ist und nichts mehr so funktioniert wie es die meisten auffindbaren Anleitungen darstellen oder diese mit sich intern nicht mehr kompatibel sind weil externe Teile geupdatet wurden.


Ich bin daher unsicher ob ich nicht vielleicht den völlig falschen Ansatz gewählt habe. HTTP ist jetzt nicht unbedingt cutting edge. Es kann doch nicht sein. Das etwas für das es sonstwo so alte Bibliotheken gibt. Sich hier scheinbar alle paar Jahre die Versionen so inkompatibel verändern das nichts mehr funktioniert.

Konkretes Beispiel:

Die "compile" Anweisung ist wohl seit ca 2016 deprecated und irgendwann raus geflogen. Ich muss hier doch irgendwo falsch abgebogen sein oder? Die Situation für Android Development kann doch nicht so katastrophal sein.

Ich musste die IDE schon über snap installieren aber direkt in den Repos habe ich nichts gefunden. Das war im Prinzip schon die erste Unsicherheit. Und ich habe es aus dem Ubuntu wiki (Android Studio › Wiki › ubuntuusers.de) also sollte das doch schon einigermaßen zuverlässig sein oder?

Ganz davon abgesehen, das das schon ein interessantes Thema ist (zu dem ich nur beitragen kann, das ich auch einmal versucht habe eine App zu schreiben und zu dem Schluss gekommen bin das das deutlich aufwendiger ist alles gedacht), stellt sich mir die Frage ob es da nicht allgemein ein besseres Vorgehen gibt.
Z.b. bestehende gute Systeme zur heimautomaion mit app?

Das Elend können wir meinetwegen woanders diskutieren. Ich habe weiss Dende genug Material mich über die Systeme auszukotzen.


Aber in der Zwischenzeit ist mir klar geworden: Wenn man einen perfekt funktionierenden Hammer hat. Kann man auch jedes Problem wie einen Nagel behandeln und komplett über den Webbrowser gehen.

Die Androidsache würde mich trotzdem interessieren.

Ich kann nur noch raten, das der einzige unterstützte Weg wohl Windows ist? Ich hab jetzt allerdings nicht wirklich Bedarf extra dafür ne VM einzurichten um dann da genauso hängen zu bleiben.

Also die Native Funktion lauf Android API Referenz ist https://developer.android.com/reference/java/net/HttpURLConnection
Seit Android 11 / SDK-Level 30+ sind im Standard nur noch https-Verbindungen erlaubt.
Es gibt wohl ein Flag das CleartextTraffic erlaubt - die Frage ist dann wie lange das noch funktioniert.

Hier gibt es ein Tutorial dafür HttpURLConnection: Android Tutorial

Android Studio gibt es natürlich auch für Linux Install Android Studio | Android Developers

Davon abgesehen ist meine Heimautomation zu Hause ohne *(fast) ohne Cloud von Drittanbietern und je nach Sensor / Gerät nutze ich W-Lan, Zigbee oder properitäre Protokolle... völlig egal.
*(z.B. der Siemenskühlschrank lässt sich nicht ohne die Cloud verbinden, da der z.B. nur meldet ob die Tür zu lange auf war - ist mir das in dem Fall egal).
Das ganze kostenfrei.
Mein Vorschlag ging eher deswegen in die Richtung da sich bei über Jahre, von Zig Entwicklern entwickelte Systeme oftmals durchaus Sicherer sind wenn da *irgendwas* aus dem Internet erreichbar ist und b) halt auch regelmäßig gepflegt werden was - je nachdem welches Handy du / die Benutzer haben könnte es gut sein das auch die einfachste App eben dann aktualisiert werden muss.

Aber das können wir gerne wo anders bereden ;D

Das "Tutorial" ist Beispielcode der nur hilft wenn man einen unbekannten Rattenschwanz von DevUmgebung bereits aufgesetzt hat. (Sieh dir mal das zugehörige git an, da konnte ich in 5 Minuten manueller Suche den Code garnicht finden) Gradle zum Beispiel sagt mir garnix, das sind wieder Recherche Stunden nur um Abhängigkeiten von etwas hinterher zu laufen von dem ich nicht weiss ob es dann klappt. Zumal da auch nicht steht wo das getestet wurde. Siehe meine Befürchtung das die Linux Umgebungen keinen Support haben.

Android Studio ist bereits installiert und die Probleme damit:

Ich musste die IDE schon über snap installieren aber direkt in den Repos habe ich nichts gefunden. Das war im Prinzip schon die erste Unsicherheit. Und ich habe es aus dem Ubuntu wiki (Android Studio › Wiki › ubuntuusers.de) also sollte das doch schon einigermaßen zuverlässig sein oder?

Zum Vergrößern anklicken....

Soweit ich das sehe ist dein Link noch eine Schritt weiter von richtigem Support entfernt.
So nach dem Motto: "Ja läuft haben wir irgendwann getestet, die executable startet vermutlich auf irgendeinem Linuxsystem das wir damals getestet haben." Ich weise darauf hin das 2016 auch "irgendwann" war. Siehe okhttp deprecation.


Unterstützt sieht anders aus.

Ich sehe durchaus ein wie das für das Thema im weiteren Sinne relevant ist. Z.B. wenn hier jemand anders drüber stolpert. Aber für mich uninteressant. Wenn ich so viel Aufwand betreiben wollte würde ich aktuell die kürzere Strecke im root access sehen. Denn erfolgreich C++ kompiliert und ausgeführt habe ich in der Vergangenheit schon. Also beides auf einem Android Handy, sonst wäre es nicht fürs Thema relevant.

Wenn ein Aufwand schon sein muss, dann bevorzuge ich allgemeingültige Lösungen und gehe nicht in irgendeinen walled garden. Auch wenn das dann etwas mehr kostet. Wenigstens habe ich mich dann nicht an eine Firma gekettet.

In anderen Worten:
50 Stunden in eine proprietäre Lösung schütten die mir nachher nicht gehört: Inakzeptabel
Selbst wenn die alternative 150 Stunden Maschinencode reverse engineering bedeutet.

alter_Bekannter schrieb:

Das "Tutorial" ist Beispielcode der nur hilft wenn man einen unbekannten Rattenschwanz von DevUmgebung bereits aufgesetzt hat. (Sieh dir mal das zugehörige git an, da konnte ich in 5 Minuten manueller Suche den Code garnicht finden) Gradle zum Beispiel sagt mir garnix,

Zum Vergrößern anklicken....

Klar muss man dafür eine der Devumgebung haben, das Tutorial handelt ja von der Api-Funktion.

Gradle is an open-source build automation tool focused on flexibility and performance. Gradle build scripts are written using a Groovy or Kotlin DSL. Read about Gradle features to learn what is possible with Gradle.

Zum Vergrößern anklicken....

Das hat mit dem Tutorial also nicht wirklich etwas zu tun und kann man in wenigen Sekunden erfahren.
Die wichtigen Punkte stehen wohl im tut alleine.

alter_Bekannter schrieb:

Zumal da auch nicht steht wo das getestet wurde. Siehe meine Befürchtung das die Linux Umgebungen keinen Support haben.

Zum Vergrößern anklicken....

Nein aber das es auch nicht so arg viele Abhängigkeiten gibt ist das eigentlich auch recht flott selbst getestet.



Beim ganzen Rest deines Artikels habe ich keine Ahnung was du mir damit sagen willst.
Von welchem Anbieter wo abhängig?

Womit werden Android Apps programmiert?

Java.

+kotlin, natürlich c/c++ aber auch c#

Mittlerweile gehts. Ich habe einfach mal die Basis Lib die drin ist probiert wie von drfuture verlinkt und bin auf Java umgestiegen.
Rückblickend habe ich den Verdacht das es auch vorher teilweise an Androidrichtlinien gescheitert ist, von denen ich nichts wusste.

Zum Beispiel wirft das wohl eine exception wenn man im GUI Thread eine Netzwerkverbindung aufmacht. Ich hab doch glatt vergessen wie nervtötend Java sein kann.

Zum letzten Absatz der bei dir Fragen aufwarf:
Ich bin irrtümlich davon ausgegangen das es sich um proprietären Mist handelt. Und war auch in dem Moment zu faul nach zu prüfen was es war. Irrtum meinerseits.

Jetzt freunde ich mich gerade mit der GUI Logik an. Der Rest funktioniert relativ normal. Naja wenn man es als normal betrachtet das die IDE einem Errors für unbehandelte potentiell auftretende Exceptions anzeigt. Ja richtig, die IDE zeigt "error" für uncaught exception VOR* der Ausführung. Also nur für den Fall das die aftritt und generelles Handling wird dafür ignoriert. Es will spezifische Exceptions explizit gehandelt haben. Das macht eignetlich kaum Sinn, das kann man vermutlich irgendwo ausschalten.

*Was die vorher erwähnte Networkexception noch seltsamer macht. Denn die sorgt für einen Crash zur Laufzeit. Und das bekommt nicht mal ein Warning. Das ist schon sehr äh, "gewöhnungsbedürftig".

alter_Bekannter schrieb:

Naja wenn man es als normal betrachtet das die IDE einem Errors für unbehandelte potentiell auftretende Exceptions anzeigt. Ja richtig, die IDE zeigt "error" für uncaught exception VOR* der Ausführung. Also nur für den Fall das die aftritt und generelles Handling wird dafür ignoriert. Es will spezifische Exceptions explizit gehandelt haben. Das macht eignetlich kaum Sinn, das kann man vermutlich irgendwo ausschalten.

Zum Vergrößern anklicken....

Nein, kann man nicht... das ist auch kein Bug, sondern ein (m.E. ziemlich fragwuerdiges) Feature von Java, die Checked Exceptions. Exceptions, die NICHT von RuntimeException erben, muessen (mit throws) explizit deklariert oder (mit try-catch) behandelt werden. Auch wenn die "Behandlung" nur darin besteht, dieselbe Exception verpackt in eine RuntimeException wieder zu schmeissen:

Im Elfenbeinturm des Java-Sprachdesigns koennte man ja vielleicht meinen, damit Exception-Handling sicherzustellen sei eine gute Idee. In der Praxis ist das aber ziemlich bloed, weil man Exceptions regelmaessig nicht direkt dort behandeln kann, wo sie auftreten, sondern weiter oben im Call-Stack, z.B. im GUI-Code wo ein API-Aufruf ausgeloest wurde, und wo man dann auch den User informieren kann, dass der nicht funktioniert hat.
Dank Checked Exceptions muss man dafuer jetzt aber entweder interne Details (in Form aller Checked Exceptions, die irgendwelche benutzten Libraries schmeissen koennen) in jeden Methodenheader setzen, oder man faengt die Exception und verpackt sie in eine RuntimeException, was die Stacktraces nicht gerade uebersichtlicher macht.
Ausserdem machen Checked Exceptions Lambdas und Methodenreferenzen kaputt, die als Runnable/Supplier/Consumer/... uebergeben werden, weil diese Klassen keine Checked Exceptions schmeissen duerfen. Ziemlich laestig z.B. in Streams.

Wenn du mich fragst, sind Checked Exceptions in der Praxis dazu gut, unnoetigen Boilerplate-Code zu generieren, und sonst fuer ziemlich wenig

Schön zu hören das man nicht nur seinen Verstand verliert, sondern der Schwachsinn wirklich da ist.

Ich würde dir als Alternative sonst noch immer vorschlagen dir einmal "Home Assistant" anzusehen.