Android sdk

Введение

В данной статье я постараюсь описать пример инфраструктуры для автотестов Android приложений (mobile automation), а именно, среду для проведения тестранов UI автотестов на эмуляторе Android девайса в виртуальной среде.

Требования:

Для Android эмулятора нужна поддержка Intel Virtualization Technology или AMD Virtualization. Поэтому часто тестировщик сталкивается с необходимостью запуска тестранов только в нативной среде ПК с прямым доступом к центральному процессору.

В этом случае схема получается такая:

Трудности:

1. Невозможно легко пересоздать среду эмулятора.

2. Среда не создаётся перед проведением тестирования, и после проведения не удаляется, поэтому среда может влиять на тестируемое приложение.

3. Починка и настройка среды занимает много времени.

Предлагаемое решение в данной статье:

1. Создать VM с использованием возможностей nested virtualization VirtualBox (более подробное описание технологии в этой статье).

2. Пробросить поддержку Intel-VT или KVM внутрь созданной виртуальной машины.

3. Изнутри VM создать и запустить Android эмулятор девайса.

4. Провести тестран UI тестов приложения.

5. После проведения тестирования уничтожить VM.

В этом случае схема получится такая:

Предполагаемые преимущества:

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

2. Уменьшится время поддержки среды и управляющего ПО, так как не нужно каждый раз руками ничего устанавливать и чинить неисправности инвайронмента.

В настоящей статье будет использоваться оборудование:

• процеcсор: Intel i5-1035G1

• память: 12Gb

• в BIOS включена поддержка виртуализации процессора

• OC: Ubuntu 20.4

Шаг 1: Установка ПО на нативную OS

Отдельно обращу внимание на управление машиной. Будем использовать протокол VNC для создания удобного удаленного рабочего стола. Протокол универсальный, для Linux, Windows, Mac и т.д.

x11vnc сервер

Установка:

sudo apt-get update #обновляем пакетыsudo apt install x11vnc #устанавливаем x11vncsudo x11vnc -storepasswd <вводим пароль сервера> /etc/x11vnc.pass #создаём пароль в файликеsudo chmod ugo+r /etc/x11vnc.pass #разрешаем использовать файлик с паролем

Запуск с параметрами:

x11vnc -nevershared -forever -dontdisconnect -many -noxfixes -rfbauth /etc/x11vnc.pass

Установка VirtualBox

Вводим в командной строке:

sudo apt-get updatesudo apt install gcc make linux-headers-$(uname -r) dkmswget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -sudo sh -c 'echo "deb http://download.virtualbox.org/virtualbox/debian $(lsb_release -sc) contrib" >> /etc/apt/sources.list.d/virtualbox.list'sudo apt update #обновляем репозиторийsudo apt install virtualbox-6.1

Создание VM

Мы пойдем по самому простому пути и создадим VM из интерфейса VirtualBox с такими характеристиками. В дальнейшем создание VM будет code-first

• Количество CPU - не больше половины имеющихся на Вашем процессоре (в идеале половина)

• Оперативная память - будет достаточно 4Gb

Nested Virtualization можно также включить из командной строки:

VBoxManage modifyvm <Имя VM> --nested-hw-virt on

Далее переходим в саму VM.

Шаг 2: Установка ПО на VM

В первый раз мы установим всё руками. В дальнейшем весь установочный сценарий будет помещен в Packer, что позволит нам создавать VM с нужными настройками каждый раз перед началом тестирования.

Устанавливаем последний образ Ubuntu с официального сайта.

Установка KVM

egrep -c '(vmx|svm)' /proc/cpuinfo #Если в результате будет возвращено 0 - значит Ваш процессор не поддерживает аппаратной виртуализации, если 1 или больше - то вы можете использовать KVM на своей машинеsudo apt-get update #Обновляем пакетыsudo apt install qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager #Установка KVM и сопроводительные либыsudo usermod -G libvirt -a ubuntu #Добавление пользователя ubuntu в группу libvirtsudo systemctl status libvirtd #Проверка запуска сервиса libvirtsudo kvm-ok #Проверка статуса KVM

Установка Android command line tools

sudo apt-get update #обновляем пакетыyes | sudo apt install android-sdk #устанавливаем Android SDKsudo apt install unzip #Устанавливаем unzip для распаковки архивовcd ~/Downloads #переходим в каталог Downloadswget https://dl.google.com/android/repository/commandlinetools-linux-6858069_latest.zip #скачиваем архив с command line tools с официального сайта Googlesudo unzip commandlinetools-linux-6858069_latest.zip -d /usr/lib/android-sdk/cmdline-tools/ #распаковываемsudo mv /usr/lib/android-sdk/cmdline-tools/cmdline-tools /usr/lib/android-sdk/cmdline-tools/tools #переименовываем каталог с тулами. Сейчас странная ситуация, Google раздаёт тулу с одним каталогом, а SDK ищет его в другом каталогеexport ANDROID_SDK_ROOT=/usr/lib/android-sdk #регистируем переменнуюexport PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/latest/bin:$ANDROID_SDK_ROOT/cmdline-tools/tools/bin #регистрируем новый Pathexport PATH=$PATH:$ANDROID_SDK_ROOT/emulator #регистируем новый Path

Проверяем, что sdkmanager работает и Android SDK доступен:

sdkmanager --version

Устанавливаем Android tools

yes | sdkmanager --licenses #принимаем лицензииsudo chown $USER:$USER $ANDROID_SDK_ROOT -R #Ставим для текущего юзера право менять содержимое папки с ANDROID_SDK_ROOTyes | sdkmanager "cmdline-tools;latest" #устанавливаем cmdline-toolssdkmanager "build-tools;30.0.3" #Устанавливаем build-toolssdkmanager "platform-tools" #Устанавливаем platform-toolssdkmanager "platforms;android-30"sdkmanager "sources;android-30"sdkmanager "emulator" #Устанавливаем AVD manageremulator -accel-check #Проверяем, есть ли поддержка виртуализацииyes | sdkmanager "system-images;android-23;google_apis;x86_64" #Устанавливаем образ для эмулятораsdkmanager --list #Выводим список установленных пакетов. Обычно для CI оставляю.no | avdmanager create avd -n android-23_google_apis_x86_64 -k "system-images;android-23;google_apis;x86_64" #создаём эмулятор из образаemulator -list-avds #проверяем наличие созданного эмулятора

Устанавливаем Git и клонируем проект

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

sudo apt update #обновляем пакетыyes | sudo apt install git #установка Gitgit --version #проверка установкиmkdir ~/workspace #создаём каталог для проектовcd ~/workspace #переходим в каталог для проектовgit clone https://github.com/panarik/AndroidClearApp.git #клонируем проект на локалcd ~/workspace/AndroidClearApp #переходим в каталог проекта

Шаг 3: Проведение тестирования проекта на созданном Android эмуляторе

./gradlew assembleDebug --no-daemon #билдим APKemulator -avd android-23_google_apis_x86_64 -no-audio -no-window -verbose -gpu off -accel off #запускаем эмулятор из ранее созданныхsleep 240 #аналог будильника, ждём четыре минуты пока загрузится эмуляторadb get-state #проверяем, видит ли ADB запущенный эмулятор. Если нет, то ждем еще

ADB видит подключенный к нему эмулятор:

Запускаем тестран:

./gradlew connectedAndroidTest --no-daemon

Ура! Тест пройден!

Негативный тест

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

Подготовка:

• Переустановка VirtualBox на родительской машине (чтобы избежать ошибочное сохранение конфигов)

sudo apt purge virtualbox-6.1

• VM мы создаём без проброса виртуализации и с одним CPU:

• В созданной VM мы не устанавливаем:

  • VBoxClient

  • KVM

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

Ура! Тест не пройден! Никогда еще так не радовался проваленному тестрану:

Падает PackageManager, как и обычно при запуске из виртуальной среды без аппаратной поддержки процессора:

Заключение

Мы сделали первый этап построения инфраструктуры для проведения автотестов Android приложений. Следующим этапом должно стать упаковка описанного выше сценария в Packer (ссылка на официальный сайт) который умеет работать с образами VirtualBox. Затем весь сценарий мы попробуем запустить из CI Jenkins. Если учесть, что плагин для него уже порядком устарел, то будет очень интересно.

Все результаты опубликую, как пополнения к этой статье.

В идеале, у нас должна получится code-first инфраструктура для тестрана UI и интеграционных автотестов для Android приложений, которую можно поднять на любом современном офисном ПК, которая работает автономно, билдит тесты на родных Android эмуляторах и есть не просит.

Спасибо большое за внимание!

П.С.

Можно Вас в комментариях попросить привести пример Вашей инфраструктуры с использованием Android эмулятора? К примеру, эмуляторы в докер-контейнерах (https://github.com/budtmo/docker-android) может быть еще какие-нибудь интересные примеры.

Мы добавили в Android Game SDK библиотеку Oboe C++ для работы со звуком. Она позволяет разрабатывать высокопроизводительные аудиоприложения с низкой задержкой для максимального спектра устройств Android. Эта библиотека также отлично подойдет большинству разработчиков игр. О ней и о том как с ней работать в Android Game SDK мы и хотим рассказать в этой статье.

Один API

Библиотека Oboe использует усовершенствованный интерфейс AAudio с расширенными функциями на устройствах под управлением Android 8.1 (API уровня 27) или более поздней версии, а также обеспечивает обратную совместимость (через OpenSL ES) с Android 4.1 (API уровня 16) или более поздней версии. В дополнение к API платформы библиотека Oboe предлагает разработчикам аудиоприложений ключевые функции для комфортной работы, такие как ресемплинг, преобразование форматов и динамическая корректировка задержек. При необходимости она позволяет преобразовывать аудиоданные, например конвертировать число каналов, чтобы повышать производительность выбранных устройств. Также библиотека предлагает обходные решения для других особенностей работы конкретных устройств, что повышает эффективность кода для обработки звука. В двух словах, теперь библиотека Oboe считается рекомендуемым решением при написании кода для работы со звуком на C/C++ для платформы Android.

Интеграция Oboe

Встроить элементы кода на базе Oboe в проект можно двумя основными способами. Если вы используете плагин Android Gradle 4.1.0 или более поздней версии вместе с CMake, а также используете (или можете подключить) общую библиотеку STL, для включения библиотеки Oboe достаточно добавить ее в список зависимостей Gradle, включить объекты prefab и добавить несколько строк кода в файл CMakeLists.

Интегрировать Oboe также можно с помощью статического связывания при помощи Android Game SDK. Сначаласкачайте библиотекуи зарегистрируйте ее в системе управления версиями. Работать нужно с minSdkVersion 16 или более поздней версии, а также с NDK 18 или более поздней версии. Затем укажите версию игрового SDK для привязки, которая скомпилирована для заданной комбинации ABI, уровня API, NDK и STL, добавив путь к компилятору в следующем формате:

gamesdk/libs/[architecture]_API[apiLevel]_NDK[ndkVersion]_[stlVersion]_ReleaseExample: gamesdk/libs/arm64-v8a_API24_NDK18_cpp_static_Release

Затем добавьте ключ-loboe_staticв команду компоновщика. Поскольку включать общую библиотеку liboboe.so не требуется, статическое связывание позволяет сократить размер кода. Если для комбинации ABI, уровня API, NDK и STL нет предварительно скомпилированной версии SDK под ваши настройки, можно выполнить связывание с общей библиотекой. Дополнительные указания, в том числе о настройке CMake для статических библиотек, см. вдокументации для разработчиков.

Основы Oboe

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

oboe::AudioStreamBuilder builder;builder.setPerformanceMode(oboe::PerformanceMode::LowLatency)  ->setSharingMode(oboe::SharingMode::Exclusive)  ->setDataCallback(myCallback)  ->setFormat(oboe::AudioFormat::Float);

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

class MyCallback : public oboe::AudioStreamDataCallback {public:    oboe::DataCallbackResult    onAudioReady(oboe::AudioStream *audioStream, void *audioData, int32_t numFrames) {        // We requested AudioFormat::Float        auto *outputData = static_cast<float *>(audioData);        // TODO: populate audioData here        return oboe::DataCallbackResult::Continue;    }};

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

Обратная связь

Если вы столкнулись с проблемами, сообщите нам о нихчерез GitHub.

Привет, Хабр! В мае прошлого года, оставшись без сервисов и API гугла, мы основательно взялись за работу над своей платформой Huawei Mobile Services. Это наш давний проект, к которому мы вернулись после введения американских санкций. Проблема отрезанных сервисов постепенно сошла на нет. Мы добавили недостающие компоненты: почтовый клиент, свои карты и другие сервисы, и HMS Core набор API, SDK и прочих сервисов для разработки, и улучшения приложений. В этот набор входит Push Kit облачная служба для рассылки уведомлений и не только. Под катом расскажем, как устроен этот инструмент, чем выделяется и как его можно использовать.

Главная функция Push Kit (об остальных поговорим дальше) доставлять на устройство пользователя уведомления от приложений. Этот процесс организован так:

• сервер приложения подключается к API-интерфейсу Push Kit и загружает туда зашифрованные сообщения;

• из облака Push Kit сообщения пересылаются на устройство с целевым приложением.

Кроме того, у Push Kit есть множество интересных и полезных фич:

• Таргетирование рассылки по темам сообщений и другим критериям, в том числе с помощью Huawei Analytics Kit;

• Отправка пуш-сообщений на основе сценариев одному или нескольким пользователям одновременно, рассылка по расписанию;

• Отправка пуш-сообщений через консоль в интерфейсе AppGallery Connect.

• Доступ к серверу Push Kit через HTTPS;

• Отправка пуш-сообщений пользователям, которые пользуются разными профилями на одном Android-устройстве;

• Отправка пуш-сообщений на устройства Android/iOS и веб-приложения;

• Автоматический выбор языка пуш-сообщения в зависимости от языка системы устройства получателя;

• Кэширование и повторная отправка в случае, если пуш-сообщение не доставлено из-за отсутствия сети.

Что и как можно послать через Push Kit

С помощью Push Kit можно не только доставлять уведомления, но и передавать данные напрямую в приложение. В этом случае на пользовательское устройство приходит послание, которое активирует в программе-адресате определённое действие. Функция может оказаться полезной, например, для соцсетей, когда вы получаете запрос добавиться в друзья или входящие вызовы по VoIP. Кроме того, с её помощью можно загружать в сообщения в мессенджеры, чтобы они уже были внутри, когда вы запустите программу.

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

Если группа уведомлений от одного приложения в статус-баре свёрнута, по умолчанию в нём будут показаны первые два пуша их количество можно расширить до восьми. Такая группа может содержать до 24 пуш-уведомлений в EMUI 10 и до 49 в EMUI 9. Если сообщений больше, будет виден счётчик оставшихся уведомлений и следующее появится только после удаления одного из отображаемых пушей.

Имя пакета, отправляемого Push Kit, может содержать до 128 байт, а максимальный размер сообщения составляет 4 Кб.

Если у целевого устройства нет проблем с сетью, доставка пушей должна происходить не дольше, чем за 1 секунду. Если же девайс получателя не в сети, Push Kit кеширует сообщение и отправляет его после того, как устройство переходит в онлайн.

Особенности Push Kit

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

Push Kit позволяет этого не делать: сообщения попадают в его центр уведомлений (NC), минуя целевые приложения. За это отвечает специальный компонент под названием Push Service. В итоге программа запускается только тогда, когда это предусмотрено сценарием, например после нажатия на уведомление.

Отсюда и высокая скорость доставки: благодаря Push Service пользователь может прочитать сообщение практически сразу после того, как оно попадёт на телефон.

Push Kit предоставляет канал системного уровня, способный одновременно отправлять десятки миллионов сообщений в секунду и десятки миллиардов в день. При этом 99 % пушей доставляются пользователям в течение 10 минут, даже если приложение не запущено. По сути, уведомления не доходят, только если устройство получателя выключено или находится вне сети.

Push Service устанавливается на все мобильные устройства с EMUI, так что на них уведомления отображаются в унифицированном виде.

Служба Центр уведомлений доступна на некоторых устройствах Huawei с EMUI 4 и на всех начиная с EMUI 5. А вот на гаджетах сторонних производителей эта функция недоступна, но если установить на них HMS Core, эти телефоны тоже научатся принимать уведомления, отправленные через Huawei Push Kit. Увы, из-за системных ограничений скорость доставки на телефоны других марок может снизиться.

Push Kit поддерживает основные кроссплатформенные среды разработки мобильных приложений, включая React Native, Cordova, Xamarin и Flutter. Чтобы разрабатывать на одном языке приложение, которое будет работать и на iOS, и на Android, нужно только интегрировать соответствующий пакет подключаемого модуля SDK.

После получения сообщений через Push Kit пользовательские устройства информируют об этом ваш сервер, помогая отслеживать ход рассылки в режиме реального времени. Благодаря этому можно быть в курсе статуса каждого уведомления и иметь возможность оперативно реагировать на неудачную доставку. Например, отправить SMS человеку, до которого не доходят пуши.

Push Kit автоматически показывает пуши на языке, который установлен в устройстве пользователя. Охват Push Kit более 200 стран и регионов, поэтому такая функция будет очень полезна.

Под капотом Push Kit: немного практики

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

• компьютер на Windows с установленным пакетом Java JDK 1.8, Android Studio и Android SDK;

• смартфон Huawei с USB-кабелем и установленным HMS Core не ниже 4-й версии.

На схеме показан процесс разработки приложения под Android. iOS и веб-приложения поддерживаются в бета-режиме.

Первым делом:

• создаём приложение в AppGallery Connect и проект в Android Studio;

• генерируем криптографический ключ SHA-256;

• сохраняем файл конфигурации приложения;

• подключаем к приложению модуль AppGallery Connect;

• добавляем репозиторий Maven в файл build.gradle.

Подробнее об этих шагах можно почитать здесь, правда, на английском.

Важный момент: чтобы использовать Push Kit для веб-приложений, нужно настроить его через приложение для Android. Кроме того, существуют Quick Apps приложения, не требующие установки, которые можно использовать на мобильных телефонах более 12 крупных производителей в Китае. Все они доступны в AppGallery и поддерживают Push Kit.

Чтобы использовать Push Kit, укажите место для хранения данных вашего проекта. Если его не задать, будут недоступны таргетирование по темам сообщений, рассылка через агент WebPush и работа с iOS.

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

Чтобы уменьшить задержку, есть смысл хранить данные неподалёку от пользователей. Например, если вы в России разрабатываете приложение для жителей из Евросоюза, оптимальным местом для сервера будет Германия.

Интеграция HMS Core SDK

Добавим файл конфигурации вашего приложения в AppGallery Connect.

1. В AppGallery Connect кликаем My project.

2. Находим и выбираем приложение, в которое хотим интегрировать HMS Core SDK.

3. Переходим в Project Setting General information. В App information загружаем файл agconnect-services.json.

4. Копируем файл agconnect-services.json в корневой каталог приложения нашего проекта Android Studio.

Добавим связи сборки. Для этого открываем файл build.gradle в каталоге приложения.

Прописываем в разделе dependencies:

dependencies {    implementation fileTree(dir: 'libs', include: ['*.jar'])    implementation 'androidx.appcompat:appcompat:1.0.2'    implementation 'androidx.constraintlayout:constraintlayout:1.1.3'    testImplementation 'junit:junit:4.12'    androidTestImplementation 'androidx.test:runner:1.1.1'    androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.1'    // Add the following line    implementation 'com.huawei.hms:push:5.0.0.300'}

5.0.0.300 заменим на последнюю версию HMS Core Push SDK.

Нажимаем Sync Now, чтобы синхронизировать файл build.gradle.

Если отображается synced successfully, всё прошло хорошо.

Настройка файла Manifest

Чтобы устройства могли получать токен push и сообщения, отправленные сервером Push Kit, нужно изменить файл AndroidManifest.xml. Определяем класс MyPushService, он наследуется от класса HmsMessageService.

<service    android:name=".MyPushService"    android:exported="false">    <intent-filter>        <action android:name="com.huawei.push.action.MESSAGING_EVENT" />    </intent-filter></service>

В этом примере кода нужно только изменить MyPushService в android: name = ". MyPushService" на имя класса, наследуемого от класса HmsMessageService. Всё остальное сохраняем.

Настройка сценариев шифрования

Открываем файл конфигурации обфускации proguard-rules.pro проекта Android Studio. Добавляем параметры, исключающие из этого процесса HMS Core SDK.

-ignorewarnings-keepattributes *Annotation*-keepattributes Exceptions-keepattributes InnerClasses-keepattributes Signature-keepattributes SourceFile,LineNumberTable-keep class com.hianalytics.android.**{*;}-keep class com.huawei.updatesdk.**{*;}-keep class com.huawei.hms.**{*;}

Если мы используем AndResGuard, его надо добавить в список разрешений в файле c конфигурацией обфускации.

"R.string.agc*","R.string.hms*","R.string.connect_server_fail_prompt_toast","R.string.getting_message_fail_prompt_toast","R.string.no_available_network_prompt_toast","R.string.third_app_*","R.string.upsdk_*","R.layout.hms*","R.layout.upsdk_*","R.drawable.upsdk*","R.color.upsdk*","R.dimen.upsdk*","R.style.upsdk*"

Разрабатываем демо

Ниже показан общий код проекта и структура ресурсов.

Открываем наш проект в Android Studio, создаём виджет и разворачиваем TextView в MainActivity, чтобы отобразить токен. Там же, в MainActivity, программируем метод обновления токена в TextView.

public class MainActivity extends AppCompatActivity {    private TextView tvToken;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        tvToken = findViewById(R.id.tv_log);        MyReceiver receiver = new MyReceiver();        IntentFilter filter=new IntentFilter();        filter.addAction("com.huawei.codelabpush.ON_NEW_TOKEN");        MainActivity.this.registerReceiver(receiver,filter);    }    public class MyReceiver extends BroadcastReceiver {        @Override        public void onReceive(Context context, Intent intent) {            if ("com.huawei.codelabpush.ON_NEW_TOKEN".equals(intent.getAction())) {                String token = intent.getStringExtra("token");                tvToken.setText(token);            }        }    }}

Для подачи заявки на токен объявляем <meta-data> в файле AndroidManifest.xml.

<application    <meta-data        android:name="push_kit_auto_init_enabled"        android:value="true" /></application>

Name и value в meta-data копируем без изменений. Push SDK будет подавать заявку на получение токена при запуске приложения.

Токен получается методом onNewToken в thMyPushService*ce class.

MyPushService.java

public class MyPushService extends HmsMessageService {    private static final String TAG = "PushDemoLog";    @Override    public void onNewToken(String token) {        super.onNewToken(token);        Log.i(TAG, "receive token:" + token);        sendTokenToDisplay(token);    }    private void sendTokenToDisplay(String token) {        Intent intent = new Intent("com.huawei.push.codelab.ON_NEW_TOKEN");        intent.putExtra("token", token);        sendBroadcast(intent);    }}

Класс MyPushService наследуется от HmsMessageService. Он, в свою очередь, переопределяет метод для подтверждения онлайн-статуса устройства onNewToken.

Сборка, загрузка и отладка приложения

Подключаем телефон Huawei к компьютеру.

Способ 1. Нажимаем Play (зелёный треугольник), чтобы начать компиляцию и сборку. Устанавливаем APK на телефон.

Способ 2. Используем Android Studio, чтобы упаковать APK.

Затем используем инструмент ADB, чтобы установить APK на телефон для отладки.

adb install D:\WorkSpace\CodeLab\pushdemo1\app\release\app-release.apk

После запуска демо убеждаемся, что телефон подключён к сети. Метод onNewToken вызываетсядлявозврататокенаAFcSAHhhnxdrMCYBxth2QOG9IgY2VydAM61DTThqNux3KBC_hgzQQT*******.

Токен записывается в журнал демонстрации. Его можно просмотреть, найдя PushDemoLog.

Отправка пуш-уведомлений

В интерфейсе Push Kit в AppGallery Connect можно редактировать сообщения и отправлять их на устройства, подключённые к сети. Перед отправкой уведомлений находим приложение по названию. В этом примере имя APK com.huawei.codelabpush. Подробнее можно прочитать здесь.

Если всё прошло удачно, на экране телефона увидим уведомление.

Коммерческие возможности Push Kit

Почти все известные нам российские кейсы связаны с банковскими учреждениями.

Первой отечественной и второй в мире компанией, интегрировавшей наш Push Kit, стала mfms: их решения по доставке пуш-уведомлений используют ВТБ, Альфа-Банк, Сбер и другие финансовые учреждения России.

Например, в ВТБ пушами клиентам сообщают о денежных операциях в реальном времени. Такие уведомления стоят сильно дешевле SMS, а затраты на внедрение минимальны: с SDK, которое предоставляет mfms, не надо интегрировать APNs, FCM и Huawei Push Kit с нуля.

Пуши используются не только для рассылки. На основе Push Kit в mfms разработали фичу, которая позволяет клиентам банков получать уведомления с подтверждением денежных операций. Такие сообщения рассылаются через SDK и заменяют SMS с кодами для оплаты. Более того, mfms научились превращать эти пуши в красивые уведомления на русском языке с брендированным названием, логотипом и категорией магазина, в котором пользователь совершил оплату.

Какие ещё сферы применения можно найти для пуш-уведомлений и как извлечь из Push Kit больше пользы вопросы не такие уж и сложные, но для нас чрезвычайно интересные. Давайте их обсудим в комментариях: ждём ваши идеи, варианты использования платформы или, возможно, предсказания о будущем пуш-уведомлений.

Single activity подходом при создании конечного приложения под Android никого не удивишь. Но мы пошли дальше и использовали No-Activity при разработке SDK. Сейчас разберемся для чего это понадобилось, возникшие сложности и как их решали.

Стандартные 3rd party SDK в Android

Как обычно работают внешние SDK в Android? Открывается Activity библиотеки, выполняется некая работа, при необходимости возвращается результат в onActivityResult.

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

Получается, что экраны нашего SDK должны быть частью внешнего приложения. Точно также, как вы можете использовать, например, MapFragment от Google. Итого, при стандартном подходе, мы сталкиваемся с рядом трудностей и ограничений.

Проблемы при стандартном подходе к SDK

• Если вам нужно несколько взаимодействий между SDK и приложением, то придется открывать-закрывать Activity от SDK и аккуратно обрабатывать передачу данных туда-обратно.

• Сложно поддержать такой логический порядок экранов, когда элементы приложения чередуются с SDK. (Спойлер: это можно понадобится, но редко).

• При относительно долгом возможном нахождении в SDK внешнее приложение может уйти в Lock Screen. Такое может случиться, если Lock реализован на колбеках жизненного цикла Activity.

No-Activity подход при разработке SDK

Итак, мы решили, что основная проблема в том, что контекст (Activity) внешнего приложения и SDK разные. Отсюда следует резонное решение - отказаться от контекста SDK и во внешнее приложение поставлять только фрагменты. В таком случае разработчик сможет сам управлять стеком экранов.

Данный подход имеет как ряд плюсов, так и значительные минусы. Какие же?

Плюсы No-Acitivty SDK

• Приложение и SDK имеют общий контекст, т.е. для пользователя это выглядит как абсолютно единое приложение.

• Основное приложение имеет свой стек фрагментов, а SDK - свой через childFragmentManager.

• Можно организовать любой порядок экранов и наложений элементов, т.к. навигация доступна и для внешнего приложения.

Минусы No-Acitivty SDK

• Внешнее приложение должно изначально работать с фрагментами, желательно вообще быть Single-Activity.

• У SDK нет своего контекста, если хотите использовать dagger - придется исхитриться (но это все же возможно).

• SDK может влиять на внешнее Acitivty, т.к. requireActivity вернет именно его. Надо полностью доверять SDK.

• Activity будет получать onActivityResult, и, вероятно, придется его прокидывать во фрагменты.

• Разработчику внешнего приложения сложнее интегрировать SDK, т.к. простой вызов Activity уже не сработает.

Использование 3rd party библиотек внутри SDK

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

Dagger2 внутри SDK

Для использования dagger зачастую в приложении используется класс Application. В случае с SDK так сделать не получится, потому что Application, вероятно, будет перетерт со стороны внешнего приложения.

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

internal object ComponentHolder {    lateinit var appComponent: SdkAppComponent        private set    @Synchronized    fun init(ctx: Context) {        if (this::appComponent.isInitialized) return        appComponent = DaggerSdkAppComponent            .builder()            .sdkAppModule(SdkAppModule(ctx))            .build()    }}

Остается только лишь понять, откуда вызвать init, да так, чтобы в процессе жизни SDK быть уверенным, что инициализация выполнилась до любой другой работы. Для этого можно использовать одну точку входа в SDK. Назовем ее EntryPointFragment. Данный фрагмент и будет виден внешнему приложению как единственная точка входа в SDK. Вся дальнейшая навигация внутри SDK будет происходить уже в нем через childFragmentManager.

Как раз при создании EntryPointFragment можно и инициализировать ComponentHolder для Dagger.

override fun onCreate(savedInstanceState: Bundle?) {        ComponentHolder.init(requireActivity())        ComponentHolder.appComponent.inject(this)        super.onCreate(savedInstanceState)    }

Итого, на выходе мы получили ComponentHolder, который можно использовать внутри SDK для инъекции нужных компонент.

Устранение коллизии в версиях

С данной проблемой столкнулись при обновлении версии okhttp3 до новой major версии 4.+. В ней добавили улучшенную поддержку Kotlin, в том числе, например, доступ к коду ошибки через code() теперь стало ошибкой. Клиенты SDK, используя либо 3, либо 4 версию должны получать ту же внутри SDK, иначе все сломается.

Это реально сделать, вынеся код с коллизиями в отдельный модуль. В нем будут 2 flavor:

    flavorDimensions("okhttpVersion")    productFlavors {        v3 {            dimension = "okhttpVersion"        }        v4 {            dimension = "okhttpVersion"        }    }        dependencies {        v3Api okhttp3.core        v3Api okhttp3.logging        v4Api okhttp4.core        v4Api okhttp4.logging}

В двух разных папках, отвечающих за каждый flavor будут одинаковые классы, один из которых будет использовать code() а другой code.

// Code in v3 folderclass ResponseWrapper(private val response: Response) {    val code : Int        get() = response.code()}

// Code in v4 folderclass ResponseWrapper(private val response: Response) {    val code : Int        get() = response.code}

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

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

defaultConfig {...missingDimensionStrategy 'okhttpVersion', 'v4'}

В таком случае вы избавитесь от конфликта при сборке. Иначе просто версия не найдется.

Заключение

Разработка SDK, если сравнивать с просто Android приложением, намного сложнее, но порой интереснее. Также требования к качеству конечного продукта выше - если что-то упадет, то упадет не у вас, а у вашего клиента, что прямо очень плохо.

В Android существуют стили и темы которые позволяют структурировать разработку пользовательского интерфейса.

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

Пример объявления атрибута из Android SDK:

<attr name="background" format="reference|color" />

Темы vs стили

Темы и стили очень похожи, но используются для разных целей.

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

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

Стили и темы предназначены для совместной работы.

Например, у нас есть стиль, в котором фон кнопки - colorPrimary, а цвет текста - colorSecondary. Фактические значения этих цветов приведены в теме.

<?xml version="1.0" encoding="utf-8" ?><resources xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"><style name="LightTheme" parent="YourAppTheme"><item name="colorPrimary">#FFFFFF</item><item name="colorSecondary">#000000</item></style><style name="DarkTheme" parent="YourAppTheme"><item name="colorPrimary">#000000</item><item name="colorSecondary">#FFFFFF</item></style><style name="Button.Primary" parent="Widget.MaterialComponents.Button"><item name="android:background">?attr/colorPrimary</item><item name="android:textColor">?attr/colorSecondary</item></style></resources>

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

Нет необходимости менять стили, так как стили используют семантические имена, а не конкретные цветовые ресуры.

Виды ссылок в XML

Атрибут android:background может принимать несколько типов:

android:background="@color/colorPrimary"android:background="?attr/colorPrimary"

В случае с @color/colorPrimary - мы cсылаемся на цветовой ресурс colorPrimary, а точнее на <color name="colorPrimary">#FFFFFF<color> строку, которая прописана в res/values/color.xml файле.

В свою очередь, ?attr - это ссылка на аттрибут темы.

?attr/colorPrimary указывает на colorPrimary атрибут, который находится в текущей теме:

<?xml version="1.0" encoding="utf-8" ?><resources xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"><style name="YourAppTheme" parent="Theme.AppCompat.Light.NoActionBar"><item name="colorPrimary">@color/colorPrimary</item></style></resources>

Преимущество ?attr ссылок в том, что они будут меняться в зависимости от выбранной темы.

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

Всегда старайтесь ссылаться на цветовые ресурсы через атрибуты темы

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

Структура ссылок

@[package:]type/name

1. package - (опционально) название пакета в котором находиться ресурс. По умолчанию - это пакет приложения, в котором находится ресурс.

2. type - может быть одним из color, string, dimen, layout или какого-либо другого типа ресурса. Более подробно читайте здесь.

3. name - имя ресурса, используется как идентификатор ресурса.

?[package:]type/name

1. package - (опционально) название пакета в котором находиться ресурс. По умолчанию - это пакет приложения, в котором находится ресурс.

2. type - (опционально) всегда attr когда используем ?.

3. name - имя ресурса, используется как идентификатор ресурса.

? vs ?attr vs ?android:attr

Возможно, вы замечали, что к некоторым атрибутам можно обратиться как ?android:attr/colorPrimary, так и ?attr/colorPrimary, а также ?colorPrimary.

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

Мы можем использовать ? и ?attr в случае, когда эти атрибуты находятся в библиотеках(Например, в AppCompat или MaterialDesign), которые компилируюся в приложение, поэтому пространство имен не требуется.

Некоторые элементы определены и в Android SDK, и в библиотеке, например colorPrimary.

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

Полезные ссылки

Ниже список с интересными статьями о стилях и темах от Google Android разработчиков:

1. Theming with AppCompat

2. Android styling: themes vs styles

3. Whats your texts appearance?

4. Android Styling: themes overlay

5. Android Styling: prefer theme attributes

6. Android styling: common theme attributes

Рекомендую ещё к просмотру видео с Android Dev Summit 2019 года. Ссылка на видео

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

Наконец, в 2020 году Google представила решение старой проблемы Activity Result API. Это мощный инструмент для обмена данными между активностями и запроса runtime permissions.

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

Чем плох onActivityResult()?

Роберт Мартин в книге Чистый код отмечает важность переиспользования кода принцип DRY или Dont repeat yourself, а также призывает проектировать компактные функции, которые выполняют лишь единственную операцию.

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

class OldActivity : AppCompatActivity(R.layout.a_main) {   override fun onCreate(savedInstanceState: Bundle?) {       super.onCreate(savedInstanceState)       vButtonCamera.setOnClickListener {           when {               checkSelfPermission(Manifest.permission.CAMERA) == PackageManager.PERMISSION_GRANTED -> {                   // доступ к камере разрешен, открываем камеру                   startActivityForResult(                       Intent(MediaStore.ACTION_IMAGE_CAPTURE),                       PHOTO_REQUEST_CODE                   )               }               shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {                   // доступ к камере запрещен, нужно объяснить зачем нам требуется разрешение               }               else -> {                   // доступ к камере запрещен, запрашиваем разрешение                   requestPermissions(                       arrayOf(Manifest.permission.CAMERA),                       PHOTO_PERMISSIONS_REQUEST_CODE                   )               }           }       }       vButtonSecondActivity.setOnClickListener {           val intent = Intent(this, SecondActivity::class.java)               .putExtra("my_input_key", "What is the answer?")           startActivityForResult(intent, SECOND_ACTIVITY_REQUEST_CODE)       }   }   override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {       when (requestCode) {           PHOTO_REQUEST_CODE -> {               if (resultCode == RESULT_OK && data != null) {                   val bitmap = data.extras?.get("data") as Bitmap                   // используем bitmap               } else {                   // не удалось получить фото               }           }           SECOND_ACTIVITY_REQUEST_CODE -> {               if (resultCode == RESULT_OK && data != null) {                   val result = data.getIntExtra("my_result_extra")                   // используем result               } else {                   // не удалось получить результат               }           }           else -> super.onActivityResult(requestCode, resultCode, data)       }   }   override fun onRequestPermissionsResult(       requestCode: Int,       permissions: Array<out String>,       grantResults: IntArray   ) {       if (requestCode == PHOTO_PERMISSIONS_REQUEST_CODE) {           when {               grantResults[0] == PackageManager.PERMISSION_GRANTED -> {                   // доступ к камере разрешен, открываем камеру                   startActivityForResult(                       Intent(MediaStore.ACTION_IMAGE_CAPTURE),                       PHOTO_REQUEST_CODE                   )               }               !shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {                   // доступ к камере запрещен, пользователь поставил галочку Don't ask again.               }               else -> {                   // доступ к камере запрещен, пользователь отклонил запрос               }           }       } else {           super.onRequestPermissionsResult(requestCode, permissions, grantResults)       }   }   companion object {       private const val PHOTO_REQUEST_CODE = 1       private const val PHOTO_PERMISSIONS_REQUEST_CODE = 2       private const val SECOND_ACTIVITY_REQUEST_CODE = 3   }}

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

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

Используем Activity Result API

Новый API доступен начиная с AndroidX Activity 1.2.0-alpha02 и Fragment 1.3.0-alpha02, поэтому добавим актуальные версии соответствующих зависимостей в build.gradle:

implementation 'androidx.activity:activity-ktx:1.3.0-alpha02'implementation 'androidx.fragment:fragment-ktx:1.3.0'

Применение Activity Result состоит из трех шагов:

Шаг 1. Создание контракта

Контракт это класс, реализующий интерфейс ActivityResultContract<I,O>. Где I определяет тип входных данных, необходимых для запуска Activity, а O тип возвращаемого результата.

Для типовых задач можно воспользоваться реализациями из коробки: PickContact, TakePicture, RequestPermission и другими. Полный список доступен тут.

При создании контракта мы обязаны реализовать два его метода:

• createIntent() принимает входные данные и создает интент, который будет в дальнейшем запущен вызовом launch()

• parseResult() отвечает за возврат результата, обработку resultCode и парсинг данных

Ещё один метод getSynchronousResult() можно переопределить в случае необходимости. Он позволяет сразу же, без запуска Activity, вернуть результат, например, если получены невалидные входные данные. Если подобное поведение не требуется, метод по умолчанию возвращает null.

Ниже представлен пример контракта, который принимает строку и запускает SecondActivity, ожидая от неё целое число:

class MySecondActivityContract : ActivityResultContract<String, Int?>() {   override fun createIntent(context: Context, input: String?): Intent {       return Intent(context, SecondActivity::class.java)           .putExtra("my_input_key", input)   }   override fun parseResult(resultCode: Int, intent: Intent?): Int? = when {       resultCode != Activity.RESULT_OK -> null       else -> intent?.getIntExtra("my_result_key", 42)   }   override fun getSynchronousResult(context: Context, input: String?): SynchronousResult<Int?>? {       return if (input.isNullOrEmpty()) SynchronousResult(42) else null   }}

Шаг 2. Регистрация контракта

Следующий этап регистрация контракта в активности или фрагменте с помощью вызова registerForActivityResult(). В параметры необходимо передать ActivityResultContract и ActivityResultCallback. Коллбек сработает при получении результата.

val activityLauncher = registerForActivityResult(MySecondActivityContract()) { result ->   // используем result}

Регистрация контракта не запускает новую Activity, а лишь возвращает специальный объект ActivityResultLauncher, который нам понадобится далее.

Шаг 3. Запуск контракта

Для запуска Activity остаётся вызвать launch() на объекте ActivityResultLauncher, который мы получили на предыдущем этапе.

vButton.setOnClickListener {   activityLauncher.launch("What is the answer?")}

Важно!

Отметим несколько неочевидных моментов, которые необходимо учитывать:

• Регистрировать контракты можно в любой момент жизненного цикла активности или фрагмента, но вот запустить его до перехода в состояние CREATED нельзя. Общепринятый подход регистрация контрактов как полей класса.

• Не рекомендуется вызывать registerForActivityResult() внутри операторов if и when. Дело в том, что во время ожидания результата процесс приложения может быть уничтожен системой (например, при открытии камеры, которая требовательна к оперативной памяти). И если при восстановлении процесса мы не зарегистрируем контракт заново, результат будет утерян.

• Если запустить неявный интент, а операционная система не сможет найти подходящую Activity, выбрасывается исключение ActivityNotFoundException: No Activity found to handle Intent. Чтобы избежать такой ситуации, необходимо перед вызовом launch() или в методе getSynchronousResult() выполнить проверку resolveActivity() c помощью PackageManager.

Работа с runtime permissions

Другим полезным применением Activity Result API является запрос разрешений. Теперь вместо вызовов checkSelfPermission(), requestPermissions() и onRequestPermissionsResult(), стало доступно лаконичное и удобное решение контракты RequestPermission и RequestMultiplePermissions.

Первый служит для запроса одного разрешения, а второй сразу нескольких. В колбеке RequestPermission возвращает true, если доступ получен, и false в противном случае. RequestMultiplePermissions вернёт Map, где ключ это название запрошенного разрешения, а значение результат запроса.

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

Зачастую разработчики забывают о следующих нюансах при работе с runtime permissions:

• Если пользователь ранее уже отклонял наш запрос, рекомендуется дополнительно объяснить, зачем приложению понадобилось данное разрешение (пункт 5a)

• При отклонении запроса на разрешение (пункт 8b), стоит не только ограничить функциональность приложения, но и учесть случай, если пользователь поставил галочку Don't ask again

Обнаружить эти граничные ситуации можно при помощи вызова метода shouldShowRequestPermissionRationale(). Если он возвращает true перед запросом разрешения, то стоит рассказать пользователю, как приложение будет использовать разрешение. Если разрешение не выдано и shouldShowRequestPermissionRationale() возвращает false была выбрана опция Don't ask again, тогда стоит попросить пользователя зайти в настройки и предоставить разрешение вручную.

Реализуем запрос на доступ к камере согласно рассмотренной схеме:

class PermissionsActivity : AppCompatActivity(R.layout.a_main) {   val singlePermission = registerForActivityResult(RequestPermission()) { granted ->       when {           granted -> {               // доступ к камере разрешен, открываем камеру           }           !shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {               // доступ к камере запрещен, пользователь поставил галочку Don't ask again.           }           else -> {               // доступ к камере запрещен, пользователь отклонил запрос           }       }   }   override fun onCreate(savedInstanceState: Bundle?) {       super.onCreate(savedInstanceState)       vButtonPermission.setOnClickListener {           if (shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) {               // доступ к камере запрещен, нужно объяснить зачем нам требуется разрешение           } else {               singlePermission.launch(Manifest.permission.CAMERA)           }       }   }}

Подводим итоги

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

class NewActivity : AppCompatActivity(R.layout.a_main) {   val permission = registerForActivityResult(RequestPermission()) { granted ->       when {           granted -> {               camera.launch() // доступ к камере разрешен, открываем камеру           }           !shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {               // доступ к камере запрещен, пользователь поставил галочку Don't ask again.           }           else -> {               // доступ к камере запрещен           }       }   }   val camera = registerForActivityResult(TakePicturePreview()) { bitmap ->       // используем bitmap   }   val custom = registerForActivityResult(MySecondActivityContract()) { result ->       // используем result   }   override fun onCreate(savedInstanceState: Bundle?) {       super.onCreate(savedInstanceState)       vButtonCamera.setOnClickListener {           if (shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) {               // объясняем пользователю, почему нам необходимо данное разрешение           } else {               permission.launch(Manifest.permission.CAMERA)           }       }       vButtonSecondActivity.setOnClickListener {           custom.launch("What is the answer?")       }   }}

Мы увидели недостатки обмена данными через onActivityResult(), узнали о преимуществах Activity Result API и научились использовать его на практике.

Новый API полностью стабилен, в то время как привычные onRequestPermissionsResult(), onActivityResult() и startActivityForResult() стали Deprecated. Самое время вносить изменения в свои проекты!

Демо-приложение с различными примерами использования Activty Result API, в том числе работу с runtime permissions, можно найти в моем Github репозитории.