Haftpflicht Blogger
Virtual Server von Host Europe

Android-Mindest-SDK: Eine schwierige Entscheidung

| 21. November 2012 | Keine Kommentare

Das Betriebssystem Android wird von Google ständig verbessert und um neue Funktionalitäten erweitert. Augenblicklich (Stand Apr. 2018) hat Android den Versionsstand 8.1 (API 27) erreicht.

Gleich zu Beginn der Programmierung einer Android App wird man vor die Frage gestellt,  für und mit welchen Android Betriebssystemversion (SDK’s, API’s) man programmieren möchte.

  • Minium Required SDK:
    Ich sichere zu, dass meine App auf allen Geräten lauffähig ist, die mindestens diese Betriebssystemversion besitzen.
  • Target SDK:
    Meine App benutzt Funktionalitäten dieser API. Die App wurde für diese API-Version voll getestet.
  • Compile With:
    Die App soll mit dieser Android SDK-Version compiliert werden.

Wertebelegung: Allgemeine Herangehensweise

Die allgemeine Herangehensweise ist sicherlich, bei

  • Minimum Required SDK, einen möglichst niedrigen Wert einzugeben. In manchen, veralteten Android Büchern wird hier zu Android 1.5 (API 3) geraten.
  • Target SDK, die Funktionalitäten, die man implementieren möchte, im Hinterkopf zu haben und eine (bekanntermaßen) stabile SDK Version zu wählen, die diese Funktionalitäten in der API mitbringt
  • Compile With, die möglichst aktuellste SDK-Version zu wählen, bei der sich die API Signaturen (Methoden- und deren Parameternamen) nicht geändert haben, in der jedoch dennoch der eine oder andere interne API-Bug korrigiert wurde.

 

Mindest SDK Version: Die Qual der Wahl

Ich möchte mich in diesem Blogartikel schwerpunktmäßig mit der Frage nach der Android-Mindest-SDK Version befassen.

Entscheidungskriterien

Marktanteile

Welche Android-Betriebsystemversionen werden auf den Endgeräten eingesetzt?

Stand: 31.03.2018

Android

Anteil API

Lauffähig auf wieviel Endgeräten

bis 4.3 5.7 % -18 100.0 %
4.4 12.0 % 19 94.3 %
5.0 5.4 %  21 82.3 %
5.1 19.2 % 22 76.9 %
6.0 28.1 % 23 57.7 %
7.0 22.3 % 24 29.6 %
7.1 6.2 % 25 7.3 %
8.0 0.8 % 26 1.1 %
8.1 0.3 % 27 0.3 %

Wie zuvor erwähnt, in vielen Android-Büchern findet sich der Rat, die Mindest SDK Version auf 1.5 zu setzen, um das Maximum an Abdeckung von Endgeräten (insbes. Smartphones) zu gewährleisten. Mit dieser Angabe kann man 100% des Marktes abdecken (Quelle: Statista).

Ich möchte ganz provokativ die Frage stellen:
Möchte ich denn immer Apps für die Ewig-Gestrigen programmieren und mir eine Selbstbeschränkung der Programmmöglichkeiten auferlegen, denn schließlich sichere ich mit der Mindest-SDK-Angabe ja zu, dass mein Programm auch auf diesem niedrigen Level läuft?

Oder möchte ich aus dem vollen Schöpfen und neue Funktionalitäten, von den der Endanwender ja auch gehört hat, auch in meiner App diesem Benutzer anbieten können.

Zielgruppe

Habe ich es mit sehr innovativen Endbenutzer zu tun, die immer das neueste Gerät, die neueste Betriebssystemversion, die neueste Funktionalität haben wollen?

Anwendungsanforderungen

Es wären Fragen zu beantworten wie:
Braucht meine App die 360 Grad Darstellung bei Bildern oder genügt die normale Kamerafunktionalität?

Qualitätssicherung

So mancher Programmierer behauptet, dass seine Programme fehlerfrei seien. Die Wahrheit ist, dass kein Programm fehlerfrei ist, man kann nur durch Qualitätssicherungsmaßnahmen (autom. Tests, Integrationstests, Anwendertests) den Qualitätslevel sehr hoch setzen.
Wenn man eine App für die API-Level 3 bis 17 freigibt, dann sollte man idealerweise auch seine Anwendung gegen diese API’s voll getestet haben.
Gut, wer hier Testskripte hat, die diesen Testaufwand automatisieren und bei jeder Weiterentwicklung erneut gestartet werden können.

Aber, diese Qualitätssicherung durch die Erstellung von Tests hat seinen Preis (Währung: Zeit und Geld).

Entwicklungsaufwand

Allgemein 300x250

Anzeige

Was wäre zu tun, wenn man unbedingt als Mindest-API 1.5 haben möchte, andererseits aber eine Anwendung mit komplexerer Funktionalität hat, die nicht mit dieser Mindest-SDK-API zu realisieren ist?

Damit die App beim Aufruf einer nicht unterstützten Funktionalität nicht abstürzt, müßte man Sicherheitsvorkehrungen treffen, d.h. die gegebene API-Version des Gerätes abfragen und dann erst die Funktionalität entweder freigeben oder den Endanwender höflichst darauf aufmerksam machen, dass sein Gerät diese Funktionalität nicht unterstützt.

Es stellt sich für mich allerdings die Frage, ob dieses „Nein, du darfst nicht/Nein, Du kannst nicht“, selbst wenn es höflich formuliert ist, den Benutzer nicht nervt und der Schuss nach hinten losgeht und er nicht seiner veralteten Betriebssystemversion, sondern ungerechterweise der App die Schuld gibt.

Niemand liebt Apps mit eingeschränkter Funktionalität.

Der Endanwender rechnet es dem App-Herausgeber eben gerade nicht hoch an, dass er als Benutzer die App überhaupt aufrufen kann, sondern für ihn steht das „Ich kann mit dieser App nicht …“ im Vordergrund.

 

Meine, persönliche Abwägung

Wenn ein Auftraggeber heute eine App für den Durchschnittsanwender/-markt möchte, dann würde ich empfehlen, den Mut aufzubringen und sich auf Endgeräte ab Android 4.4 zu beschränken.

Das spart signifikant Zeit (TTM/TimeToMarket) und Kosten (ROI/Return of Investment).

Links zum Artikel

Developer.android.com: Android Marktanteile  (Google)

Stichworte: ,

Kategorie: Android

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.