Was ist der Unterschied zwischen der Min- und der Target-SDK-Version, wenn es um die Entwicklung von Anwendungen für Android geht? Eclipse lässt mich kein neues Projekt erstellen, wenn die Min- und Target-Versionen nicht identisch sind!
Antworten
Zu viele Anzeigen?Der Kommentar des Fragestellers (der im Grunde behauptet, dass das targetSDK keinen Einfluss auf die Kompilierung einer Anwendung hat) ist völlig falsch! Tut mir leid, dass ich so offen bin.
Kurz gesagt, hier liegt der Sinn darin, ein anderes targetSDK als das minSDK zu deklarieren: Es bedeutet, dass Sie Funktionen aus einem höheren SDK als dem minimalen verwenden, aber Sie haben Abwärtskompatibilität gewährleistet . Mit anderen Worten: Stellen Sie sich vor, Sie möchten eine Funktion nutzen, die erst kürzlich eingeführt wurde, aber für Ihre Anwendung nicht entscheidend ist. Sie würden dann das targetSDK auf die Version setzen, in der diese neue Funktion eingeführt wurde, und das Minimum auf eine niedrigere Version, so dass jeder Ihre Anwendung weiterhin nutzen kann.
Nehmen wir an, Sie schreiben eine Anwendung, die in hohem Maße von der Gestenerkennung Gebrauch macht. Jeder Befehl, der durch eine Geste erkannt werden kann, kann jedoch auch über eine Schaltfläche oder das Menü ausgeführt werden. In diesem Fall sind Gesten ein "cooles Extra", aber nicht unbedingt erforderlich. Daher würden Sie den Ziel-SDK auf 7 ("Eclair", als die GestureDetection-Bibliothek eingeführt wurde) und den Mindest-SDK auf Stufe 3 ("Cupcake") setzen, damit auch Leute mit sehr alten Handys Ihre App nutzen können. Sie müssten nur sicherstellen, dass Ihre App die Android-Version überprüft, auf der sie läuft, bevor sie versucht, die Gestenbibliothek zu verwenden, um zu vermeiden, dass sie versucht, sie zu verwenden, wenn sie nicht vorhanden ist. (Zugegebenermaßen ist dies ein veraltetes Beispiel, da kaum noch jemand ein Telefon der Version 1.5 besitzt, aber es gab eine Zeit, in der die Aufrechterhaltung der Kompatibilität mit Version 1.5 wirklich wichtig war).
Ein weiteres Beispiel: Sie könnten dies verwenden, wenn Sie eine Funktion von Gingerbread oder Honeycomb nutzen möchten. Einige Leute werden die Updates bald erhalten, aber viele andere, insbesondere mit älterer Hardware, bleiben vielleicht bei Eclair, bis sie ein neues Gerät kaufen. Auf diese Weise könnten Sie einige der coolen neuen Funktionen nutzen, ohne jedoch einen Teil Ihres möglichen Marktes auszuschließen.
Es gibt einen wirklich guten Artikel aus der Blog für Android-Entwickler darüber, wie diese Funktion verwendet werden kann, und insbesondere darüber, wie der oben erwähnte Code "Prüfen Sie, ob die Funktion vorhanden ist, bevor Sie sie verwenden" aussehen soll.
An den OP: Ich habe dies hauptsächlich zum Nutzen aller geschrieben, die in Zukunft über diese Frage stolpern, da ich weiß, dass Ihre Frage schon vor langer Zeit gestellt wurde.
Android:minSdkVersion
Eine ganze Zahl, die die Mindest-API-Stufe angibt, die erforderlich ist, damit die Anwendung ausgeführt werden kann. Das Android-System verhindert, dass der Benutzer die Anwendung installiert, wenn der API-Level des Systems niedriger ist als der in diesem Attribut angegebene Wert. Sie sollten dieses Attribut immer deklarieren.
Android:targetSdkVersion
Eine ganze Zahl, die die API-Stufe angibt, auf die die Anwendung abzielt.
Wenn dieses Attribut gesetzt ist, sagt die Anwendung, dass sie auf älteren Versionen (bis minSdkVersion) laufen kann, aber explizit getestet wurde, um mit der hier angegebenen Version zu funktionieren. Die Angabe dieser Zielversion ermöglicht es der Plattform, Kompatibilitätseinstellungen zu deaktivieren, die für die Zielversion nicht erforderlich sind (und die andernfalls zur Aufrechterhaltung der Vorwärtskompatibilität aktiviert sein könnten), oder neuere Funktionen zu aktivieren, die für ältere Anwendungen nicht verfügbar sind. Dies bedeutet nicht, dass Sie verschiedene Funktionen für verschiedene Versionen der Plattform programmieren können - es informiert die Plattform lediglich darüber, dass Sie mit der Zielversion getestet haben und die Plattform keine zusätzliche Arbeit leisten sollte, um die Vorwärtskompatibilität mit der Zielversion zu erhalten.
Weitere Informationen finden Sie unter dieser URL:
http://developer.Android.com/guide/topics/manifest/uses-sdk-element.html
Ein Konzept kann besser mit Beispielen vermittelt werden, immer . Ich hatte Schwierigkeiten, diese Konzepte zu verstehen, bis ich mich in den Quellcode des Android-Frameworks vertiefte und einige Experimente durchführte, selbst nachdem ich alle Dokumente auf Android-Entwickler-Websites und die entsprechenden Stackoverflow-Threads gelesen hatte. Ich werde zwei Beispiele teilen, die mir sehr geholfen haben, diese Konzepte vollständig zu verstehen.
A DatePickerDialog sieht anders aus, je nachdem, welche Stufe Sie in der Datei AndroidManifest.xml unter targetSDKversion( <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>
). Wenn Sie den Wert 10 oder niedriger einstellen, wird Ihr DatePickerDialog wie links aussehen. Wenn Sie hingegen den Wert 11 oder höher einstellen, sieht der DatePickerDialog wie rechts aus, mit genau demselben Code .
Der Code, den ich zur Erstellung dieses Beispiels verwendet habe, ist supereinfach. MainActivity.java
aussieht:
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
public void onClickButton(View v) {
DatePickerDialog d = new DatePickerDialog(this, null, 2014, 5, 4);
d.show();
}
}
Und activity_main.xml
aussieht:
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:onClick="onClickButton"
android:text="Button" />
</RelativeLayout>
Das war's. Das ist wirklich jeder Code, den ich brauche, um das zu testen.
Und diese Veränderung des Aussehens ist kristallklar, wenn Sie die Quellcode des Android-Frameworks . Es geht so:
public DatePickerDialog(Context context,
OnDateSetListener callBack,
int year,
int monthOfYear,
int dayOfMonth,
boolean yearOptional) {
this(context, context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB
? com.android.internal.R.style.Theme_Holo_Light_Dialog_Alert
: com.android.internal.R.style.Theme_Dialog_Alert,
callBack, year, monthOfYear, dayOfMonth, yearOptional);
}
Wie Sie sehen können, holt sich das Framework die aktuelle targetSDK-Version und setzt ein anderes Theme. Diese Art von Codeschnipsel( getApplicationInfo().targetSdkVersion >= SOME_VERSION
) können hier und da im Android-Framework gefunden werden.
Ein weiteres Beispiel ist die WebView Klasse. Die öffentlichen Methoden der Webview-Klasse sollten im Haupt-Thread aufgerufen werden, und wenn nicht, löst das Laufzeitsystem eine RuntimeException
, wenn Sie targetSDKversion 18 oder höher einstellen. Dieses Verhalten kann eindeutig mit seinen Quellcode . Es ist einfach so geschrieben.
sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >=
Build.VERSION_CODES.JELLY_BEAN_MR2;
if (sEnforceThreadChecking) {
throw new RuntimeException(throwable);
}
Das Android-Dokument sagt: " Da sich Android mit jeder neuen Version weiterentwickelt, können sich einige Verhaltensweisen und sogar das Erscheinungsbild ändern ." Wir haben uns also mit der Veränderung von Verhalten und Aussehen befasst und damit, wie diese Veränderung zustande kommt.
Zusammenfassend sagt das Android-Dokument " Dieses Attribut (targetSdkVersion) teilt dem System mit, dass Sie gegen die Zielversion getestet haben und das System sollte kein Kompatibilitätsverhalten ermöglichen um die Vorwärtskompatibilität Ihrer Anwendung mit der Zielversion zu gewährleisten. ". Dies ist im Fall von WebView sehr deutlich. Bis zur Veröffentlichung von JELLY_BEAN_MR2 war es in Ordnung, die öffentliche Methode der WebView-Klasse auf einem Nicht-Haupt-Thread aufzurufen. Es ist unsinnig, wenn das Android-Framework eine RuntimeException auf JELLY_BEAN_MR2-Geräten auslöst. Es sollte einfach nicht neu eingeführte Verhaltensweisen in seinem Interesse aktivieren, die zu einem fatalen Ergebnis führen. Was wir also tun müssen, ist zu prüfen, ob auf bestimmten targetSDK-Versionen alles in Ordnung ist. Die Einstellung einer höheren targetSDK-Version bringt Vorteile wie ein verbessertes Erscheinungsbild mit sich, bringt aber auch Verantwortung mit sich.
EDIT : haftungsausschluss. Der DatePickerDialog-Konstruktor, der verschiedene Themes basierend auf der aktuellen targetSDK-Version einstellt (die ich oben gezeigt habe), wurde tatsächlich geändert in später begehen . Dennoch habe ich dieses Beispiel verwendet, da die Logik nicht geändert wurde und dieser Codeausschnitt das Konzept der targetSDK-Version deutlich zeigt.
Für diejenigen, die eine Zusammenfassung wünschen,
android:minSdkVersion
ist die Mindestversion, die Ihre Anwendung unterstützt. Wenn Ihr Gerät eine niedrigere Android-Version hat, wird die Anwendung nicht installiert.
während,
android:targetSdkVersion
ist die API-Ebene, bis zu der Ihre Anwendung laufen soll. Das bedeutet, dass das System Ihres Telefons kein Kompatibilitätsverhalten verwenden muss, um die Vorwärtskompatibilität aufrechtzuerhalten, da Sie bis zu dieser API getestet haben.
Ihre App läuft auch auf höheren Android-Versionen als den angegebenen targetSdkVersion
aber das Android-Kompatibilitätsverhalten wird aktiviert.
Gratisgeschenk -
android:maxSdkVersion
Wenn die API-Version Ihres Geräts höher ist, wird die App nicht installiert. D.h. dies ist die maximale API, bis zu der Sie die Installation Ihrer App erlauben.
D.h. für MinSDK -4, maxSDK - 8, targetSDK - 8 Meine App wird auf mindestens 1.6 funktionieren, aber ich habe auch Funktionen verwendet, die nur in 2.2 unterstützt werden, die sichtbar sein werden, wenn sie auf einem 2.2-Gerät installiert wird. Auch für maxSDK - 8, wird diese App nicht auf Handys mit API > 8 installieren.
Zum Zeitpunkt des Verfassens dieser Antwort war die Android-Dokumentation nicht sehr aussagekräftig. Jetzt ist es sehr gut erklärt. Prüfen Sie es hier
Wenn Sie zum Beispiel Kompilierfehler erhalten:
<uses-sdk
android:minSdkVersion="10"
android:targetSdkVersion="15" />
.
private void methodThatRequiresAPI11() {
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Config.ARGB_8888; // API Level 1
options.inSampleSize = 8; // API Level 1
options.inBitmap = bitmap; // **API Level 11**
//...
}
Sie erhalten einen Kompilierfehler:
Das Feld erfordert API-Level 11 (derzeit mindestens 10): Android.graphics.BitmapFactory$Options#inBitmap
Seit Version 17 der Android Development Tools (ADT) gibt es eine neue und sehr nützliche Annotation @TargetApi
die dies sehr leicht beheben können. Fügen Sie sie vor der Methode ein, die die problematische Deklaration umschließt:
@TargetApi
private void methodThatRequiresAPI11() {
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Config.ARGB_8888; // API Level 1
options.inSampleSize = 8; // API Level 1
// This will avoid exception NoSuchFieldError (or NoSuchMethodError) at runtime.
if (Integer.valueOf(android.os.Build.VERSION.SDK) >= android.os.Build.VERSION_CODES.HONEYCOMB) {
options.inBitmap = bitmap; // **API Level 11**
//...
}
}
Keine Kompilierfehler mehr und es wird laufen!
EDIT: Dies führt zu einem Laufzeitfehler auf API-Level unter 11. Auf 11 oder höher wird es ohne Probleme laufen. Sie müssen also sicher sein, dass Sie diese Methode auf einem Ausführungspfad aufrufen, der von der Versionskontrolle überwacht wird. TargetApi erlaubt Ihnen nur die Kompilierung, aber Sie führen sie auf eigenes Risiko aus.
- See previous answers
- Weitere Antworten anzeigen