Версия Android Min SDK против целевой версии SDK

комментарий, опубликованный OP к вопросу (в основном заявляя, что targetSDK не влияет на компиляцию приложения), совершенно неверен! К сожалению, чтобы быть тупым.

короче говоря, вот цель объявления другого targetSDK от minSDK: это означает, что вы используете функции из SDK более высокого уровня, чем ваш минимум, но у вас есть обеспечена обратная совместимость. Иными словами, представьте, что вы хотите использовать функцию, которая была только недавно появившаяся, но это не критично для приложения. Затем вы установите targetSDK в версию, где была введена эта новая функция, и минимум на что-то ниже, чтобы все могли использовать ваше приложение.

чтобы привести пример, Предположим, вы пишете приложение, которое широко использует обнаружение жестов. Однако каждая команда, которая может быть распознана жестом, также может быть выполнена кнопкой или из меню. В этом случае жесты - это "классный экстра", но не требуется. Поэтому вы установите целевой sdk на 7 ("Eclair", когда была введена библиотека GestureDetection), а minimumSDK на уровень 3 ("Cupcake"), чтобы даже люди с действительно старыми телефонами могли использовать ваше приложение. Все, что вам нужно сделать, это убедиться, что ваше приложение проверило версию Android, на которой оно работает, прежде чем пытаться использовать библиотеку жестов, чтобы избежать попыток использовать ее, если она не существует. (По общему признанию, это датированный пример, так как вряд ли у кого-то еще есть v1.5 телефон, но было время, когда поддерживалась совместимость с v1.5 было действительно важно.)

чтобы дать другой пример, вы можете использовать это, если хотите использовать функцию из пряников или сот. Некоторые люди скоро получат обновления, но многие другие, особенно со старым оборудованием, могут застрять в Eclair, пока не купят новое устройство. Это позволит вам использовать некоторые из интересных новых функций, но не исключая часть вашего возможного рынка.

есть действительно хорошие статья блог разработчика Android о том, как использовать эту функцию, и, в частности, как создать код "проверить, что функция существует перед ее использованием", о котором я упоминал выше.

ОП: я написал это в основном для тех, кто случайно наткнется на этот вопрос в будущем, поскольку я понимаю, что ваш вопрос был задан давно.

когда вы устанавливаете targetSdkVersion= "xx", вы подтверждаете, что ваше приложение работает правильно (например, было тщательно и успешно протестировано) на уровне API xx.

версия Android работает на уровне API выше xx будет автоматически применять код совместимости для поддержки любых функций, на которые вы можете полагаться, которые были доступны на уровне API xx или до него, но которые теперь устарели на более высоком уровне этой версии Android.

и наоборот, если вы используйте любые функции, которые устарели at или до до уровня xx, код совместимости будет не автоматически применяться версиями ОС на более высоких уровнях API (которые больше не включают эти функции) для поддержки этих применений. В этом случае ваш собственный код должен иметь специальные предложения case, которые проверяют уровень API, и, если обнаружен более высокий уровень ОС, который больше не имеет данной функции API, код должен использовать альтернативные функции, которые are доступно на уровне API работающей ОС.

Если это не удается сделать, то некоторые функции интерфейса могут просто не отображаться, которые обычно запускают события в вашем коде, и вам может не хватать критической функции интерфейса, которая необходима пользователю для запуска этих событий и доступа к их функциональности (как в примере ниже).

как указано в других ответах, вы можете установить targetSdkVersion выше, чем minSdkVersion, если хотите использовать некоторый API функции, первоначально определенные на более высоких уровнях API, чем ваша minSdkVersion, и предприняли шаги для обеспечения того, чтобы ваш код мог обнаруживать и обрабатывать отсутствие этих функций на более низких уровнях, чем targetSdkVersion.

чтобы предупредить разработчиков специально протестировать минимальный уровень API, необходимый для использования функции, компилятор выдаст ошибку (а не просто предупреждение), если код содержит вызов любого метода, который был определен на более позднем уровне API, чем minSdkVersion, даже если targetSdkVersion больше или равно уровню API, на котором этот метод был впервые доступен. Чтобы удалить эту ошибку, директива компилятора

@TargetApi(nn)

сообщает компилятору, что код в пределах этой директивы (который будет предшествовать либо методу, либо классу) был написан для тестирования уровня API, по крайней мере, nn, до вызова любого метода, который зависит от наличия по крайней мере этого уровня API. Например, следующий код определяет метод, который можно назвать из кода в приложении, которое имеет minSdkVersion менее 11 и targetSdkVersion 11 или выше:

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

Вы можете и хотите объявить более высокую targetSdkVersion, если вы протестировали на этом более высоком уровне, и все сработало, даже если вы были не использование любых функций с уровня API выше, чем ваш minSdkVersion. Это было бы просто, чтобы избежать накладных расходов на доступ к коду совместимости, предназначенных для адаптации от целевого уровня до минимальный уровень, так как вы бы подтвердили (через тестирование), что такая адаптация не требуется.

примером функции пользовательского интерфейса, которая зависит от объявленной targetSdkVersion, будет кнопка меню с тремя вертикальными точками, которая появляется в строке состояния приложений, имеющих targetSdkVersion меньше 11, когда эти приложения работают под API 11 и выше. Если ваше приложение имеет targetSdkVersion 10 или ниже, предполагается, что интерфейс вашего приложения зависит от наличия выделенная кнопка меню, и поэтому кнопка с тремя точками, по-видимому, заменяет более ранние выделенные аппаратные и / или экранные версии этой кнопки (например, как показано в Gingerbread), когда ОС имеет более высокий уровень API, для которого выделенная кнопка меню на устройстве больше не предполагается. Однако, если вы установите targetSdkVersion вашего приложения на 11 или выше, предполагается, что вы воспользовались функциями, представленными на этом уровне, которые заменяют выделенную кнопку меню (например, панель действий), или что вы в противном случае обошли необходимость иметь кнопку системного меню; следовательно, меню "совместимость" с тремя вертикальными точками исчезает. В этом случае, если пользователь не может найти кнопку меню, она не может нажать ее, и это, в свою очередь, означает, что переопределение onCreateOptionsMenu(меню) вашей активности может никогда не вызываться, что, в свою очередь, означает, что значительная часть функциональности вашего приложения может быть лишена его пользовательского интерфейса. Если, конечно, вы не внедрили панель действий или другие альтернативные средства для доступа пользователя к этим функциям.

minSdkVersion, напротив, заявляет требование, чтобы версия ОС устройства имела хотя бы этот уровень API для запуска вашего приложения. Это влияет на то, какие устройства могут видеть и загружать ваше приложение, когда оно находится в Google Play app store (и, возможно, в других магазинах приложений). Это способ заявить, что ваше приложение полагается на ОС (API или другие) функции, которые были установлены на этом уровне, и не имеет приемлемого способа справиться с отсутствием этих функций.

пример использования minSdkVersion для обеспечения наличия функции, которая не API-related будет установить minSdkVersion в 8, чтобы гарантировать, что ваше приложение будет работать только на JIT-версии интерпретатора Dalvik (так как JIT был представлен интерпретатору Android на уровне API 8). Поскольку производительность интерпретатора с поддержкой JIT может быть в пять раз больше, чем у одного в отсутствие этой функции, если ваше приложение интенсивно использует процессор, вам может потребоваться уровень API 8 или выше для обеспечения адекватной производительности.

концепция может быть лучше поставлена с примерами, всегда. У меня были проблемы с пониманием этой концепции, пока я не копаюсь в исходном коде Android framework и не провожу некоторые эксперименты, даже после прочтения всех документов на сайтах разработчиков Android и связанных с ними потоках stackoverflow. Я собираюсь поделиться двумя примерами, которые помогли мне полностью понять эти концепции.

A DatePickerDialog будет выглядеть по-разному в зависимости от уровня, что вы положить в AndroidManifest.targetSDKversion xml-файла (<uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>). Если вы установите значение 10 или ниже, ваш DatePickerDialog будет выглядеть как left. С другой стороны, если вы установите значение 11 или выше, DatePickerDialog будет выглядеть как right,С тем же самым кодом.

код, который я использовал для создания этого образца, очень прост. MainActivity.java выглядит так :

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

и activity_main.xml выглядит :

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

Вот и все. Это действительно каждый код, который мне нужно проверить.

и это изменение во взгляде кристально ясно, когда вы видите исходный код Android framework. Оно идет как :

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

как вы можете видеть, фреймворк получает текущую targetSDKversion и устанавливает другую тему. Такой фрагмент кода(getApplicationInfo().targetSdkVersion >= SOME_VERSION) можно найти здесь и там в рамках Android.

другой пример-о WebView класса. Открытые методы класса Webview должны вызываться в основном потоке, а если нет, система выполнения выдает RuntimeException, когда вы устанавливаете targetSDKversion 18 или выше. Это поведение может быть четко поставлено с исходный код. Просто так написано.

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

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

Android doc говорит:"как Android развивается с каждой новой версией, некоторые поведения и даже внешний вид может изменить."Итак, мы посмотрели, как меняется поведение и внешний вид, и как это изменение достигается.

в резюме, Android doc говорит"этот атрибут(targetSdkVersion) сообщает системе, что вы протестировали на целевой версии и система не должна включать поведение совместимости сохранить совместимость приложений с целевой версией.". Это действительно ясно с делом WebView. Это было нормально, пока JELLY_BEAN_MR2 выпущен для вызова открытого метода класса WebView в Не-основном потоке. Это нонсенс, если Android framework бросает исключение RuntimeException на устройствах JELLY_BEAN_MR2. Он просто не должен позволять вновь вводимым поведениям для своего интереса, которые вызывают фатальный результат. Итак, нам нужно проверить, все ли в порядке на определенных targetSDKversions. Мы получаем преимущество как повышение возникновения с установкой более высокого targetSDKversion, но оно приходит с ответственностью.

изменить : оговорка. Конструктор DatePickerDialog, который устанавливает разные темы на основе текущего targetSDKversion (который я показал выше), фактически был изменен в фиксация. Тем не менее я использовал этот пример, потому что логика не была изменена, и этот фрагмент кода четко показывает концепцию targetSDKversion.

для тех, кто хочет резюме,

android:minSdkVersion

минимальная версия, пока ваше приложение поддерживает. Если ваше устройство имеет более низкую версию Android , приложение не будет установлено.

а,

android:targetSdkVersion

- это уровень API, до которого ваше приложение предназначено для запуска. Значит, системе вашего телефона не нужно использовать поведение совместимости для поддержания прямой совместимости, потому что вы протестировали до этого API.

ваше приложение будет по-прежнему запуск на Android версии выше, чем задано targetSdkVersion но поведение совместимости android будет пинать.

Халява -

android:maxSdkVersion

если версия API вашего устройства выше, приложение не будет установлено. То есть. это max API, до которого вы разрешаете устанавливать свое приложение.

ie. для MinSDK -4, maxSDK-8, targetSDK-8 мое приложение будет работать на минимуме 1.6, но я также использовал функции, которые поддерживаются только в 2.2, которые будут отображается, если он установлен на устройстве 2.2. Кроме того, для maxSDK - 8 это приложение не будет устанавливаться на телефоны с помощью API > 8.

на момент написания этого ответа документация Android не делала большой работы по его объяснению. Теперь это очень хорошо объяснено. регистрация здесь

если вы получаете некоторые ошибки компиляции, например:

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

вы получаете ошибку при компиляции:

поле требует уровня API 11 (текущая минута-10): андроид.графика.BitmapFactory$Options#inBitmap

начиная с версии 17 Android Development Tools (ADT) есть одна новая и очень полезная аннотация @TargetApi это может исправить это очень легко. Добавьте его перед методом, который заключает проблему объявление:

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

нет ошибок компиляции сейчас и он будет работать !

EDIT: это приведет к ошибке выполнения на уровне API ниже 11. На 11 или выше, это будет работать без проблем. Поэтому вы должны быть уверены, что вызываете этот метод по пути выполнения, защищенному проверкой версии. TargetApi просто позволяет скомпилировать его, но вы запускаете его на свой страх и риск.

android:minSdkVersion и android:targetSdkVersion оба являются целочисленным значением, которое нам нужно объявить в файле манифеста android, но оба имеют разные свойства.

android:minSdkVersion: это минимальный необходимый уровень API для запуска приложения для android. Если мы установим одно и то же приложение на более низкую версию API, появится ошибка парсера, и появится проблема с поддержкой приложения.

android:targetSdkVersion: целевая версия sdk должна установить целевой уровень API приложения. если этот атрибут не объявлено в манифесте, версия minSdk будет вашей версией TargetSdk. Это всегда верно ,что "установка поддержки приложений на всех более высоких версиях API мы объявили как TargetSdk версии". Чтобы сделать app limited target, нам нужно объявить maxSdkVersion в нашем файле манифеста...

Target sdk-это версия, которую вы хотите настроить, а min sdk-минимальная.

Если вы делаете приложения require опасные разрешения и установите targetSDK в 23 или выше вы должны быть осторожны. Если вы не проверяете разрешения на время выполнения, вы получите исключение SecurityException, и если вы используете код внутри блока try, например open camera, может быть трудно обнаружить ошибку, если вы не проверяете logcat.