Use java api in android

Как Java 8 поддерживается в Android

Привет, Хабр! Предлагаю вашему вниманию перевод замечательной статьи из цикла статей небезызвестного Джейка Вортона о том, как происходит поддержка Андроидом Java 8.

Оригинал статьи лежит тут

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

Это довольно сложная тема. Для начала нужно определиться, что мы вообще подразумеваем под «поддержкой Java в Android», ведь в одной версии языка может быть много всего: фичи (лямбды, например), байткод, тулзы, APIs, JVM и так далее.

Когда говорят о поддержке Java 8 в Android, обычно подразумевают поддержку фичей языка. Итак, начнем с них.

Лямбды

Одним из главных нововведений Java 8 были лямбды.
Код стал более лаконичным и простым, лямбды избавили нас от необходимости писать громоздкие анонимные классы, используя интерфейс с единственным методом внутри.

После компиляции этого, используя javac и легаси dx tool , мы получим следующую ошибку:

Эта ошибка происходит из-за того, что лямбды используют новую инструкцию в байткоде — invokedynamic , которая была добавлена в Java 7. Из текста ошибки можно увидеть, что Android поддерживает ее только начиная с 26 API (Android 8).

Звучит не очень, ведь вряд ли кто-то будет выпускать приложение с 26 minApi. Чтобы это обойти, используется так называемый процесс десахаризации (desugaring), который делает возможным поддержку лямбд на всех версиях API.

История десахаризации

Она довольно красочна в мире Android. Цель десахаризации всегда одна и та же — позволить новым языковым фичам работать на всех устройствах.

Изначально, например, для поддержки лямбд в Android разработчики подключали плагин Retrolambda. Он использовал тот же встроенный механизм, что и JVM, конвертируя лямбды в классы, но делал это в рантайме, а не во время компиляции. Сгенерированные классы были очень дорогими с точки зрения количества методов, но со временем, после доработок и улучшений, этот показатель снизился до чего-то более-менее разумного.

Затем команда Android анонсировала новый компилятор, который поддерживал все фичи Java 8 и был более производительным. Он был построен поверх Eclipse Java компилятора, но вместо генерации Java-байткода генерировал Dalvik-байткод. Однако его производительность все равно оставляла желать лучшего.

Когда новый компилятор (к счастью) забросили, трансформатор Java байткода в Java байткод, который и выполнял дешугаринг, был интегрирован в Android Gradle Plugin из Bazel — системы сборки Google. И его производительность все равно была невелика, поэтому параллельно продолжался поиск более хорошего решения.

И вот нам представили новый dexer — D8, который должен был заменить dx tool . Десахаризация теперь выполнялась во время конвертации скомпилированных JAR-файлов в .dex (dexing). D8 сильно выигрывает в производительности по сравнению с dx , и, начиная с Android Gradle Plugin 3.1 он стал dexer’ом по умолчанию.

Теперь, используя D8, у нас получится скомпилировать приведенный выше код.

Чтобы посмотреть, как D8 преобразовал лямбду, можно использовать dexdump tool , который входит в Android SDK. Она выведет довольно много всего, но мы заострим внимание только на этом:

Если вы до этого еще не читали байткод, не волнуйтесь: многое из того, что здесь написано, можно понять интуитивно.

В первом блоке наш main метод с индексом 0000 получает ссылку от поля INSTANCE на класс Java8$1 . Этот класс был сгенерирован во время десахаризации . Байткод метода main тоже нигде не содержит упоминаний о теле нашей лямбды, поэтому, скорее всего, она связана с классом Java8$1 . Индекс 0002 затем вызывает static-метод sayHi , используя ссылку на INSTANCE . Методу sayHi требуется Java8$Logger , поэтому, похоже, Java8$1 имплементирует этот интерфейс. Мы можем убедиться в этом тут:

Флаг SYNTHETIC означает, что класс Java8$1 был сгенерирован и список интерфейсов, которые он включает, содержит Java8$Logger .
Этот класс и представляет собой нашу лямбду. Если вы посмотрите на реализацию метода log , то не увидите тело лямбды.

Вместо этого внутри вызывается static метод класса Java8 — lambda$main$0 . Повторюсь, этот метод представлен только в байткоде.

Флаг SYNTHETIC снова говорит нам, что этот метод был сгенерирован, и его байткод как раз содержит тело лямбды: вызов System.out.println . Причина, по которой тело лямбды находится внутри Java8.class, простая — ей может понадобиться доступ к private членам класса, к которым сгенерированный класс иметь доступа не будет.

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

Преобразование исходников — Source Transformation

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

Возьмем за основу тот же класс с лямбдой:

Сначала тело лямбды перемещается в package private метод.

Затем генерируется класс, имплементирующий интерфейс Logger , внутри которого выполняется блок кода из тела лямбды.

Далее создается синглтон инстанс Java8$1 , который хранится в static переменной INSTANCE .

Вот итоговый задешугаренный класс, который может использоваться на всех версиях API:

Если вы посмотрите на сгенерированный класс в байткоде Dalvik, то не найдете имен по типу Java8$1 — там будет что-то вроде -$$Lambda$Java8$QkyWJ8jlAksLjYziID4cZLvHwoY . Причина, по которой для класса генерируется такой нейминг, и в чем его плюсы, тянет на отдельную статью.

Нативная поддержка лямбд

Когда мы использовали dx tool , чтобы скомпилировать класс, содержащий лямбды, сообщение об ошибке говорило, что это будет работать только с 26 API.

Поэтому кажется логичным, что если мы попробуем скомпилировать это с флагом —min-api 26 , то десахаризации происходить не будет.

Однако если мы сдампим .dex файл, то в нем все равно можно будет обнаружить -$$Lambda$Java8$QkyWJ8jlAksLjYziID4cZLvHwoY . Почему так? Это баг D8?

Чтобы ответить на этот вопрос, а также почему десахаризация происходит всегда, нам нужно заглянуть внутрь Java-байткода класса Java8 .

Внутри метода main мы снова видим invokedynamic по индексу 0 . Второй аргумент в вызове — 0 — индекс ассоциируемого с ним bootstrap метода.

Вот список bootstrap методов:

Здесь bootstrap метод назван metafactory в классе java.lang.invoke.LambdaMetafactory . Он живет в JDK и занимается созданием анонимных классов налету (on-the-fly) в рантайме для лямбд так же, как и D8 генерит их в компайлтайме.

Если взглянуть на документацию Android к java.lang.invoke
или на исходники AOSP к java.lang.invoke , увидим, что в рантайме этого класса нет. Вот поэтому дешугаринг всегда происходит во время компиляции, независимо от того, какой у вас minApi. VM поддерживает байткод инструкцию, похожую на invokedynamic , но встроенный в JDK LambdaMetafactory недоступен для использования.

Method References

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

Наш интерфейс Logger как раз является таким примером. Тело лямбды ссылалось на System.out.println . Давайте превратим лямбду в метод референc:

Когда мы это скомпилируем и взглянем на байткод, то увидим одно различие с предыдущей версией:

Вместо вызова сгенерированного Java8.lambda$main$0 , который содержит вызов System.out.println , теперь System.out.println вызывается напрямую.

Класс с лямбдой больше не static синглтон, а по индексу 0000 в байткоде видно, что мы получаем ссылку на PrintStream — System.out , который затем используется для того, чтобы вызвать на нем println .

В итоге наш класс превратился в это:

Default и static методы в интерфейсах

Еще одним важным и серьезным изменением, которое принесла Java 8, стала возможность объявлять default и static методы в интерфейсах.

Все это тоже поддерживается D8. Используя те же инструменты, что и ранее, несложно увидеть задешугаренную версию Logger’a с default и static методами. Одно из различий с лямбдами и method references в том, что дефолтные и статик методы реализованы в Android VM и, начиная с 24 API, D8 не будет дешугарить их.

Может, просто использовать Kotlin?

Читая статью, большинство из вас, наверное, подумали о Kotlin. Да, он поддерживает все фичи Java 8, но реализованы они kotlinc точно так же, как и D8, за исключением некоторых деталей.

Поэтому поддержка Андроидом новых версий Java до сих пор очень важна, даже если ваш проект на 100% написан на Kotlin.

Не исключено, что в будущем Kotlin перестанет поддерживать байткод Java 6 и Java 7. IntelliJ IDEA, Gradle 5.0 перешли на Java 8. Количество платформ, работающих на более старых JVM, сокращается.

Desugaring APIs

Все это время я рассказывал про фичи Java 8, но ничего не говорил о новых API — стримы, CompletableFuture , date/time и так далее.

Возвращаясь к примеру с Logger’ом, мы можем использовать новый API даты/времени, чтобы узнать, когда сообщения были отправлены.

Снова компилируем это с помощью javac и преобразуем его в байткод Dalvik с D8, который дешугарит его для поддержки на всех версиях API.

Можете даже запушить это на свой девайс, чтобы убедиться, что оно работает.

Если на этом устройстве API 26 и выше, появится месседж Hello. Если нет — увидим следующее:

D8 справился с лямбдами, метод референсами, но не сделал ничего для работы с LocalDateTime , и это очень печально.

Разработчикам приходится использовать свои собственные реализации или обертки над date/time api, либо использовать библиотеки по типу ThreeTenBP для работы со временем, но почему то, что ты можешь написать руками, не может сделать D8?

Эпилог

Отсутствие поддержки всех новых API Java 8 остается большой проблемой в экосистеме Android. Ведь вряд ли каждый из нас может позволить указать 26 min API в своем проекте. Библиотеки, поддерживающие и Android и JVM, не могут позволить себе использовать API, представленный нам 5 лет назад!

И даже несмотря на то, что саппорт Java 8 теперь является частью D8, каждый разработчик все равно должен явно указывать source и target compatibility на Java 8. Если вы пишете собственные библиотеки, то можете усилить эту тенденцию, выкладывая библиотеки, которые используют Java 8 байткод (даже если вы не используете новые фичи языка).

Над D8 ведется очень много работ, поэтому, кажется, в будущем с поддержкой фичей языка все будет ок. Даже если вы пишете только на Kotlin, очень важно заставлять команду разработки Android поддерживать все новые версии Java, улучшать байткод и новые API.

Этот пост — письменная версия моего выступления Digging into D8 and R8.

Источник

Уровень Android API, обратная и прямая совместимость

Добрый вечер, друзья. Мы подготовили полезный перевод для будущих студентов курса «Android-разработчик. Продвинутый курс». С радостью делимся с вами данным материалом.

Если вы читаете эту статью, значит вас могут интересовать такие вещи, как:

• Что означает уровень API?
• Как использовать compileSdkVersion , minSdkVersion или targetSdkVersion ?
• Как можно гарантировать, что приложение будет работать правильно на устройствах с разными версиями ОС?

Все эти понятия связаны друг с другом, и я постараюсь объяснить их вам в этой статье простым, но эффективным способом.

Для этого необходимо понимать разницу между 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) содержит:

• Android SDK Platform 28 (это API фреймворка).
• Исходный код для Android 28 (это реализация API, как вы видите, она не является обязательной… запомните это).
• и еще куча других вещей… например, различные системные образы для эмулятора Android.

Обзор SDK в Android Studio SDK Manager.

На второй вкладке 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-файлы. Оно состоит из двух основных компонентов:

• Виртуальная машина, чтобы воспользоваться преимуществами переносимости кода и независимости от платформы. Начиная с Android 5.0 (Lollipop), старая среда выполнения, Dalvik Virtual Machine, была полностью заменена новой средой Android RunTime (ART). Dalvik использовал JIT-компилятор, тогда как ART использует AOT (Ahead of time) компиляцию плюс JIT для профилирования кода во время выполнения.
• Базовые библиотеки — это стандартные библиотеки Java и Android. Проще говоря, именно здесь находится реализация API.

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

Например, если на фактическом устройстве установлен Android 9 (Pie), доступны все API до 28 уровня.

Если вам понятны ключевые моменты работы Android Runtime и какова роль API, то должно быть достаточно просто понять обратную и прямую совместимость, а так же использование compileSdkVersion , minSdkVersion и targetSdkVersion .

compileSdkVersion

Это значение используется только для указания Gradle, с какой версией SDK компилировать ваше приложение. Это позволяет разработчикам получить доступ ко всем API, доступным до уровня API, установленного для compileSdkVersion .

Настоятельно рекомендуется выполнить компиляцию с последней версией SDK:

• высокий уровень API позволяет разработчикам использовать преимущества последнего API и возможностей, предоставляемых новыми платформами.
• чтобы использовать последнюю версию SupportLibrary , compileSdkVersion должен соответствовать версии SupportLibrary .

Например, чтобы использовать SupportLibrary-28.x.x , compileSdkVersion также должен быть равен 28.

• для перехода на AndroidX или его использования, compileSdkVersion должен быть установлен как минимум равным 28.
• чтобы быть готовым удовлетворить требования целевого уровня API от Google Play. В Google объявили, что для более быстрого распространения новых версий Android на рынке Google каждый год будет устанавливать минимальный целевой уровень API для новых приложений и обновлений. Больше информации вы можете найти здесь и здесь.

Приложения Android совместимы с новыми версиями платформы Android, поскольку изменения в API обычно являются аддитивными, а старое API может стать устаревшим, но не удаленным.

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

Приложение + compileSdkVersion = 26 и метод API xyz() , представленный в API 26 уровня, могут работать на устройстве с Android 8 Oreo (API 26 уровня).

Это же приложение может работать на устройстве с Android 9 Pie (API 28 уровня), поскольку метод API xyz() все еще доступен на API 28 уровня.

minSdkVersion

Это значение обозначает минимальный уровень API, на котором приложение может работать. Это минимальное требование. Если не указан, значением по умолчанию является 1.

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

Во время разработки Lint также предупредит разработчиков при попытке использовать любой API ниже указанного в minSdkVersion . Очень важно не игнорировать предупреждения и исправить их!

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

Также важно упомянуть, что Google Play Store использует это значение, чтобы определить, можно ли установить приложение на определенное устройство, сопоставив версию платформы устройства с minSdkVersion приложения.

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

Выбор «правильного» значения для проекта также является бизнес-решением, поскольку оно влияет на то, насколько большой будет аудитория приложения. Посмотрите на распределение платформ.

Приложение + compileSdkVersion = 26 + minSdkVersion = 22 и метод API xyz() , представленный в API 26 уровня, могут работать на устройстве с Android 8 Oreo (API 26 уровня).

Это же приложение можно установить и запустить на более старом устройстве с Android 5.1 Lollipop (API 22 уровня), где метода API xyz() не существует. Если разработчики не обеспечили обратную совместимость ни с помощью проверок времени выполнения, ни с помощью каких-либо библиотек, то приложение будет аварийно завершать работу, как только оно попытается получить доступ к методу API xyz() .

targetSdkVersion

Это значение указывает уровень API, на котором приложение было разработано.

Не путайте его с compileSdkVersion . Последний используется только во время компиляции и делает новые API доступными для разработчиков. Первый, напротив, является частью APK (также как и minSdkVersion ) и изменяет поведение среды выполнения. Это способ, которым разработчики могут контролировать прямую совместимость.

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

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

Простым примером является Runtime Permission, которое было представлено в Android 6 Marshmallow (API 23 уровня).

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

Таким образом, приложение может по-прежнему быть совместимым без включения нового поведения среды выполнения.

В любом случае, как уже упоминалось, Google требует, чтобы приложения удовлетворяли новым требованиям целевого уровня API, поэтому всегда следует иметь высокий приоритет для обновления этого значения.

Теперь соединяя все это вместе, мы видим четкое отношение

minSdkVersion ≤ targetSdkVersion ≤ compileSdkVersion

Имейте в виду, что настоятельно рекомендуется выполнить компиляцию в соответствии с последним уровнем API и стараться использовать targetSdkVersion == compileSdkVersion.

Источник