Android build version tags

Русские Блоги

Таблица номеров версий Android-SDK

Предисловие

Поскольку часто бывает необходимо адаптировать версию SDK по-другому, необходимо знать номер версии SDK. Здесь для удобства дальнейшего просмотра запишите его в виде стол. Просто запишите4.0В конце концов, указанная выше версия Android4.0Вышеуказанный уровень проникновения достиг97.4%。

1. Таблица версий SDK

На основе Android 6.0 (уровень API 23)

Дата выхода	API Level	Версия Android	VERSION_CODES	английское имя	китайское имя
2011.10	14	4.0	ICE_CREAM_SANDWICH	IceCreamSandwich	Сэндвич с мороженым
2011.12	15	4.0.3	ICE_CREAM_SANDWICH_MR1	IceCreamSandwich	Сэндвич с мороженым
2012.06	16	4.1	JELLY_BEAN	Jelly Bean	жевательные конфеты
2012.11	17	4.2	JELLY_BEAN_MR1	Jelly Bean	жевательные конфеты
2013.07	18	4.3	JELLY_BEAN_MR2	Jelly Bean	жевательные конфеты
2014.06	19	4.4	KITKAT	KitKat	KitKat Шоколад
2014.09	20	4.4W	KITKAT_WATCH	KitKat Wear	Устройство KitKat для ношения шоколада
2014.11	21	5.0	L или LOLLIPOP	Lollipop	Леденец
2015.03	22	5.1	LOLLIPOP_MR1	Lollipop	Леденец
2015.10	23	6.0	M	Marshmallow	сахарная вата
Не опубликовано	24	6.X	N	Nougat	Нуга

Если вам нужна более подробная версия NDK, см. Здесь:Форма SDK с версией NDK

2. Назначение номера версии SDK

2.1. Получите номер версии

• Зачем нужен номер версии：
  Иногда в опубликованном приложении бывают исключения. Мы перехватываем исключение и должны загрузить номер версии SDK для устройства, которое передает исключение, на сервер, чтобы разработчик мог проанализировать исключение.
• Как получить номер версии выпуска и уровень API

2.2. Адаптировать под номер версии

• Ситуация 1. Система разрешений Android 6.0:

Судите, есть ли разрешение, если версия больше 5.1, ее нужно судить (то есть 6.0 или выше), а другие судить не нужно. Build.VERSION.SDK_INT относится к уровню API текущего устройства.

• Ситуация 2. Некоторые атрибуты уведомления:

Подзаголовок уведомления требует использования API уровня 16.

Источник

Creating Different Build Variants in Android

While developing an Android application, we generally need various types of APKs or you can say different versions of APK during the development and release phase. For example, you may need one debug APK without having proguard or one debug APK with proguard or you may need one APK for your free users and one APK for your paid users or you may need one APK for Android version 6 and above and one APK for Android version below 6 and there are many other possibilities. But the question is, how you are going to create these many versions of your App. Are you going to have different projects for these versions or just one project is enough? Because the code is going to remain almost the same and just some APIs or some build configurations are going to change? So, how to achieve this? This can be achieved by using Build Variants i.e. the topic of this blog.

In this blog, we are going to learn what Build Variants are and how to create different build variants in Android. So, let’s get started.

Build Types and Build Variants

While building any Android application, we create various build types such as «debug» and «release». At the same time, we can create various product flavors for the same app, for example, the free product flavor for free users and the paid product flavor for the paid users. So, Android Studio provides a feature of Build Variants which can be thought of as a cartesian product of all your build types and all your product flavors.

All you need to do is add various build types in your module-level build.gradle file and during development or production, you can simply choose the Build Variant you want to test or release.

NOTE: By default, the Android Studio will generate » debug» and » release» Build Types for your project.

The Build Variant option can be found at the left part of the screen(mostly below Resource Manager)in Android Studio or go to Build > Select Build Variant or you can simply press cmd + shift + A and search for «Build Variant»:

So, to change a Build Type, all you need to do is just select your Build Type from the Build Variant and after the project sync, you are good to go. But how to create a Build Type? Let’s see.

Add Build Types

In this section, we are going to learn how to add various build types in Android.

By default, whenever you create any project, then Android Studio will create two build types for the project i.e. » debug» and » release«. But in order to add more build types, you need to add them to your module-level build.gradle file and under the buildTypes block. The following is an example of the same:

In the above code, there are three build types i.e. debug, release, and minifiedDebug. The debug and release are the same generated by Android Studio with some additional properties and minifiedDebug is the new build type that is a combination of debug + proguard.

If you closely look at the code, then you will find that in the defaultConfig block, the version name is «0.0.3» and in the debug and minifedDebug build type, we are adding a «.dev» suffix to the version name. This will differentiate the dev APK from the prod APK.

Similarly, you can create the build type named noMinifedRelease that will be a combination of release + without proguard.

There are certain cases where you want to use the same properties of some of your previous build types and add or modify some properties to create a new build type. So, to do so you can use initWith :

The above is the code of a new build type name newBuildType. Since we are using initWith debug , so it will contain all the properties of debug and you can add more properties to it or you can also edit some of the properties of debug and keep other things as it is. In our case, we are editing the versionNameSuffix and setting it with » .newbuild» instead of » .dev» that is there in the debug.

Now, if you open the Build Variants option in the Android Studio, then you will find 4 build variants i.e. debug, release, minifiedDebug, and newBuildType. You can choose any of these for your build.

NOTE: If you are using Kotlin DSL in your build.gradle file, then to add a build type, you need to use create(«yourBuildTypeName») method in buildTypes block.

Adding Product Flavors

You can think of Product Flavors as different variants of your app. i.e. if you are providing different content to different users but using the same code base, then you can add product flavors to your app.

For example, you can add product flavors such as » development» and » production«, Inside these flavors you can add different API keys for the same working flow. For example, you can add the development API in the development flavor and production API in the production flavor.

To add a product flavor you need to add the productFlavors block inside the android block and each product flavor must have some flavor dimension:

The best part of product flavors is that they are associated with build types. For example, if you have two build types named «debug» and «release» and two product flavors named «development» and «production», then your build variants will be:

• developmentDebug
• developmentRelease
• productionDebug
• productionRelease

Now, you can select any of the build variants you want for your build.

You can create as many product flavor dimensions as you want by separating each dimension from others by using a comma( , ) and use it by using dimension «dimensionName» . For example:

So, this is how you can create a product flavor and use it in your app for making various versions.

That’s it for this blog.

If you want to learn about build variants by watching from video, you can watch our video from MindOrks YouTube channel .

Источник

Android build version tags

В статье приведен перевод статей [1, 2], посвященных управлению версиями приложения Android, и работе приложения на разных версиях операционной системы Android. Все непонятные термины и сокращения ищите в Словарике [3].

Управление версией приложения является критически важным аспектом для обновления приложения и для стратегии его поддержки в будущем. Это важно потому что:

• Пользователям нужна соответствующая информация о версии приложения, которая установлена на их устройствах, и о доступности обновлений версии приложения для существующей инсталляции.
• Другие приложения — включая другие приложения, которые Вы публикуете в как комплект приложений — нуждаются в опросе системы для версии Вашего приложения, чтобы определить совместимость и идентифицировать зависимости (от API и библиотек).
• Сервисы, через которые Вы публикуете приложение (или приложения) могут также нуждаться в опросе Вашего приложения на его версию, чтобы можно было отобразить эту версию для пользователей. Сервис публикации может также нуждаться в проверки версии приложения, чтобы определить совместимость и установить взаимосвязи для апгрейда или довнгрейда.

Система Android не использует информацию об версии приложения для принудительного ограничения на апгрейд, довнгрейд, или на ограничение совместимости приложений сторонних производителей. Вместо этого Вы (как разработчик) отвечаете за ограничения, связанные с версиями приложения, или за информирование об этом пользователей. Однако система Android обеспечивает совместимость приложения с системой в соответствии с атрибутом minSdkVersion, который указан в манифесте. Этот атрибут позволяет приложению указать минимальный уровень системного API, с которым совместимо приложение. Дополнительную информацию см. ниже android:minSdkVersion в разделе «Как указать требования приложения к уровню (версии) API Android».

[Установка версии приложения (Application Version)]

Чтобы задать информацию о версии для Вашего приложения, нужно установить атрибуты в файле манифеста приложения (AndroidManifest.xml, секция manifest). Доступно 2 атрибута, для которых обязательно нужно назначить значения:

• android:versionCode — целое число, которое представляет версию кода приложения относительно других версий. Значение целого числа установлено так, чтобы другие приложения могли программно вычислить его, например для проверки взаимосвязи апгрейда или довнгрейда. Вы можете установить значение в любое целое число, какое захотите, однако нужно помнить, что обновленное приложение должно иметь последовательно увеличенный номер версии. Система не принуждает к такому поведению, однако увеличение номера версии с новым релизом является нормой.

Обычно Вы должны сделать первый релиз приложения с versionCode установленным в 1, и затем монотонно увеличивать это значение с каждым новым релизом, независимо от статуса, который имеет релиз: major или minor. Это не означает, что значение атрибута android:versionCode должно быть строго подобно версии релиза, которую видит пользователь (см. далее атрибут android:versionName). Приложения и сервисы публикации приложений не должны отображать значение атрибута android:versionCode для пользователей.

• android:versionName — строковое значение, которое представляет версию релиза кода приложения, которая должна быть показана пользователям.

Значение является строкой, в которой Вы можете описать версию приложения как . . , или любым другим способом, выражая текстовым идентификатором абсолютную или относительную версию приложения.

Как и атрибут android:versionCode, система Android не использует android:versionName для внутреннего использования, кроме того как отобразить это значение для пользователей. Сервисы публикации приложений могут также прочитать значение android:versionName для того, чтобы отобразить её для пользователей.

Оба этих элемента нужно задать в секции файла манифеста приложения. Пример:

Обратите внимание, что в этом примере android:versionCode показывает, что текущий файл .apk содержит второй релиз кода приложения, который соответствует минорной последующей версии релиза 1, как показано в строке android:versionName.

Рабочее окружение Android предоставляет API, позволяющее приложениям опросить систему для получения информации версии приложения. Чтобы получить информацию версии, приложения используют метод getPackageInfo(java.lang.String, int) объекта PackageManager.

[Как указать требования приложения к уровню (версии) API Android]

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

Чтобы указать требования к API Level, добавьте тег в файл манифеста приложения, и укажите в нем один или несколько этих атрибутов:

• android:minSdkVersion — минимальное значение версии платформы Android, на которой приложение будет работать. Значение версии указано в виде цифрового идентификатора API Level.
• android:targetSdkVersion — указывает число API Level, для которого приложение разработано. В некоторых случаях это позволит приложению использовать элементы манифеста и определять поведение по заданному уровню целевого API Level, вместо того, чтобы ограничиваться использованием только определенного минимального уровня API Level.
• android:maxSdkVersion — максимальное значение версии платформы Android, на котором приложение может работать. Внимательно прочтите документацию по секции (см. далее) перед использованием этого атрибута.

При подготовке к установке приложения система проверяет эти атрибуты и сравнивает их с версией системы. Если значение android:minSdkVersion больше версии системы, то установка приложения будет прервана. Точно также система установить Ваше приложение только в том случае, если android:maxSdkVersion совместим с версией платформы.

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

Чтобы указать минимальную требуемую версию платформы для Вашего приложения, добавьте секцию дочерней к секции , и затем добавьте атрибут android:minSdkVersion и его значение.

[Подробнее о секции манифеста ]

Секция uses-sdk появилась начиная с API Level 1 (т. е. сразу, начиная с самых старых версий Android). Синтаксис секции следующий:

Секция uses-sdk позволяет Вам выражать совместимость приложения Android с одной или большим количеством версий платформ (операционных систем) Android. Эта совместимость определяется посредством чисел API Level, которая указывается в атрибутах секции minSdkVersion, targetSdkVersion, maxSdkVersion. Версия платформы может (которая соответствует определенному числу API Level) может различаться на разных устройствах Android. Указанные API Level, представленные приложением в этой секции, сравниваются с API Level системы, на которой работает (или устанавливается) приложение, и на основе этого сравнения принимаются определенные решения по инсталляции программы или её работе.

Несмотря на имя секции uses-sdk, эта секция на самом деле используется для определения API Level, но не номер версии SDK платформы Android. API Level всегда задается одиночным целым числом. Вы не можете получить из связанной с ним текстовой версии Android, кроме как получить такое соответствие из таблицы API Level (см. [4]). К примеру, API level 16 относится к версиям Android 4.1, Android 4.1.1, Android 4.1.2. Теперь рассмотрим назначение атрибутов minSdkVersion, targetSdkVersion, maxSdkVersion.

android:minSdkVersion число, обозначающее минимальный API Level, который требуется для установки, запуска и работы приложения. Система Android не позволит пользователю установить приложение, если API Level системы меньше значения, указанного в этом атрибуте. Вы всегда должны указывать этот атрибут в секции uses-sdk файла AndroidManifest.xml.

Предостережение: если Вы не укажете этот атрибут, то система предположит его значение по умолчанию «1», что означает совместимость Вашего приложения со всеми без исключения версиями операционной системы Android. Если Ваше приложение несовместимо со всеми версиями (например, оно использует API, представленное впервые на API Level 3), и Вы не укажете правильно minSdkVersion, то при установке на систему с уровнем API Level меньше 3 приложение будет завершаться с ошибкой при попытке доступа к недоступному API. По этой причине обязательно объявляйте подходящий API Level в атрибуте minSdkVersion.

android:targetSdkVersion этот атрибут представлен начиная с API Level 4. Это целое число, обозначающее API Level, для которого приложение предназначено (target, что означает цель). Если этот атрибут не установлен, то его значение по умолчанию равно minSdkVersion.

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

Поскольку Android развивается с каждой новой версией, то некоторые поведения и даже внешний вид приложения может измениться. Однако, если API level платформы выше, чем версия, указанная в targetSdkVersion приложения, система может включить обработки совместимости (compatibility behaviors), чтобы обеспечить работоспособность Вашего приложения так, как Вы этого ожидали. Вы можете запретить такие обработки совместимости, если укажете targetSdkVersion равным API level платформы Android, на которой приложение работает. Например, установка этого значения в «11» или более высокое значение позволит системе установить новую тему оформления по умолчанию (Holo) для Вашего приложения при работе на Android 3.0 или более новой, и также запретит режим совместимости экрана, когда программа будет работать на больших экранах (потому что поддержка API level 11 неявно подразумевает поддержку больших экранов).

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

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

android:maxSdkVersion этот атрибут представлен начиная с API Level 4. Это целое число, обозначающее максимальный API Level, на котором приложение может работать.

На версиях Android 1.5, 1.6, 2.0 и 2.0.1 система проверяет значение этого атрибута, когда инсталлируется приложение, и когда приложение проверяется на совместимость после обновления системы. В любом случае, если атрибут приложения maxSdkVersion меньше API Level системы, то установка приложения будет запрещена. При проверке приложения на совместимость после обновления системы такой случай соответствует полному удалению приложения с устройства. Для иллюстрации того, как этот атрибут может повлиять на приложение после обновления системы, рассмотрим пример.

Приложение декларировало maxSdkVersion=»5″ в своем манифесте, и было опубликовано на Google Play. Пользователь устройства Android 1.6 (API Level 4) загрузил и установил это приложение. После нескольких недель пользователь принял сообщение от системы over-the-air с предложением обновить систему до уровня Android 2.0 (API Level 5). После установки этого обновления система проверила атрибут приложения maxSdkVersion, и разрешила дальнейшее использование этого приложения. Приложение после этого работало нормально. Однако через некоторое время устройство приняло другое обновление системы Android 2.0.1 (API Level 6). После обновления система не разрешает работу приложения, так как API Level системы (6) теперь выше, чем максимальный уровень, который может поддержать приложение (5). Система делает приложение невидимым для пользователя, и удаляет его из устройства.

Предупреждение: использование этого атрибута не рекомендуется. Во-первых, нет никакой потребности установить этот атрибут как средство блокирования развертывания Вашего приложения на новые версии платформы Android по мере их появления. Для Android декларируется полная обратная совместимость старых приложений для новых версий Android. Ваше приложение должно работать должным образом на всех новых версиях, если оно использует только стандартное API и следует лучшим правилам и практикам разработки. Во-вторых нужно помнить, что применение этого атрибута приведет к автоматическому удалению Вашего приложения с устройств пользователя, которые обновят свою систему на более высокий API Level, чем указано в атрибуте. Большинство устройств, на которых вероятно будет установлено Ваше приложение, получают периодические обновления системы на лету, по воздуху (over the air), так что Вы должны учитывать этот эффект перед тем, как установить этот атрибут для своего приложения.

Будущие версии Android (вне Android 2.0.1) больше не будут проверять maxSdkVersion и принудительно применять его значение при установке или проверке совместимости приложения. Однако Google Play продолжит использовать этот атрибут как фильтр при предоставлении приложений, доступных для закачки пользователям.

[Пример установки версии приложения при создании проекта в Eclipse]

В Eclipse при создании проекта запускается мастер, который на первом экране позволяет настроить параметры, касающиеся версии приложения.

Поле Minimum Required SDK определяет значение атрибута android:minSdkVersion будущего приложения. Здесь желательно указать версию достаточно популярной платформы, которая возможно уже несколько устарела.

Поле Target SDK задает атрибут android:targetSdkVersion. Укажите здесь версию системы, с которой Вы тестировали Ваше приложение. К примеру, Вы отлаживаете программу на версии Android 4.1.2, тогда в выпадающем списке Target SDK нужно выбрать API 16: Android 4.1 (Jelly Bean).

Поле Compile With задает версию SDK, на котором Ваше приложение будет скомпилировано. Задайте здесь максимальную (самую свежую) на текущий момент версию системы Android.

Источник