-
Wozu?
Autor: Hut+Burger 18.04.19 - 18:00
Ernstgemeinte Frage. Wenn Google aus Scham ihre Androidversion-Zahlen nicht mehr veröffentlicht, da Android Pie vermutlich eine Verbreitung von ~ i² % hat, was nützt es, Q zu unterstützen? In ein Paar Jährchen, wenn Q genug Marktanteile hat, könnte man anfangen darüber nachzudenken.
-
Re: Wozu?
Autor: logged_in 18.04.19 - 22:08
Worüber nachdenken? Es zu unterstützen? Wieso sollte man es nicht gezielt für die wenigen Geräte tun, die es dann unterstützen, wenn die Abwärtskompatibilität sowieso gegeben ist. Es ist ja ohnehin sinnvoll, sich möglichst früh mit den Änderungen auseinanderzusetzen.
Ich meine, beim Kompilieren einer App setze ich min-sdk und target-sdk fest. Und wenn ich das Target SDK jetzt schon mal Testweise auf Android Q setze, dann werde ich später nicht überrascht sein, dass dies oder jenes nicht mehr in der App funktioniert, weil z.B. neue Sicherheitsbeschränkungen hinzugekommen sind.
Mit Marktanteilen hat das rein gar nichts zu tun, das ist einfach der Weg.
Früher oder Später wirst Du dann Android Q-Nutzer haben, und für die wäre es ärgerlich, wenn deine App nicht mehr funktioniert.
1 mal bearbeitet, zuletzt am 18.04.19 22:11 durch logged_in. -
Re: Wozu?
Autor: treysis 18.04.19 - 22:40
Ich habe diese Trennung in MinSDK und TargetSDK noch nicht so ganz verstanden...
MinSDK heißt, meine App läuft mindestens auf dieser und jener Android-Version.
TargetSDK heißt, die App ist auf diese Android-Version zugeschnitten. Welche Vorteile bringt das nun genau, wenn sie doch genauso auf alten Versionen läuft, und auch Versionen mit älterem TargetSDK auch auf neueren Android-Versionen läuft?
Hast du vielleicht Lust, mir das knapp zu erläutern? -
Re: Wozu?
Autor: logged_in 19.04.19 - 12:18
Angenommen Du möchtest die neuen Benachrichtigungen von Android Pie (9) benutzen
https://developer.android.com/about/versions/pie/android-9.0#notifications
dann bleibt Dir nichts anderes übrig, als targetSdkVersion 28 zu setzen
Das gleiche gilt, wenn du z.B. zwei oder mehr Kamerastreams gleichzeitig aufnehmen willst.
https://developer.android.com/about/versions/pie/android-9.0#camera
Der Google Play Store schreibt auch seit letzten Jahr vor, dass neue Apps immer mindestens die vorletzte SDK-Version als targetSdkVersion benutzen müssen, bei Upgrades sind die toleranter.
https://developer.android.com/distribute/best-practices/develop/target-sdk
Im Grunde geht es dort immer um die Nutzung von neuen Features. Muss man nicht haben, kann aber ein Vorteil sein.
In meinem Fall weiß ich z.B. dass möglicherweise die Share Sheets von Android Q ein großes Problem für mich werden, weshalb ich mich möglichst früh damit auseinandersetzen möchte. Also in 1-2 Monaten vielleicht. Da bin ich dann froh, dass es jetzt schon möglich ist, das auszuprobieren.
--
Die minSdkVersion ist eher ein Hinweis an den Google Play Store, die App bei älteren Geräten als inkompatibel anzuzeigen. Wenn Deine App z.B. BluetoothLE benötigt, dann müsste minSdkVersion 21 angegeben werden, da es erst ab dieser Version verfügbar ist. Die App kann auch minSdkVersion 14 angeben, dann muss aber der Code drin sein, der überprüft, dass die nicht vorhandenen Funktionen auch nicht aufgerufen werden, also dass die App nicht crasht, wenn sie BluetoothLE benutzen will.
In meinem Fall war minSdkVersion 21 nötig, da ich multidex benötigen musste
https://developer.android.com/studio/build/multidex und nicht auf eine alte Lösung zugreifen wollte, da diese Probleme machte. Außerdem wurde mir angegeben, dass 85% aller Geräte >= 21 sind, was ok war (alle Geräte mit ART-Unterstüzung).
Wenn appcompat benutzt wird ( = im Grunde Material Design https://developer.android.com/topic/libraries/support-library/packages#v7-appcompat ), dann ist minSdkVersion 14 vorgeschrieben. Oder wenn man eine Library von anderen mit einbindet, und die eine minSdkVersion vorschreibt, die höher ist, als die, die man selbst benutzt hätte, dann muss man sie auch hochsetzen. -
Re: Wozu?
Autor: treysis 19.04.19 - 18:20
Ah besten Dank.
Trotzdem ist mir noch unklar, wozu man minSDK wirklich braucht. Kann man die App wirklich so schreiben, dass sie sowohl alte, als auch neue APIs nutzt? Das hört sich für mich irgendwie seltsam an. Ok, ich verstehe, so Funktionen wie "Direkt antworten" seit Android 7(?) können auf alten Geräten nicht funktionieren, die Messenger-App sollte dann aber trotzdem generell mit den Standard-Funktionen auch auf alten Geräten laufen. Oder, dass man die Berechtigungen genauer anpassen kann: habe ich eine alte App mit altem targetSDK, dann wird auch auf neueren Android-Versionen pauschal für alle Berechtigungen erfragt, aber mit neuerem targetSDK geht es halt auf alten Versionen wie bisher, und bei neuen Versionen dann einzelne Berechtigungen, richtig verstanden? -
Re: Wozu?
Autor: logged_in 19.04.19 - 21:54
Die neuen APIs sind eine Ergänzung zu den alten.
Im Falle der neuen Benachrichtigungen von Android Pie würde man dann schreiben
if os.version >= Android Pie then
use improved notifications
else
use old notifications with less features
Mit BluetoothLE hatte ich einen Fehler. Ab 21 wird ein neues API angeboten, zuvor konnte man auch schon BLE benutzen. Wenn jetzt die Entwickler keine Lust haben, Teile des Codes mit "if os.version" vollzupflastern, dann setzen die einfach minSDK 21 und benutzen nur noch das neue API, älteren Geräten wird die App dann nicht im Play Store angezeigt.
Wegen minSDK aber ein besseres Beispiel: Eingeführt wurde Material Design mit KitKat (5) = API Level 21. Zusätzlich hat Google dann aber eine Bibliothek bereitgestellt, die man in die App einbetten kann, die sogenannte "v7 appcompat library", mit der das Material Design auch auf älteren Geräten lief. Dort war es dann nicht Teil des OS, sondern eben eine zusätzliche Bibliothek. Sonst hätten alle pre-KitKat Apps noch dieses flache, dunkle UI und keine Möglichkeit das neue zu benutzen, was für Entwickler auch bedeuten würde 2 Versionen der App bereitzustellen. Diese "v7 appcompat library" hat aber ein minSDK von 14, d.h. man kann die ab Ice Cream Sandwich (4) = API Level 14 benutzen. Honeycomb war ja nur so eine komische Zwischenversion vor ICS, die eine neue UI Rendering Engine in Android reinbrachte, zuvor war alles dieses komische UI was man von den ersten Android-Versionen kennt verfügbar.
In der Regel kann man das minSDK sehr niedrig setzen, was aber nicht viele Vorteile bietet (Anzahl der unterstützten Geräte ist der einzige Vorteil). Vor ICS war die Zwischenversion Honeycomb, die wie gesagt nie eine richtige Version war, und zuvor Gingerbread (2.3) = API-Level 10. Gingerbread (v10) hatte im Oktober 2018 noch 0.2% der Geräte, und ICS (v14,15) 0.3%. Jelly Bean (v16,17,18) 3% und KitKat (v19) 7.8%. Wenn man also minSDK 14 setzt dann kann man das Material Design benutzen und unterstützt werden so gut wie alle Geräte. Das wäre die Restriktion, die von appcompat vorgegeben wäre.
Es gibt aber eben auch noch andere Dinge, die Restriktionen vorgeben. Z.B. ob man bestimmte Features von Java 1.8 benutzen möchte, oftmals hat es aber damit zu tun, dass Entwickler einfach bestimmte Altlasten loswerden wollen.
Wegen den Berechtigungen: Updates übernehmen die Zustimmung der Vorgängerversion. Wenn eine neue Version rauskommt und die zum ersten mal installiert wird, dann muss man sich an die neuen Regeln halten, wenn sie als targetSDK die neue OS Version hat, die diese neue Regel einführt, z.B. den Nutzer fragen, ob er es zulässt, dass die Kamera verwendet wird. Wenn die Vorgängerversion der App aber diese Regel nicht kannte, weil das OS der targetSDK-Version sie nicht erforderte, dann gilt die als zugestimmt wenn die App damals installiert wurde. Deswegen pushen die seit letztem Jahr auf dem Google Play Store diese Regel, dass targetSDK recht aktuell sein muss, damit auch die Berechtigungen bei Neuinstallationen eingefordert werden.
6 mal bearbeitet, zuletzt am 19.04.19 22:02 durch logged_in. -
Re: Wozu?
Autor: Anonymer Nutzer 20.04.19 - 11:46
Hut+Burger schrieb:
--------------------------------------------------------------------------------
> Ernstgemeinte Frage. Wenn Google aus Scham ihre Androidversion-Zahlen nicht
> mehr veröffentlicht, da Android Pie vermutlich eine Verbreitung von ~ i² %
> hat, was nützt es, Q zu unterstützen? In ein Paar Jährchen, wenn Q genug
> Marktanteile hat, könnte man anfangen darüber nachzudenken.
Ernstgemeinte Frage, bist du Entwickler? Man sieht ja immer wieder wenn Entwickler ihre Apps, Treiber und Programme erst zu Release anschauen.
Wenn du eine halbwegs ernsthafte App anbietest, sollte die auch bei Release auf Android Q laufen.



