Уровень Android API, обратная и прямая совместимость
Добрый вечер, друзья. Мы подготовили полезный перевод для будущих студентов курса «Android-разработчик. Продвинутый курс». С радостью делимся с вами данным материалом.
Если вы читаете эту статью, значит вас могут интересовать такие вещи, как:
Все эти понятия связаны друг с другом, и я постараюсь объяснить их вам в этой статье простым, но эффективным способом.
Для этого необходимо понимать разницу между SDK и API и знать что такое уровень API в экосистеме Android.
Это правда, что в Android между SDK и API существует отношение 1:1, и часто эти два термина используются как синонимы, но важно понимать, что это не одно и то же.
Правильнее говорить, что для каждой версии Android есть SDK и эквивалентный API, а также уровень этого API.
Расшифровывается как Software Development Kit (комплект для разработки программного обеспечения). Обратите внимание на слово «kit» (комплект)… он как раз представляет из себя набор различных инструментов, библиотек, документации, примеров, помогающих разработчикам создавать, отлаживать и запускать приложения для Android. API предоставляется вместе с SDK.
Если открыть SDK Manager в Android Studio, можно будет яснее увидеть, из чего состоит Android SDK.
На первой вкладке SDK Platform перечислены SDK каждой версии Android.
Как показано на рисунке ниже, Android 9.0 SDK (также известный как Pie) содержит:
На второй вкладке SDK Tools показаны другие инструменты, которые также являются частью SDK, но не зависят от версии платформы. Это означает, что они могут быть выпущены или обновлены отдельно.
Расшифровывается как Application Programming Interface (программный интерфейс приложения). Это просто интерфейс, уровень абстракции, который обеспечивает связь между двумя разными «частями» программного обеспечения. Он работает как договор между поставщиком (например, библиотекой) и потребителем (например, приложением).
Это набор формальных определений, таких как классы, методы, функции, модули, константы, которые могут использоваться другими разработчиками для написания своего кода. При этом API не включает в себя реализацию.
Уровень API
Уровень API — это целочисленное значение, однозначно идентифицирующее версию API фреймворка, предлагаемую платформой Android.
Обычно обновления API фреймворка платформы разрабатываются таким образом, чтобы новая версия API оставалась совместимой с более ранними версиями, поэтому большинство изменений в новом API являются аддитивными, а старые части API становятся устаревшими, но не удаляются.
И теперь кто-то может задаться вопросом…
если API Android не предоставляет реализацию, а SDK Manager предлагает необязательный загружаемый исходный код API в составе SDK, то где находится соответствующая реализация?
Ответ прост. На устройстве.
Давайте разберемся с этим…
От исходного кода к APK-файлу
Как правило, проект под Android состоит из кода, написанного разработчиками с использованием Android API (модуль приложения), а также некоторых других библиотек/зависимостей (.jar-файлов, AAR, модулей и т.д.) и ресурсов.
Процесс компиляции преобразует код, написанный на Java или Kotlin, включая зависимости (одна из причин уменьшить ваш код!), в байт-код DEX, а затем сжимает все в файл APK вместе с ресурсами. На данном этапе реализация API не включена в итоговый APK!
Процесс сборки — Android Developers
DEX файлы и Android Runtime
Архитектура Android — Android Developers
Android Runtime — это место, где делается вся грязная работа и где выполняются DEX-файлы. Оно состоит из двух основных компонентов:
Версия API, доступная на этом уровне, соответствует версии платформы Android, на которой запущено приложение.
Например, если на фактическом устройстве установлен Android 9 (Pie), доступны все API до 28 уровня.
compileSdkVersion
Настоятельно рекомендуется выполнить компиляцию с последней версией SDK:
Это же приложение может работать на устройстве с Android 9 Pie (API 28 уровня), поскольку метод API xyz() все еще доступен на API 28 уровня.
minSdkVersion
Это значение обозначает минимальный уровень API, на котором приложение может работать. Это минимальное требование. Если не указан, значением по умолчанию является 1.
Разработчики обязаны установить корректное значение и обеспечить правильную работу приложения до этого уровня API. Это называется обратной совместимостью.
Чтобы обеспечить обратную совместимость, разработчики могут во время выполнения проверять версию платформы и использовать новый API в более новых версиях платформы и старый API в более старых версиях или, в зависимости от случая, использовать некоторые статические библиотеки, которые обеспечивают обратную совместимость.
Также важно упомянуть, что Google Play Store использует это значение, чтобы определить, можно ли установить приложение на определенное устройство, сопоставив версию платформы устройства с minSdkVersion приложения.
Разработчики должны быть очень осторожны при выборе этого значения, поскольку обратная совместимость не гарантируется платформой.
Выбор «правильного» значения для проекта также является бизнес-решением, поскольку оно влияет на то, насколько большой будет аудитория приложения. Посмотрите на распределение платформ.
targetSdkVersion
Это значение указывает уровень API, на котором приложение было разработано.
Иногда могут быть некоторые изменения API в базовой системе, которые могут повлиять на поведение приложения при работе в новой среде выполнения.
Целевой уровень приложения включает поведение среды выполнения, которое зависит от конкретной версии платформы. Если приложение не готово к поддержке этих изменений поведения среды выполнения, оно, вероятно, завершится сбоем.
Простым примером является Runtime Permission, которое было представлено в Android 6 Marshmallow (API 23 уровня).
Приложение может быть скомпилировано с использованием API 23 уровня, но иметь целевым API 22 уровня, если оно еще не готово поддержать новую модель разрешений времени выполнения.
Таким образом, приложение может по-прежнему быть совместимым без включения нового поведения среды выполнения.
В любом случае, как уже упоминалось, Google требует, чтобы приложения удовлетворяли новым требованиям целевого уровня API, поэтому всегда следует иметь высокий приоритет для обновления этого значения.
Теперь соединяя все это вместе, мы видим четкое отношение
minSdkVersion ≤ targetSdkVersion ≤ compileSdkVersion
Имейте в виду, что настоятельно рекомендуется выполнить компиляцию в соответствии с последним уровнем API и стараться использовать targetSdkVersion == compileSdkVersion.
Minimum sdk что это
В статье приведен перевод статей [1, 2], посвященных управлению версиями приложения Android, и работе приложения на разных версиях операционной системы Android. Все непонятные термины и сокращения ищите в Словарике [3].
Управление версией приложения является критически важным аспектом для обновления приложения и для стратегии его поддержки в будущем. Это важно потому что:
Система Android не использует информацию об версии приложения для принудительного ограничения на апгрейд, довнгрейд, или на ограничение совместимости приложений сторонних производителей. Вместо этого Вы (как разработчик) отвечаете за ограничения, связанные с версиями приложения, или за информирование об этом пользователей. Однако система Android обеспечивает совместимость приложения с системой в соответствии с атрибутом minSdkVersion, который указан в манифесте. Этот атрибут позволяет приложению указать минимальный уровень системного API, с которым совместимо приложение. Дополнительную информацию см. ниже android:minSdkVersion в разделе «Как указать требования приложения к уровню (версии) API Android».
[Установка версии приложения (Application Version)]
Чтобы задать информацию о версии для Вашего приложения, нужно установить атрибуты в файле манифеста приложения (AndroidManifest.xml, секция manifest). Доступно 2 атрибута, для которых обязательно нужно назначить значения:
Обычно Вы должны сделать первый релиз приложения с versionCode установленным в 1, и затем монотонно увеличивать это значение с каждым новым релизом, независимо от статуса, который имеет релиз: major или minor. Это не означает, что значение атрибута android:versionCode должно быть строго подобно версии релиза, которую видит пользователь (см. далее атрибут android:versionName). Приложения и сервисы публикации приложений не должны отображать значение атрибута android:versionCode для пользователей.
Как и атрибут android:versionCode, система Android не использует android:versionName для внутреннего использования, кроме того как отобразить это значение для пользователей. Сервисы публикации приложений могут также прочитать значение android:versionName для того, чтобы отобразить её для пользователей.
Оба этих элемента нужно задать в секции файла манифеста приложения. Пример:
Рабочее окружение Android предоставляет API, позволяющее приложениям опросить систему для получения информации версии приложения. Чтобы получить информацию версии, приложения используют метод getPackageInfo(java.lang.String, int) объекта PackageManager.
[Как указать требования приложения к уровню (версии) API Android]
Если Ваше приложение требует определенную минимальную версию платформы Android, где приложение должно работать, или если приложение разработано для поддержки определенного диапазона версий платформ Android, то Вы можете указать эти требования к версиям в виде идентификаторов API Level в файле манифеста приложения. Если сделать так, то это обеспечит то, что Ваше приложение может быть установлено только на устройствах, на которых работает совместимая версия системы Android.
Чтобы указать требования к API Level, добавьте тег в файл манифеста приложения, и укажите в нем один или несколько этих атрибутов:
При подготовке к установке приложения система проверяет эти атрибуты и сравнивает их с версией системы. Если значение android:minSdkVersion больше версии системы, то установка приложения будет прервана. Точно также система установить Ваше приложение только в том случае, если android:maxSdkVersion совместим с версией платформы.
Если Вы не укажете эти атрибуты в манифесте, то система предположит, что Ваше приложение совместимо со всеми версиями платформы, и также нет ограничения на максимальный API Level.
[Подробнее о секции манифеста ]
Секция 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.
Что такое минимум SDK и какой из них я должен выбрать
Во-первых, я очень мало знаю о разработке android, я только начинаю.
Каков минимальный выбор SDK, который вы получаете при создании проекта в android studio? Есть ли недостаток в использовании более старого? И если я следую учебнику, важно ли, чтобы я использовал тот же самый учебник, чтобы я мог следовать ему?
2 ответа
Динамические языки находятся на подъеме, и их очень много: например, Ruby, Groovy, Jython, Scala (статический, но имеет внешний вид динамического языка) и т. д. Мое образование связано с программированием Java SE и EE, и я хочу расширить свои знания на один из этих динамических языков, чтобы лучше.
Сейчас я работаю над приложением Ember CLI. Теперь проверим стратегию реализации аутентификации. Теперь я планирую создать Auth.js, который будет поддерживать состояние входа в систему и может выполнять действия. Например, в Balanced-dashboard они используют Namespace, но Travis-CI поместил его в.
Каков минимальный выбор SDK, который вы получаете при создании проекта в android studio?
Есть ли недостаток в использовании более старого?
И если я следую учебнику, важно ли, чтобы я использовал тот же самый учебник, чтобы я мог следовать ему?
Целое число, обозначающее минимальный уровень API, необходимый для запуска приложения. Система Android не позволит пользователю установить приложение, если уровень API системы ниже значения, указанного в этом атрибуте. Вы всегда должны объявлять этот атрибут.
Вы можете использовать свой собственный min SDK, но будьте осторожны с функциями, которые вы используете. на самом деле, minSDK с большим количеством функций имеют больше возможностей.
Похожие вопросы:
Я новичок в разработке VR, я немного запутался, в чем разница и связь между Cardboard Sdk и Oculus Sdk, если я хочу разработать приложение, которое может воспроизводить 360 VR видео или фотографий.
Во время разработки я опубликовал SDK 21, Lollipop, и я не могу использовать его на своем устройстве KitKat. Приложения очень просты, и я использовал SDK только для анимации и дизайна материалов.
Я новичок в веб-сервисе Amazon. У меня есть задача, которая настраивает, а затем создает веб-службу, предоставляющую APIs клиенту Mac OS, iOS, Android. Есть некоторые APIs, и база данных должна.
Динамические языки находятся на подъеме, и их очень много: например, Ruby, Groovy, Jython, Scala (статический, но имеет внешний вид динамического языка) и т. д. Мое образование связано с.
Сейчас я работаю над приложением Ember CLI. Теперь проверим стратегию реализации аутентификации. Теперь я планирую создать Auth.js, который будет поддерживать состояние входа в систему и может.
На моем компьютере с ОС Windows 7 у меня есть три версии SDK OpenCL от этого производителя: Intel NVIDIA AMD. Я строю свое приложение с каждым из них. В качестве вывода у меня есть три разных.
У меня есть страница PHP с простой формой. Одно входное текстовое поле & кнопка. Текстовое поле ввода принимает запросы пользователя & при нажатии кнопки HTTP делается запрос GET на сервер.
Для программы я работал только с пользовательскими потоками или потоками kernel. Какой из них я должен выбрать?
Мой проект должен поддерживать RTL и пользовательскую карту unity. Поэтому мне нужно решить, правильно ли установить минимум sdk. Я знаю, что 19 покрыто %96.2, но есть %3.8 ниже 19. Итак, какую.
Общие сведения об уровнях API Android
Xamarin. Android имеет несколько параметров уровня API Android, которые определяют совместимость приложения с несколькими версиями Android. В этом руководство объясняется, что означают эти параметры, как их настроить и как они влияют на приложение во время выполнения.
Быстрый запуск
Xamarin. Android предоставляет три параметра проекта уровня API Android:
Целевая платформа — указывает, какая платформа будет использоваться при сборке приложения. Этот уровень API используется на этапе компиляции Xamarin. Android.
Прежде чем можно будет настроить уровень API для проекта, необходимо установить компоненты платформы SDK для этого уровня API. Дополнительные сведения о загрузке и установке компонентов пакет SDK для Android см. в разделе пакет SDK для Android Setup.
Начиная с августа 2021, консоль Google Play требует, чтобы новые приложения были нацелены на уровень API 30 (Android 11,0) или более поздней версии. Существующие приложения должны быть ориентированы на уровень API 30 или выше, начиная с ноября 2021. Дополнительные сведения см. в разделе требования к целевому уровню API для консоли воспроизведения раздела «Создание и настройка приложения» в документации по консоли воспроизведения.
Как правило, для всех трех уровней API Xamarin. Android задано одно и то же значение. На странице приложение задайте для параметра компилировать с помощью версии Android (Целевая платформа) последнюю стабильную версию API (или, как минимум, до версии Android, которая содержит все необходимые компоненты). На следующем снимке экрана для целевой платформы задано значение Android 7,1 (API уровня 25-Nougat):
Если вы хотите обеспечить обратную совместимость с более ранней версией Android, задайте для минимальной версии Android целевую версию Android, которая будет поддерживаться вашим приложением. (Обратите внимание, что уровень API 14 — это минимальный уровень API, необходимый для Google Play служб и поддержки Firebase.) В следующем примере конфигурация поддерживает версии Android из API уровня 14 через уровень API 25.
Как правило, для всех трех уровней API Xamarin. Android задано одно и то же значение. Задайте для целевой платформы последнюю стабильную версию API (или, как минимум, до версии Android, которая содержит все необходимые компоненты). чтобы задать целевую платформу, перейдите к разделу сборка общие в параметрах Project. На следующем снимке экрана Целевая платформа настроена для использования последней установленной платформы (8,0):
Если вы хотите обеспечить обратную совместимость с более ранней версией Android, измените минимальную версию Android на самую старую версию Android, которую должно поддерживать ваше приложение. Обратите внимание, что уровень API 14 — это минимальный уровень API, необходимый для Google Play служб и поддержки Firebase. Например, следующая конфигурация поддерживает версии Android как раньше, чем API уровня 14:
Если приложение поддерживает несколько версий Android, в коде должны содержаться проверки среды выполнения, чтобы обеспечить работу приложения с минимальной версией Android (Дополнительные сведения см. в разделе проверки среды выполнения для версий Android ниже). Если вы используете или создаете библиотеку, ознакомьтесь со статьей уровни API и библиотеки ниже, чтобы получить рекомендации по настройке параметров уровня API для библиотек.
Версии Android и уровни API
По мере развития платформы Android и выпуска новых версий Android каждой версии Android назначается уникальный целочисленный идентификатор, называемый уровнем API. Таким образом, каждая версия Android соответствует одному уровню API Android. Так как пользователи устанавливают приложения на более ранних версий, а также в самых последних версиях Android, приложения для работы в реальном времени для Android должны быть разработаны с несколькими уровнями API Android.
Версии Android
Каждый выпуск Android проходит несколько имен:
Имя кода Android может соответствовать нескольким версиям и уровням API (как показано в таблице ниже), но каждая версия Android соответствует ровно одному уровню API.
| Имя | Версия | Уровень API | Выпущено | Код версии сборки |
|---|---|---|---|---|
| Q | 10.0 | 29 | Август 2020 г. | BuildVersionCodes.Q |
| Pie | 9.0 | 28 | Авг 2018 | BuildVersionCodes.P |
| Oreo | 8.1 | 27 | Dec 2017 | BuildVersionCodes.OMr1 |
| Oreo | 8.0 | 26 | Авг 2017 | BuildVersionCodes.O |
| Nougat | 7.1 | 25 | Dec 2016 | BuildVersionCodes.NMr1 |
| Nougat | 7.0 | 24 | Авг 2016 | BuildVersionCodes.N |
| Marshmallow | 6.0 | 23 | Авг 2015 | BuildVersionCodes.M |
| Lollipop | 5.1 | 22 | Мар 2015 | BuildVersionCodes.LollipopMr1 |
| Lollipop | 5.0 | 21 | Ноя 2014 | BuildVersionCodes.Lollipop |
| KitKat Watch | 4.4 w | 20 | Июнь 2014 | BuildVersionCodes.KitKatWatch |
| KitKat | 4.4. | 19 | Окт 2013 | BuildVersionCodes.KitKat |
| Jelly Bean | 4.3 | 18 | Июл 2013 | BuildVersionCodes.JellyBeanMr2 |
| Jelly Bean | 4.2 — 4.2.2 | 17 | 2012 ноября | BuildVersionCodes.JellyBeanMr1 |
| Jelly Bean | 4.1 — 4.1.1 | 16 | Июнь 2012 | BuildVersionCodes.JellyBean |
| Южные Сандвичевы | 4.0.3 — 4.0.4 | 15 | Dec 2011 | BuildVersionCodes.IceCreamSandwichMr1 |
| Южные Сандвичевы | 4.0 — 4.0.2 | 14 | Октябрь 2011 | BuildVersionCodes.IceCreamSandwich |
| хонэйкомб | 3.2 | 13 | Июнь 2011 | BuildVersionCodes.HoneyCombMr2 |
| хонэйкомб | 3.1. x | 12 | Май 2011 | BuildVersionCodes.HoneyCombMr1 |
| хонэйкомб | 3.0. x | 11 | Фев 2011 | BuildVersionCodes.HoneyComb |
| Gingerbread | 2.3.3 — 2.3.4 | 10 | Фев 2011 | BuildVersionCodes.GingerBreadMr1 |
| Gingerbread | 2.3 — 2.3.2 | 9 | 2010 ноября | BuildVersionCodes.GingerBread |
| фройо | 2.2. x | 8 | Июнь 2010 | BuildVersionCodes.Froyo |
| еклаир | 2.1.x | 7 | янв 2010 | BuildVersionCodes.EclairMr1 |
| еклаир | 2.0.1 | 6 | Dec 2009 | BuildVersionCodes.Eclair01 |
| еклаир | 2.0 | 5 | 2009 ноября | BuildVersionCodes.Eclair |
| кольцевой график; | 1.6 | 4 | Sep 2009 | BuildVersionCodes.Donut |
| купкаке | 1.5 | 3 | Май 2009 | BuildVersionCodes.Cupcake |
| Основной | 1,1 | 2 | Фев 2009 | BuildVersionCodes.Base11 |
| Основной | 1.0 | 1 | Октябрь 2008 | BuildVersionCodes.Base |
Как показано в этой таблице, новые версии Android выводятся часто, а иногда — несколько версий в год. В результате среда устройств Android, на которых может работать ваше приложение, включает в себя множество более старых и более новых версий Android. Как вы можете гарантировать, что приложение будет выполняться единообразно и надежно на разных версиях Android? Уровни API для Android могут помочь в управлении этой проблемой.
Уровни API Android
Каждое устройство Android выполняется только на одном уровне API — этот уровень API гарантированно уникален для каждой версии платформы Android. Уровень API точно определяет версию набора API, к которому может обращаться приложение. Он определяет сочетание элементов манифеста, разрешений и т. д., которые вы задаете в качестве разработчика. Система Android на уровнях API позволяет Android определить, совместимо ли приложение с образом системы Android перед установкой приложения на устройстве.
При сборке приложения он содержит следующие сведения об уровне API:
Целевой уровень API Android, на котором построено приложение для запуска.
Минимальный уровень API Android, который должен иметь устройство Android для запуска приложения.
Эти параметры используются, чтобы убедиться, что функции, необходимые для корректного запуска приложения, доступны на устройстве Android во время установки. В противном случае приложение блокируется на этом устройстве. Например, если уровень API устройства Android ниже минимального уровня API, указанного для приложения, устройство Android не позволит пользователю установить приложение.
Project параметров уровня API
В следующих разделах объясняется, как с помощью диспетчера пакетов SDK подготовить среду разработки для уровней API, которые вы хотите ориентировать, а затем подробно объяснить, как настроить целевую платформу, минимальную версию Androidи целевые параметры версии Android в Xamarin. Android.
Платформы пакет SDK для Android
Прежде чем можно будет выбрать целевой или минимальный уровень API в Xamarin. Android, необходимо установить пакет SDK для Android версию платформы, соответствующую этому уровню API. Диапазон доступных вариантов для целевой платформы, минимальной версии Android и целевой версии Android ограничен диапазоном установленных версий пакет SDK для Android. С помощью диспетчера пакетов SDK можно проверить, установлены ли требуемые версии пакет SDK для Android, и можно использовать ее для добавления новых уровней API, необходимых для приложения. Если вы не знакомы с установкой уровней API, см. раздел пакет SDK для Android Setup.
Целевая платформа (также известная как ) — это конкретная версия платформы Android (уровень API), для которой компилируется приложение во время сборки. Этот параметр указывает, какие API- интерфейсы будет использовать приложение при его запуске, но не влияет на то, какие API фактически доступны для приложения при его установке. В результате изменение параметра целевой платформы не приводит к изменению поведения среды выполнения.
Рекомендуется всегда компилироваться с последней доступной версией целевой платформы. Это позволяет получить полезные предупреждения для всех устаревших интерфейсов API, которые могут быть вызваны кодом. Использование последней версии целевой платформы особенно важно при использовании последних версий библиотеки поддержки — каждая библиотека предполагает, что приложение должно быть скомпилировано на основе минимального уровня API библиотеки поддержки или выше.
чтобы получить доступ к параметру целевой платформы в Visual Studio, откройте свойства проекта в обозреватель решений и выберите страницу приложения :
Минимальная версия Android
Минимальная версия Android (также известная как ) — это самая старая версия ОС Android (то есть самый низкий уровень API), которая может установить и запустить приложение. По умолчанию приложение может быть установлено только на устройствах, соответствующих параметру целевой платформы или выше. Если минимальная версия Android меньше, чем Целевая платформа, приложение также может работать в более ранних версиях Android. Например, если задать в качестве целевой платформы android 7,1 (Nougat) и установить для минимальной версии Android значение Android 4.0.3 (Ice-Южные Сандвичевы), приложение можно установить на любой платформе с уровня API 15 на уровень API 25 включительно.
Несмотря на то, что приложение может успешно создаваться и устанавливаться на этом диапазоне платформ, это не гарантирует, что он будет успешно запущен на всех этих платформах. Например, если приложение установлено в android 5,0 (без описания операций) и код вызывает API, доступный только в Android 7,1 (Nougat) и более поздней версии, приложение получит ошибку во время выполнения и, возможно, приведет к сбою. Поэтому код должен гарантировать – во время выполнения — он вызывает только те интерфейсы API, которые поддерживаются устройством Android, на котором оно выполняется. Иными словами, код должен включать явные проверки среды выполнения, чтобы гарантировать, что приложение использует более новые API только на тех устройствах, которые достаточно актуальны для их поддержки. Проверка среды выполнения для версий Androidдалее в этом руководство объясняет, как добавить эти проверки среды выполнения в код.
Если выбрать параметр использовать компиляцию с использованием версии пакета SDK, минимальная версия Android будет совпадать с целевой платформой.
Целевая версия Android
Целевая версия Android (также известная как ) — это уровень API устройства Android, на котором должно выполняться приложение. Android использует этот параметр, чтобы определить, следует ли включить любое поведение совместимости. Это гарантирует, что приложение продолжит работать так, как вы планируете. Android использует параметр целевой версии Android приложения, чтобы определить, какие изменения поведения можно применить к приложению без его нарушения (это то, как Android обеспечивает прямую совместимость).
Целевая платформа и Целевая версия Android с очень похожими именами не совпадают. Параметр целевой платформы передает сведения о целевом уровне API в Xamarin. Android для использования во время компиляции, а Целевая версия Android передает сведения о ЦЕЛЕВом интерфейсе API в Android для использования во время выполнения (если приложение установлено и выполняется на устройстве).
Рекомендуется явно указать в качестве целевой версии Android последнюю версию Android, используемую для тестирования приложения. В идеале его следует устанавливать на последнюю версию пакет SDK для Android — это позволяет использовать новые интерфейсы API до начала работы с изменениями поведения. Для большинства разработчиков не рекомендуется задавать в качестве целевой версии Android Использование функции Compile с использованием версии пакета SDK.
В общем случае целевая версия Android должна быть ограничена минимальной версией Android и целевой платформой. Это означает следующее:
Минимальная версия Android = Целевая версия Android Android.OS.Build.VERSION.SdkInt чтобы определить уровень API платформы, в которой работает приложение. Если уровень API меньше, чем минимальная версия Android, поддерживающая API, которую нужно вызвать, то код должен найти способ правильной работы без выполнения этого вызова API.
Как правило, проверка версии сборки помогает вашему коду принимать во время выполнения действия по сравнению со старым способом. Пример:
Нет быстрого и простого правила, объясняющих, как сократить или изменить функциональность приложения при запуске в более старых версиях Android, в которых отсутствует один или несколько API-интерфейсов. В некоторых случаях (например, в приведенном SetCategory выше примере) достаточно опустить вызов API, если он недоступен. Однако в других случаях может потребоваться реализовать альтернативную функциональность, когда Android.OS.Build.VERSION.SdkInt обнаруживается меньше уровня API, необходимого приложению для обеспечения его оптимального взаимодействия.
Уровни API и библиотеки
При создании проекта библиотеки Xamarin. Android (например, библиотеки классов или библиотеки привязок) можно настроить только параметр целевой платформы — минимальная версия Android и параметры целевой версии Android недоступны. Это связано с тем, что отсутствует страница манифеста Android :
Параметры минимальной версии Android и целевой версии Android недоступны, так как итоговая библиотека не является автономным приложением — библиотека может быть запущена в любой версии Android в зависимости от приложения, с которым оно упаковано. Можно указать способ компиляциибиблиотеки, но нельзя предсказать, на каком уровне API платформы будет выполняться библиотека. Учитывая это, при использовании или создании библиотек следует соблюдать следующие рекомендации.
При создании библиотеки Android — если вы создаете библиотеку Android для использования другими приложениями, убедитесь, что для параметра целевой платформы задан минимальный уровень API, необходимый для компиляции.
Эти рекомендации рекомендуется использовать для предотвращения ситуации, когда библиотека пытается вызвать API, который недоступен во время выполнения (что может привести к сбою приложения). Если вы разработчик библиотеки, вам следует ограничить использование вызовов API небольшим и хорошо установленным подмножеством общей контактной зоны API. Это гарантирует, что библиотеку можно будет использовать в более широком диапазоне версий Android.

















