Wersja min. Zestawu SDK systemu Android a docelowa wersja zestawu SDK

Jeśli chodzi o tworzenie aplikacji dla Androida, jaka jest różnica między wersją Min i docelową wersją SDK? Eclipse nie pozwoli mi utworzyć nowego projektu, chyba że wersje Min i Target są takie same!

Android: minSdkVersion

Liczba całkowita określająca minimalny poziom API wymagany do uruchomienia aplikacji. System Android uniemożliwi użytkownikowi instalację aplikacji, jeśli poziom interfejsu API systemu jest niższy niż wartość określona w tym atrybucie. Zawsze powinieneś zadeklarować ten atrybut.

android: targetSdkVersion

Liczba całkowita określająca poziom interfejsu API, na który jest kierowana aplikacja.

Dzięki temu zestawowi atrybutów aplikacja mówi, że jest w stanie działać na starszych wersjach (do minSdkVersion), ale została wyraźnie przetestowana do pracy z podaną tutaj wersją. Określenie tej wersji docelowej pozwala platformie na wyłączenie ustawień zgodności, które nie są wymagane dla wersji docelowej (które w przeciwnym razie mogłyby zostać włączone w celu zachowania zgodności z poprzednimi wersjami) lub umożliwić nowsze funkcje, które nie są dostępne dla starszych aplikacji. Nie oznacza to, że możesz zaprogramować różne funkcje dla różnych wersji platformy - po prostu informuje platformę, że przetestowałeś wersję docelową, i platforma nie powinna wykonywać żadnych dodatkowych prac w celu zachowania zgodności z wersją docelową.

Aby uzyskać więcej informacji, zapoznaj się z tym adresem URL:

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

Komentarz wysłany przez OP do pytania (w zasadzie stwierdzający, że targetSDK nie wpływa na kompilację aplikacji) jest całkowicie błędny! Przepraszam, że jestem tępy.

Krótko mówiąc, tutaj jest cel zadeklarowania innego targetSDK niż minSDK: Oznacza to, że używasz funkcji z SDK wyższego poziomu niż minimum, ale masz zapewnioną kompatybilność wsteczną . Innymi słowy, wyobraź sobie, że chcesz użyć funkcji, która została niedawno wprowadzona, ale nie jest to krytyczne dla twojej aplikacji. Następnie ustaw targetSDK na wersję, w której ta nowa funkcja została wprowadzona, a minimum na coś niższego, aby wszyscy mogli nadal korzystać z Twojej aplikacji.

Dla przykładu: załóżmy, że piszesz aplikację, która szeroko wykorzystuje wykrywanie gestów. Jednak każde polecenie, które można rozpoznać po geście, można również wykonać za pomocą przycisku lub z menu. W tym przypadku gesty są „fajnym dodatkiem”, ale nie są wymagane. Dlatego ustawiłeś docelowy sdk na 7 („Eclair”, kiedy wprowadzono bibliotekę GestureDetection), a minimalny SDK na poziom 3 („Cupcake”), aby nawet osoby posiadające naprawdę stare telefony mogły korzystać z Twojej aplikacji. Wszystko, co musisz zrobić, to upewnić się, że aplikacja sprawdziła wersję Androida, na której była uruchomiona, przed próbą użycia biblioteki gestów, aby uniknąć próby jej użycia, jeśli nie istnieje. (Wprawdzie jest to przestarzały przykład, ponieważ prawie nikt nadal nie ma telefonu w wersji 1.5, ale był czas, gdy zachowano zgodność z wersją v1.

Aby dać inny przykład, możesz użyć tego, jeśli chcesz użyć funkcji z piernika lub plastra miodu. Niektóre osoby wkrótce otrzymają aktualizacje, ale wiele innych, szczególnie ze starszym sprzętem, może utknąć w Eclair, dopóki nie kupią nowego urządzenia. Pozwoliłoby to korzystać z niektórych nowych fajnych funkcji, ale bez wykluczania części potencjalnego rynku.

Na blogu programisty Androida jest bardzo dobry artykuł na temat korzystania z tej funkcji, a w szczególności na temat projektowania kodu „sprawdź, czy funkcja istnieje przed użyciem”, o którym wspomniałem powyżej.

Do OP: Napisałem to głównie na korzyść każdego, kto natknie się na to pytanie w przyszłości, ponieważ zdaję sobie sprawę, że twoje pytanie zostało zadane dawno temu.

Po ustawieniu targetSdkVersion = "xx" poświadczasz, że Twoja aplikacja działa poprawnie (np. Została dokładnie i pomyślnie przetestowana) na poziomie interfejsu API xx.

Wersja Androida działająca na poziomie API wyższym niż xx automatycznie zastosuje kod zgodności w celu obsługi wszelkich funkcji, na których możesz polegać, które były dostępne na poziomie API xx lub wcześniej, ale które są teraz przestarzałe na wyższym poziomie tej wersji Androida.

I odwrotnie, jeśli używasz żadnych funkcji, które stały się przestarzałe na poziomie xx lub wcześniejszym , kod zgodności nie będzie automatycznie stosowany przez wersje systemu operacyjnego na wyższych poziomach API (które nie zawierają już tych funkcji) do obsługi tych zastosowań. W takiej sytuacji Twój własny kod musi zawierać specjalne klauzule przypadków, które testują poziom API, a jeśli wykryty poziom systemu operacyjnego jest wyższy, który nie ma już danej funkcji API, twój kod musi używać alternatywnych funkcji, które są dostępne w uruchomionym systemie operacyjnym Poziom API.

Jeśli tego nie zrobi, niektóre funkcje interfejsu mogą po prostu nie pojawiać się, które normalnie wywoływałyby zdarzenia w kodzie, i może brakować krytycznej funkcji interfejsu, którą użytkownik musi uruchomić te zdarzenia i uzyskać dostęp do ich funkcjonalności (jak w przykład poniżej).

Jak stwierdzono w innych odpowiedziach, możesz ustawić targetSdkVersion na wyższy niż minSdkVersion, jeśli chcesz korzystać z niektórych funkcji API początkowo zdefiniowanych na wyższych poziomach API niż minSdkVersion, i podjąłeś kroki, aby Twój kod mógł wykryć i poradzić sobie z brakiem tych funkcji na niższe poziomy niż targetSdkVersion.

Aby ostrzec programistów przed konkretnym testowaniem minimalnego poziomu interfejsu API wymaganego do korzystania z funkcji, kompilator wygeneruje błąd (nie tylko ostrzeżenie), jeśli kod zawiera wywołanie dowolnej metody zdefiniowanej na późniejszym poziomie interfejsu API niż minSdkVersion, nawet jeśli targetSdkVersion jest większy lub równy poziomowi API, na którym ta metoda została po raz pierwszy udostępniona. Aby usunąć ten błąd, dyrektywa kompilatora

@TargetApi(nn)

informuje kompilator, że kod objęty zakresem tej dyrektywy (który będzie poprzedzał metodę lub klasę) został napisany w celu przetestowania poziomu API co najmniej nn przed wywołaniem dowolnej metody zależnej od posiadania co najmniej tego poziomu API . Na przykład poniższy kod definiuje metodę, którą można wywołać z kodu w aplikacji, która ma minSdkVersion mniejszą niż 11 i targetSdkVersion 11 lub wyższą:

@TargetApi(11)
    public void refreshActionBarIfApi11OrHigher() {
      //If the API is 11 or higher, set up the actionBar and display it
      if(Build.VERSION.SDK_INT >= 11) {
        //ActionBar only exists at API level 11 or higher
        ActionBar actionBar = getActionBar();

        //This should cause onPrepareOptionsMenu() to be called.
        // In versions of the API prior to 11, this only occurred when the user pressed 
        // the dedicated menu button, but at level 11 and above, the action bar is 
        // typically displayed continuously and so you will need to call this
        // each time the options on your menu change.
        invalidateOptionsMenu();

        //Show the bar
        actionBar.show();
    }
}

Możesz również zadeklarować wyższy celSdkVersion, jeśli testowałeś na tym wyższym poziomie i wszystko działało, nawet jeśli nie korzystałeś z żadnych funkcji z poziomu API wyższego niż minSdkVersion. Byłoby to po prostu, aby uniknąć narzutu związanego z dostępem do kodu zgodności, który ma zostać dostosowany z poziomu docelowego do poziomu minimalnego, ponieważ potwierdziłbyś (poprzez testowanie), że taka adaptacja nie była wymagana.

Przykładem funkcji interfejsu użytkownika, która zależy od zadeklarowanego targetSdkVersion, jest przycisk menu z trzema pionowymi kropkami, który pojawia się na pasku stanu aplikacji mających wartość docelową SDKVersion mniejszą niż 11, gdy aplikacje te działają pod API 11 i wyższym. Jeśli twoja aplikacja ma docelową wersję 10 lub mniej, zakłada się, że interfejs aplikacji zależy od istnienia dedykowanego przycisku menu, więc przycisk z trzema kropkami wydaje się zastępować wcześniejsze dedykowane wersje sprzętowe i / lub ekranowe tego przycisku (np. jak widać w Gingerbread), gdy system operacyjny ma wyższy poziom API, dla którego nie jest już zakładany dedykowany przycisk menu na urządzeniu. Jeśli jednak ustawisz docelową wersję aplikacji na 11 lub wyższą, zakłada się, że skorzystałeś z funkcji wprowadzonych na tym poziomie, które zastępują dedykowany przycisk menu (np. g., pasek akcji) lub że w inny sposób ominąłeś potrzebę posiadania przycisku menu systemowego; w konsekwencji „przycisk zgodności” z trzema pionowymi kropkami znika. W takim przypadku, jeśli użytkownik nie może znaleźć przycisku menu, nie może go nacisnąć, a to z kolei oznacza, że ​​zastąpienie onCreateOptionsMenu (menu) Twojej aktywności może nigdy nie zostać wywołane, co z kolei oznacza, że znaczna część funkcjonalności aplikacji może zostać pozbawiona interfejsu użytkownika. O ile oczywiście nie zaimplementowałeś paska akcji lub innych alternatywnych sposobów uzyskiwania dostępu do tych funkcji przez użytkownika. Aby znaleźć przycisk menu, nie może go nacisnąć, a to z kolei oznacza, że ​​przesłonięcie Twojej aktywności onCreateOptionsMenu (menu) może nigdy nie zostać wywołane, co z kolei oznacza, że ​​znaczna część funkcjonalności aplikacji może być pozbawiony interfejsu użytkownika. O ile oczywiście nie zaimplementowałeś paska akcji lub innych alternatywnych sposobów uzyskiwania dostępu do tych funkcji przez użytkownika. Aby znaleźć przycisk menu, nie może go nacisnąć, a to z kolei oznacza, że ​​przesłonięcie Twojej aktywności onCreateOptionsMenu (menu) może nigdy nie zostać wywołane, co z kolei oznacza, że ​​znaczna część funkcjonalności aplikacji może być pozbawiony interfejsu użytkownika. O ile oczywiście nie zaimplementowałeś paska akcji lub innych alternatywnych sposobów uzyskiwania dostępu do tych funkcji przez użytkownika.

Natomiast minSdkVersion określa wymóg, aby wersja systemu operacyjnego urządzenia miała co najmniej ten poziom interfejsu API w celu uruchomienia aplikacji. Wpływa to na to, które urządzenia mogą wyświetlać i pobierać aplikację, gdy jest ona dostępna w sklepie z aplikacjami Google Play (i ewentualnie także w innych sklepach z aplikacjami). Jest to sposób na stwierdzenie, że twoja aplikacja opiera się na funkcjach systemu operacyjnego (API lub innych), które zostały ustanowione na tym poziomie, i nie ma akceptowalnego sposobu radzenia sobie z brakiem tych funkcji.

Przykładem użycia minSdkVersion w celu zapewnienia obecności funkcji niezwiązanej z API byłoby ustawienie minSdkVersion na 8 w celu zapewnienia, że ​​Twoja aplikacja będzie działała tylko w wersji interpretera Dalvik z obsługą JIT (od czasu wprowadzenia JIT do interpretera Androida na poziomie API 8). Ponieważ wydajność interpretera obsługującego JIT może być nawet pięciokrotnie wyższa niż w przypadku tej funkcji, jeśli aplikacja intensywnie wykorzystuje procesor, możesz chcieć wymagać interfejsu API w wersji 8 lub wyższej, aby zapewnić odpowiednią wydajność.

Zawsze można lepiej dostarczyć koncepcję z przykładami . Miałem problem ze zrozumieniem tej koncepcji, dopóki nie zagłębiłem się w kod źródłowy frameworku Androida i nie przeprowadziłem eksperymentów, nawet po przeczytaniu wszystkich dokumentów w witrynach deweloperów Androida i powiązanych wątków przepływu stosu. Podzielę się dwoma przykładami, które bardzo mi pomogły w pełni zrozumieć te pojęcia.

DatePickerDialog będzie wyglądać inaczej w zależności od poziomu, który można umieścić w targetSDKversion AndroidManifest.xml pliku, ( <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>). Jeśli ustawisz wartość 10 lub niższą, Twój DatePickerDialog będzie wyglądał jak w lewo. Z drugiej strony, jeśli ustawisz wartość 11 lub wyższą, DatePickerDialog będzie wyglądał dobrze, z tym samym kodem .

Kod, którego użyłem do utworzenia tego przykładu, jest bardzo prosty. MainActivity.javawygląda:

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();       
    }
}

I activity_main.xmlwygląda:

<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>

Otóż ​​to. To naprawdę każdy kod, którego potrzebuję, aby to przetestować.

Ta zmiana wyglądu jest krystalicznie czysta, gdy zobaczysz kod źródłowy platformy Android . To wygląda tak:

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);
}

Jak widać, środowisko pobiera bieżący targetSDKversion i ustawia inny motyw. Ten rodzaj kodu snippet ( getApplicationInfo().targetSdkVersion >= SOME_VERSION) można znaleźć tu i tam w systemie Android.

Kolejny przykład dotyczy klasy WebView . Metody publiczne klasy Webview powinny być wywoływane w głównym wątku, a jeśli nie, system wykonawczy rzuca a RuntimeException, gdy ustawisz docelową SDKversion 18 lub wyższą. To zachowanie można wyraźnie dostarczyć za pomocą kodu źródłowego . Jest tak napisane.

sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >=
            Build.VERSION_CODES.JELLY_BEAN_MR2;

if (sEnforceThreadChecking) {
    throw new RuntimeException(throwable);
}

Dokument na Androida mówi: „ Ponieważ Android ewoluuje z każdą nową wersją, niektóre zachowania, a nawet wygląd mogą się zmienić ”. Sprawdziliśmy więc zmianę zachowania i wyglądu oraz sposób, w jaki ta zmiana została osiągnięta.

Podsumowując, dokument na Androida mówi: „ Ten atrybut (targetSdkVersion) informuje system, który testowałeś w stosunku do wersji docelowej, i system nie powinien włączać żadnych zachowań kompatybilności w celu utrzymania zgodności aplikacji z wersją docelową ”. Jest to naprawdę jasne w przypadku WebView. Było OK, dopóki JELLY_BEAN_MR2 nie został wydany, aby wywołać metodę publiczną klasy WebView w nie głównym wątku. To nonsens, jeśli system Android zgłasza wyjątek RuntimeException na urządzeniach JELLY_BEAN_MR2. Po prostu nie powinno to umożliwiać nowo wprowadzonych zachowań ze względu na ich zainteresowanie, które powodują fatalne skutki. Musimy więc sprawdzić, czy wszystko jest OK na niektórych docelowychSDKversions. Dostajemy korzyści takie jak poprawa wyglądu dzięki ustawieniu wyższej wartości docelowej SDKversion,

EDYCJA: wyłączenie odpowiedzialności. Konstruktor DatePickerDialog, który ustawia różne kompozycje w oparciu o bieżący targetSDKversion (który pokazałem powyżej), faktycznie został zmieniony w późniejszym zatwierdzeniu . Niemniej jednak użyłem tego przykładu, ponieważ logika nie została zmieniona, a fragment kodu wyraźnie pokazuje koncepcję targetSDKversion.

Dla tych, którzy chcą podsumowania,

android:minSdkVersion

jest wersją minimalną, dopóki aplikacja nie będzie obsługiwać Jeśli twoje urządzenie ma niższą wersję Androida, aplikacja się nie zainstaluje.

podczas,

android:targetSdkVersion

to poziom interfejsu API, do którego aplikacja ma działać. Oznacza to, że system twojego telefonu nie musi używać żadnych zachowań kompatybilności, aby zachować kompatybilność do przodu, ponieważ testowałeś do tego API.

Twoja aplikacja będzie nadal działać na wersjach Androida wyższych niż podane, targetSdkVersionale rozpocznie się zachowanie kompatybilności z Androidem .

Freebie -

android:maxSdkVersion

jeśli wersja interfejsu API Twojego urządzenia jest wyższa, aplikacja się nie zainstaluje. To znaczy. jest to maksymalny interfejs API, do którego zezwalasz na instalację aplikacji.

to znaczy. dla MinSDK -4, maxSDK - 8, targetSDK - 8 Moja aplikacja będzie działała na minimum 1.6, ale użyłem również funkcji, które są obsługiwane tylko w wersji 2.2, które będą widoczne, jeśli zostaną zainstalowane na urządzeniu 2.2. Ponadto w przypadku wersji maxSDK - 8 ta aplikacja nie będzie instalowana na telefonach z interfejsem API> 8.

W momencie pisania tej odpowiedzi dokumentacja Androida nie była w stanie jej wyjaśnić. Teraz jest to bardzo dobrze wyjaśnione. Sprawdź tutaj

Jeśli na przykład występują błędy kompilacji:

<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**
        //...
    }

Pojawia się błąd kompilacji:

Pole wymaga interfejsu API na poziomie 11 (bieżąca wartość to 10): android.graphics.BitmapFactory $ Opcje # inBitmap

Od wersji 17 narzędzi programistycznych Android (ADT) istnieje jedna nowa i bardzo przydatna adnotacja, @TargetApiktóra może to bardzo łatwo naprawić. Dodaj go przed metodą, która zawiera problematyczną deklarację:

@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**
            //...
      }
    }

Teraz nie ma błędów kompilacji i będzie działać!

EDYCJA: Spowoduje to błąd w czasie wykonywania na poziomie API niższym niż 11. Na 11 lub wyższym będzie działał bez problemów. Musisz więc mieć pewność, że wywołasz tę metodę na ścieżce wykonania chronionej przez sprawdzanie wersji. TargetApi pozwala tylko na kompilację, ale uruchamiasz go na własne ryzyko.

android:minSdkVersioni android:targetSdkVersionoba są wartościami całkowitymi, które musimy zadeklarować w pliku manifestu Androida, ale oba mają różne właściwości.

android:minSdkVersion:Jest to minimalny wymagany poziom interfejsu API do uruchomienia aplikacji na Androida. Jeśli zainstalujemy tę samą aplikację na niższej wersji API, pojawi się błąd analizatora składni i pojawi się problem z brakiem obsługi aplikacji.

android:targetSdkVersion:Docelowa wersja SDK to ustawienie docelowego poziomu interfejsu API aplikacji. jeśli ten atrybut nie zostanie zadeklarowany w manifeście, wersja minSdk będzie wersją TargetSdk. Jest to zawsze prawdą, że „instalacja obsługi aplikacji na wszystkich wyższych wersjach API zadeklarowaliśmy jako wersję TargetSdk”. Aby aplikacja była ograniczonym celem, musimy zadeklarować maxSdkVersion w naszym pliku manifestu ...

Jeśli tworzysz aplikacje wymagające niebezpiecznych uprawnień i ustaw wartość docelową SDK na 23 lub wyższą , powinieneś zachować ostrożność. Jeśli nie sprawdzisz uprawnień w środowisku wykonawczym, otrzymasz SecurityException, a jeśli używasz kodu wewnątrz bloku próbnego, na przykład otwartej kamery, wykrycie błędu może być trudne, jeśli nie sprawdzisz logcat.

Docelowy sdk to wersja, na którą chcesz kierować, a min sdk to wersja minimalna.