Android sdk api версии

Android sdk api версии

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

Платформа Android предоставляет framework API, которое могут использовать приложения для взаимодействия с нижележащей системой Android. Framework API состоит из:

• Базового набора пакетов и классов.
• Набора элементов XML и атрибутов для декларирования в файле манифеста (manifest file).
• Набора элементов XML и атрибутов для декларирования и доступа к ресурсам.
• Набора намерений (Intents).
• Набора разрешений доступа к ресурсам устройства и системы, которые приложение может запросить, а также защита ограничения доступа, встроенная в систему.

Каждая последующая версия платформы Android может включать в себя обновления предоставляемого framework API приложения Android.

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

Framework API, который поставляет платформа Android, указывается в виде целого числа, и этот идентификатор в виде целого числа называется «API Level». Каждая версия платформы Android поддерживает точно один API Level, несмотря на неявную поддержку всех более старых версий API Level (вплоть до API Level 1). Первоначальный релиз платформы Android предоставлял API Level 1 и с каждым новым релизом номер API Level последовательно увеличивался на единицу.

В таблице ниже указаны поддерживаемые API Level для каждой платформы Android. Для информации по относительным количествам устройств, которые работают на каждой версии, см. страничку [2].

Версия платформы	API Level	VERSION_CODE
Android 4.4	19	KITKAT
Android 4.3	18	JELLY_BEAN_MR2
Android 4.2, 4.2.2	17	JELLY_BEAN_MR1
Android 4.1, 4.1.1	16	JELLY_BEAN
Android 4.0.3, 4.0.4	15	ICE_CREAM_SANDWICH_MR1
Android 4.0, 4.0.1, 4.0.2	14	ICE_CREAM_SANDWICH
Android 3.2	13	HONEYCOMB_MR2
Android 3.1.x	12	HONEYCOMB_MR1
Android 3.0.x	11	HONEYCOMB
Android 2.3.3, 2.3.4	10	GINGERBREAD_MR1
Android 2.3, 2.3.1, 2.3.2	9	GINGERBREAD
Android 2.2.x	8	FROYO
Android 2.1.x	7	ECLAIR_MR1
Android 2.0.1	6	ECLAIR_0_1
Android 2.0	5	ECLAIR
Android 1.6	4	DONUT
Android 1.5	3	CUPCAKE
Android 1.1	2	BASE_1_1
Android 1.0	1	BASE

[Как используется API Level в Android]

Идентификатор API Level играет ключевую роль в предоставлении информации пользователям и разработчикам.

• API Level позволяет платформе (операционной системе) Android описать максимальную ревизию framework API, которую платформа поддерживает.
• API Level позволяет приложениям описать требуемую для них ревизию framework API.
• API Level позволяет системе обрабатывать инсталляции приложений на устройстве пользователя и определять, какие их них являются несовместимыми с текущей версией системы.

Подробнее про использовании API Level в приложении и системе Android см. [3].

[Совместимость приложений с новыми версиями операционной системы Android]

Application forward compatibility — под этим имеют в виду, что приложения Android обычно имеют «совместимость вперед». Т. е. старые приложения, которые скомпилированы в расчете на старую версию операционной системы, будут продолжать нормально работать на всех более новых операционных системах Android.

Поскольку большинство изменений framework API в операционной системе являются добавочными, то приложения Android, разработанные с указанной версией API (как указано по API Level) будут совместимы в будущем (forward-compatible) с последующими версиями платформ Android и более высокими уровнями API level. Приложения должны иметь возможность работать на всех последующих версиях платформы Android, за исключением изолированных случаев, когда приложение использует часть API, которая по некоторым причинам было удалена в поздней ревизии API.

Forward-совместимость важна, потому что множество устройств, работающих на Android, получают обновления системы на лету, по каналу Wi-Fi (over-the-air, OTA). Пользователь может установить Ваше приложение и успешно его использовать, и позднее получить OTA-обновление на новую версию платформы Android. Как только обновление установлено, Ваше приложение будет работать уже в новой версии рабочего окружения, на новом API (run-time version environment), и от этого нового API и возможностей системы будет зависеть работа Вашего приложения.

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

Application backward compatibility — означает совместимость приложения со старыми версиями операционной системы Android. Приложения не обязательно будут обратно совместимы с версиями платформ Android, которые имеют более старую версию, чем версия системы, под которую приложение было скомпилировано.

Каждая новая версия платформы Android может включать новый framework API, который дает приложениям доступ к возможностям новой платформы, или заменяет существующие части API. Новый API доступен приложениями, когда они работают на новой платформе и, как уже упоминалось, также будет доступен и в более новых версиях платформы, как указано по API Level. С другой стороны, потому что более ранние версии платформы не включают в себя новый API, приложения, использующие новый API, не смогут работать на более старых платформах.

[Выбор версии платформы и API Level]

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

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

[Декларирование минимальной версии API Level]

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

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

[Тестирование на верхних уровнях API Level]

После того, как скомпилировали приложение, Вы должны убедиться, что протестировали его на платформе, указанной в атрибуте android:minSdkVersion приложения. Чтобы сделать это, создайте AVD, которая использует версию платформы, требуемую приложением. Дополнительно, чтобы убедиться в forward-совместимости, Вы должны запустить и протестировать приложение на всех платформах, которые используют более высокий уровень API Level, чем использует Ваше приложение.

Android SDK включает в себя множество версий платформ, которые Вы можете использовать, включая последнюю версию, и предоставляет инструмент обновления (updater tool), который можно использовать для загрузки других необходимых версий платформ. Чтобы запустить updater, используйте инструмент командную строки android (на Windows это android.bat), находящийся в директории / tools directory. Вы можете запустить SDK updater, если выполните команду android sdk. Вы также можете сделать двойной клик на файле android.bat (под Windows) или android (под OS X/Linux). В ADT Вы можете также получить доступ к updater путем выбора меню Window -> Android SDK Manager.

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

[Использование Provisional API Level]

В некоторых случаях может быть доступен «Ранний просмотр (Early Look)» платформы Android SDK. Это означает разработку для платформы, которая пока официально не появилась на рынке. Чтобы начать разработку на платформе, API которой еще не получила финальную версию, то не указывается API Level платформы. Вместо этого Вы должны использовать предварительный (provisional) API Level в манифесте приложения, когда делаете сборку приложения на указанной платформе. Provisional API Level не является числом, это строка, соответствующая кодовому имени еще не выпущенной версии платформы. Provisional API Level будет указан в примечаниях к релизу для ранних релизов SDK (Early Look SDK release), и эта строка чувствительна к регистру символов.

Использование provisional API Level разработано для того, чтобы защитить разработчиков и пользователей устройств от нежелательной публикации или инсталляции приложений, основанных на Early Look framework API, потому что на финальном образе системы приложение может работать не так, как ожидалось.

Provisional API Level будет допустим только при использовании Early Look SDK, и его можно использовать для запуска приложений только в эмуляторе. Приложения, использующие provisional API Level, никогда не могут быть установлены на устройство Android. После финального релиза платформы Вы должны заменить любые экземпляры provisional API Level в Вашем файле манифеста приложения на действительный идентификатор API Level в виде целого числа.

[Фильтрация документации на основе API Level]

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

Чтобы использовать фильтрацию, поставьте галочку в чекбоксе для разрешения фильтрации, сразу ниже бокса поиска на странице. Затем установите контрол «Filter by API Level» в тот же API Level, который используется в Вашем приложении. Обратите внимание, что API, представленный в последующих версиях API Level нарисованы серым, и это содержимое будет замаскировано, потому что не будет доступно в Вашем приложении.

Фильтрация по API Level в документации не предоставляет просмотр, что нового представлено в каждом API Level. Фильтрация просто предоставляет метод для просмотра всего API, связанного с указанным API Level, когда исключаются элементы API, представленные в последующих API Levels.

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

Также имейте в виду, что документация по отдельным элементам API указывает API Level для каждого представленного элемента. API Level для пакетов и классов указывается как «Since » в правом верхнем углу содержимого каждой страницы документации. API Level для членов класса указан в соответствующем заголовочном файле.

Источник

Обновляемся на новую версию API Android по наставлению Google

Скоро выходит Android 12, но в этом августе уже с 11-й версии разработчикам придётся использовать новые стандарты доступа приложений к внешним файлам. Если раньше можно было просто поставить флаг, что ваше приложение не поддерживает нововведения, то скоро они станут обязательными для всех. Главный фокус — повышение безопасности.

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

Что происходит

Если вы уже знакомы с теорией, то этот раздел можно пропустить — тут я хочу поверхностно сравнить подходы к предмету в разных версиях операционной системы.

В Android есть внутреннее Internal Storage (IS) и внешнее хранилище External Storage (ES). Исторически это были встроенная память в телефоне и внешняя SD-карта, поэтому ES был больше, но медленнее и дешевле. Отсюда и разделение — настройки и критически важное записывали в IS, а в ES хранили данные и большие файлы, например, медиа. Потом ES тоже стал встраиваться в телефон, но разделение, по крайней мере логическое, осталось.

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

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

В Android решили всё это переделать ещё в 10-й версии, а в 11-й это стало обязательным.

Чтобы минимизировать риски для пользователя в Google решили внедрить Scoped Storage (SS) в ES. Возможность проникнуть в папки других приложений убрали, а доступ есть только к своим данным — теперь это сугубо личная папка. А IS с 10-й версии ещё и зашифрована по умолчанию.

В Android 11 Google зафорсировала использование SS — когда таргет-версия SDK повышается до 30-й версии API, то нужно использовать SS, иначе будут ошибки, связанные с доступом к файлам. Фишка Android в том, что можно заявить совместимость с определённой версией ОС. Те, кто не переходили на 11, просто говорили, что пока не совместимы с этой версий, но теперь нужно начать поддерживать нововведения всем. С осени не получится заливать апдейты, если не поддерживаешь Android 11, а с августа нельзя будет заливать новые приложения.

Если SS не поддерживается (для девайсов ниже 10-й версии), то для доступа к данным других приложений требуется получить доступ к чтению и записи в память. Иначе придётся получать доступ к файлам через Media Content, Storage Access Framework или новый, появившийся в 11-м Android, фреймворк Datasets в зависимости от типа данных. Здесь тоже придётся получать разрешение доступа к файлу, но по более интересной схеме. Когда расшариваемый файл создаёшь сам, то доступ к нему не нужен. Но если переустановить приложение — доступ к нему опять потребуется. К каждому файлу система привязывает приложение, поэтому когда запрашиваешь доступ, его может не оказаться. Особо беспокоиться не нужно, это сложно отследить, поэтому лучше просто сразу запрашивать пермишен.

Media Content, SAF и Datasets относятся к Shared Storage (ShS). При удалении приложения расшаренные данные не удаляются. Это полезно, если не хочется потерять нужный контент.

Хотя даже при наличии SS можно дать доступ к своим файлам по определённой технологии — через FileProvider можно указать возможность получения доступа к своим файлам из другого приложения. Это нормально, потому что файлы расшаривает сам разработчик.

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

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

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

Перейдём к практике.

Переход на новую версию

Основная функциональность по работе с файлами в приложении iFunny представлена в виде сохранения мемов в память и расшаривания их между приложениями. Это было первое, что требовалось починить.

Для этого выделили в общий интерфейс работу с файлами, реализация которого зависела от версии API.

FilesManipulator представляет собой интерфейс, который знает, как работать с файлами и предоставляет разработчику API для записи информации в файл. Copier — это интерфейс, который разработчик должен реализовать, и в который передаётся поток вывода. Грубо говоря, мы не заботимся о том, как создаются файлы, мы работаем только с потоком вывода. Под капотом до 10-й версии Android в FilesManipulator происходит работа с File API, после 10-й (и включая её) — MediaStore API.

Рассмотрим на примере сохранения картинки.

Так как операция сохранения медиафайлов достаточно длительная, то целесообразно использовать MediaStore.Images.Media.IS_PENDING , которая при установлении значения 0 не дает видеть файл приложениям, отличного от текущего.

По сути, вся работа с файлами реализована через эти классы. Шаринг в другие приложения автоматически сохраняют медиа в память устройства и последующая работа с URI уже происходит по новому пути. Но есть такие SDK, которые ещё не успели перестроиться под новые реалии и до сих пор используют File API для проверки медиа. В этом случае используем кеш из External Storage и при необходимости провайдим доступ к файлу через FileProvider API.

Помимо ограничений с памятью в приложениях, таргетированных на 30-ю версию API, появилось ограничение на видимость приложения. Так как iFunny использует шаринг во множество приложений, то данная функциональность была сломана полностью. К счастью, достаточно добавить в манифест query, открывающую область видимости к приложению, и можно будет также полноценно использовать SDK.

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

После проверок запуска UI-тестов на девайсах с версиями API 29-30 было выявлено, что они также перестали корректно отрабатываться.

Первоначально в LogCat обнаружил, что приложение не может приконнектиться к процессу Orchestrator и выдает ошибку java.lang.RuntimeException: Cannot connect to androidx.test.orchestrator.OrchestratorService.

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

Тест удачно запустился, но возникла другая ошибка — Allure не может сохранить отчёт в память устройства, падает с ошибкой.

Очевидно из-за Scoped Storage стало невозможно сохранять файлы в другие папки, поэтому снова почитав документацию по управлению файлами в памяти на девайсе, обнаружил интересный раздел. Там рассказано, как для нужд тестов открыть доступ к папкам девайса, но с существенными ограничениями, которые можно почитать тут.

Так как нам нужно использовать этот пермишен только для тестов, то нам условия подходят. Поэтому я быстренько написал свой ShellCommandExecutor, который выполняет команду adb shell appops set —uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow на создании раннера тестов.

На Android 11 тесты удачно запустились и стали проходить без ошибок.

После попытки запуска на 10-й версии Android обнаружил, что отчет Allure также перестал сохраняться в память девайса. Посмотрев issue Allure, обнаружил, что проблема известная, как и с 11-й версией. Достаточно выполнить команду adb shell appops set —uid PACKAGE_NAME LEGACY_STORAGE allow . Сказано, сделано.

Запустил тесты — всё еще не происходит сохранения в память отчёта. Тогда я обнаружил, что в манифесте WRITE_EXTERNAL_STORAGE ограничен верхней планкой до 28 версии API, то есть запрашивая работу памятью мы не предоставили все разрешения. После изменения верхней планки (конечно, для варианта debug) и запроса пермишена на запись тесты удачно запустились и отчёт Allure сохранился в память устройства.

Добавлены следующие определения пермишенов для debug-сборки.

После всех вышеописанных манипуляций с приложением, можно спокойно устанавливать targetSdkVersion 30, загружать в Google Play и не беспокоиться про дедлайн, после которого загружать приложения версией ниже станет невозможно.

Источник