Intent filter verification Xiaomi что это

Я прочитал много статей о фильтрах намерений, и я действительно не могу точно понять, что они делают?

так что, пожалуйста, если кто-нибудь может объяснить мне на четком примере, какова роль фильтров намерений?

user235123 03 июл ’10 в 16:55 2010-07-03 16:55
2010-07-03 16:55

7 ответов

Я думаю, что это хорошо задокументировано здесь. Подводя итог, когда (например) вы передаете намерение в Context.startActivity или Context.startService или транслируете его с помощью Context.sendBroadcast и т. Д., К какой деятельности или услуге (или к какому набору приемников широковещания) доставляется намерение?

Ответ: если намерение является «явным», т. Е. У него установлено поле имени компонента, то оно доставляется целевому компоненту, который оно обозначает — это обычно происходит при обмене данными внутри приложения.

В противном случае («неявное» намерение, как это характерно для связи между приложениями), Android должен сам определить лучшую активность или службу (или набор получателей). Как Android это делает? Вот тут и вступают фильтры, и я цитирую:

Start Аndroid: Урок 22. Intent, Intent Filter, Context — теория. (уроки по андроид)

Это достигается путем сравнения содержимого объекта Intent с фильтрами намерений, структурами, связанными с компонентами, которые потенциально могут получать намерения. Фильтры объявляют о возможностях компонента и разграничивают его намерения. Они открывают компонент для возможности получения неявных намерений рекламируемого типа. Если у компонента нет фильтров намерений, он может получать только явные намерения. Компонент с фильтрами может получать как явные, так и неявные намерения.

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

Источник: stackru.com

Intent filter verification service что это

Немного странно, как по мне…

Разбираемся

Удалось выяснить, что Intent Filter Verification Service — системный сервис для проверки доступности ссылок, которые заявлены как дефолтные для некоторых приложений. Сервис используется при установке вот таких приложений. Эту инфу нашел на форуме 4PDA, инфе думаю можно доверять. Вообще вот это сообщение юзера, который видимо шарит:

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

Описание номер два — более понятным языком. В некотором смысле эта прога позволяет системе понять — что делать с ссылкой, они ведь бывают разные.. Например пришла ссылка в смс-ке на… ну пусть будет Ютуб. Вы нажали — открылось приложение Ютуб. Второй пример — пришла ссылка на приложение Андроид, вы нажали — открылся Плей Маркет.

Урок 22. Что такое Intent, Intent Filter, Context

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

Доступ в интернет приложению вряд ли нужен.

Но также нашел инфу — пишет уже другой чел, что эта служба нужна для обмена данными между приложениями:

Подробнее — ссылка ведет на материал Объекты Intent и фильтры объектов Intent. Важно то, что ссылка официальная, ибо сайт — developer.android.com. Поэтому при желании — можете глянуть.

Один чел пишет — у него тормозил интернет, браузеры оч медленно работали. Что он сделал? Заморозил приложения Intent Filter Verification Service, Диспетчер телефона, Служба диспетчера телефона, после — выполнил перезагрузку. В итоге любой браузер летает по интернету. Инфа на заметку))

Внимание! У одного чела после отключения Intent Filter Verification Service телефон начал зависать на заставке. Отключение производилось штатными средствами. Вывод — возможно реально после отключения будут глюки, но они могут отсутствовать при заморозке. Так что пробовать на свой страх и риск!

Снова нашел на форуме 4PDA описание приложения, в этот раз кажется уже понятно станет:

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

Ребята — удалять нельзя, вот вам коммент:

Нашел его на форуме 4PDA.

По поводу удаления

Значит удалять как я понял — не стоит. Могут быть глюки. Дело в том, что при некоторых глюках — можно все исправить, включить приложение обратно. Но что делать, если тел будет постоянно перезагружаться? Зависать при включении?

Такая проблема для вас может обернуться гемором(( Поэтому просто так, без необходимости — отключить не стоит..

Однако, если все же заморозить хочется — то на свой страх и риск:

1. Вообще мастер по заморозке и отключению приложений — Titanium Backup. Но требует некого опыта и если не ошибаюсь — нужен рут-доступ.
   Для заморозки найдите приложение, потом выберите его и в окошке нажмите Заморозка. Удалять не советую — писал почему.
2. Перед заморозкой лучше сделать бэкап. Страховка никогда не помешает.
3. Можно попробовать заморозить без рута при помощи приложения App Freezer.

Вывод

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

Надеюсь информация была полезной. Удачи и добра!

— вызываем Activity, используя неявный вызов и Intent Filter

Последние уроки получились перегруженными теорией. Эту теорию необходимо понять, чтобы не было проблем с практикой. Эти темы являются основой – Task, Lifecycle, Intent. Если что-либо осталось непонятно, то вы всегда можете снова открыть и перечитать материал. А далее мы будем реализовывать примеры, которые будут эту теорию подтверждать и все станет понятнее.

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

Давайте посмотрим, как это реализуется на практике. Мы создадим приложение, которое будет отображать нам текущее время или дату. Сделаем мы это с помощью трех Activity:
— первое будет содержать две кнопки: Show time и Show date
— второе будет отображать время
— третье будет отображать дату

Нажатие на кнопку Show time будет вызывать второе Activity, а нажатие на кнопку Show date – третье Activity. Но реализуем мы это не через прямое указание классов Activity в Intent, а через Intent Filter.

Layout-файл назовем date.xml:

Все сохраняем, запускаем приложение, жмем Show date и видим дату. Это значит, что Intent с action = ru.startandroid.intent.action.showdate нашел и отобразил ActivityDate подходящее ему по Intent Filter.

Чтобы закрепить тему, проделаем еще кое-что. Если помните, в уроке №22, где я рассказывал про Intent Filter, я говорил, что один Intent может найти несколько подходящих Activity. В этом случае пользователю предоставляется выбор, какое Activity использовать. Давайте сами спровоцируем такой случай.

Мы сделаем еще одно Activity, которое будет реагировать на Intent с action = ru.startandroid.intent.action.showdate. И будет отображать текущую дату аналогично ActivityDate. Но формат отображения даты будет немного другой.

Давайте создадим такое Activity, назовем его ActivityDateEx. Действия все те же самые, что и при создании ActivityDate:
— создание класса
— создание Activity в манифесте и создание для него Intent Filter (с action = ru.startandro >

Новый layout-файл создавать не будем, используем уже существующий date.xml. В принципе, все три Activity у нас могли использовать один layout, т.к. они совершенно одинаковы – один TextView.

Как видим, отличие от ActivityDate только в формате даты.

Сохраним все и запустим. Жмем Show date и видим такой выбор:

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

Нажмите Back, чтобы закрыть диалог выбора. Идем в манифест и для Activity пропишем label:

Date basic для ActivityDate
Date extended для ActivityDateEx

Сохраняем и запускаем. Жмем Show date и видим такой выбор:

Так значительно лучше. Жмем Date extended и видим дату в расширенном формате на ActivityDateEx.

Итак, мы создавали и посылали Intent с action. Этот Intent находил Activity с подходящим Intent Filter и отображал его. Если находил несколько – давал выбор. Примеры отлично показывают механизм.

Если запутались, чего и где создавать, привожу скрин проекта и содержимое манифеста.

Содержимое манифеста (вкладка AndroidManifest.xml):

На следующем уроке:

— читаем action из Intent

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

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

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

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

HwLBSService (com.huawei.lbs.HwLBSService), а также GeofenceService — собственные сервисы Huawei, нужны для определения местоположения смартфона во время блокировки. Соответственно могут использовать модуль GPS.

Отключение под вопросом (читать ниже).

Может активно использовать батарею. Один юзер отключил, пишет — глюков/лагов не наблюдает, телефон работает в штатном режиме, звонки принимает, GPS работает.

HwLBSService может иметь доступ к отпечатков пальцев, при этом отправлять данные на такие сервера:

• connectivitycheck.android.com
• streamback.ff.avast.com
• www.google.com

Как видим — адреса легальные, вирусное/подозрительное отсутствует.

Для энергосбережения HwLBSService вроде как можно отключить.

Нашел PDF файл Декларация соответствия, в котором идет перечень приложений телефона и их описание. Присутствует и HwLBSService, в описании сказано — Intent Filter Verification Service.

Погуглив, выяснил: Intent Filter Verification Service — системный сервис проверки доступности дефолтных ссылок приложений, комментарий форума 4PDA:

Простыми словами: имеется ввиду ссылки не в прямом смысле. Например пришло сообщение с любым веб-адресом. Android должен понять — это адрес и его нужно открывать браузером. Пример #2 — пришла СМС-ка, в содержании — номер телефона. Android должен понимать — по телефону можно позвонить Скайпом, Вайбером, в итоге выдаст запрос-предложение.

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

Минутку! Мое мнение — HwLBSService это определение георасположения, а не Intent Filter Verification Service. Все источники мной найденные — указывают именно на первый вариант.

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

Как отключать/удалить?

Внимание! На форуме 4PDA нашел сообщение — при попытке отключить одно из приложений EUIReceive, HwChrService, androidhwext, HwLBSService — может произойти бутлуп (цикличная перезагрузка):

Вывод — сперва делаем бэкап, после уже отключаем.

1. Попробуйте отключить стандартным способом в списке приложений, если оно присутствует.
2. Используйте титаниум (Titanium Backup) — лучшее средство для удаления, заморозки приложений, в том числе системных. Минус — нужны root-права.
3. Можно использовать и Lucky Patcher — аналог титаниума, также умеет прекрасно морозить приложения. Нужен рут.
4. Важно — отключение под вопросом из-за риска бутлупа. Разве что только при наличии бэкапа.

Заключение

1. HwLBSService — сервис определения георасположения.
2. Отключение под вопросом. Хотя юзеры писали — выключали, проблем не наблюдали. Но нет гарантий их отсутствия на вашем устройстве.

Надеюсь информация пригодилась. Удачи и добра!

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Источник: auto-technologies.ru

Android 12: история поддержки

Всем привет! Меня зовут Максим Новиков, я Android-разработчик в команде мобильного оператора Yota.

Совсем недавно вышла новая версия всеми нами любимой OS. Вот и пришло время нашему приложению поддержать её. Было очень много обзоров на новые возможности Android 12, а также изменений для разработчиков. Сегодня я расскажу про наш тернистый путь. Наливайте чай/кофе и готовьтесь к увлекательному погружению в мир Android.

До поддержки

Главный вопрос: сможет ли приложение работать без какой-либо адаптации? Берём приложение без какой-либо поддержки и устанавливаем на девайс с Android 12. В нашем случае это Pixel 3a XL.

Конкретно у нас появилась ошибка, связанная с получением параметров экрана через ApplicationContext. Кому интересно небольшое расследование, прошу под спойлер.

Разбор ошибки

Смотрим логи. Появилась новая ошибка:

Смотрим на эту строчку

com.splunk.mint.Utils.getScreenOrientation(Utils.java:63)

и понимаем, что корни ошибки идут из библиотеки com.splunk.mint, в которую мы уже передаём контекст приложения.

Проведя исследование кода библиотеки, указанного в логе, видим, что проблема в следующем:

Display display = ((WindowManager)gContext.getSystemService(«window»)).getDefaultDisplay()

Естественно, поскольку это выглядит как краш, было ощущение, что часть функционала библиотеки теперь не будет работать. Однако, если посмотреть сам код функци getSystemService в ContextImpl.java.

Увидим, что ошибка создаётся, отправляется в StrictMode и логируется, но при этом никак не влияет на создание WindowManager. Также сами протестируем работоспособность кода из библиотеки

val windowManager = applicationContext.getSystemService(Context.WINDOW_SERVICE) as WindowManager val rotation = windowManager.defaultDisplay.rotation Log.d(«rotation = $rotation»)

Немного посмотрев документацию, видим, что начиная с Android 12 следует использовать Context#getDisplay(). А уже он приводит к падению, если мы используем его не из нужного контекста.

Из всего этого делаем вывод, что теперь получить Display можно только из Visual Context, которым у нас является Activity.

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

Начало

Первый шаг для поддержки новой версии OS — это поднятие compileSdkVersion и targetSdkVersion. В нашем случае до 31.

СompileSdkVersion отвечает за то, под какую версию компилируется ваш проект. От этого, например, зависят разные lint rules и inspections.

От targetSdkVersion зависит то, как сама OS будет реагировать на ваше приложение, делать какие-то обратные совместимости и так далее.

При компиляцие проекта видим ошибку, которая говорит нам, что необходимо явно проставить android:exported у Activity.

Manifest merger failed: android:exported needs to be explicitly specified for activity. Apps targeting Android 12 and higher are required to specify an explicit value for android:exported when the corresponding component has an intent filter defined. See https://developer.android.com/guide/topics/manifest/activity-element#exported for details.

Кроме activity такая же логика теперь работает для service и broadcast receiver у которых есть intent-filter.

Итак, собираем и устанавливаем приложение.

Получаем краш при старте приложения.

java.lang.IllegalArgumentException: ru.yota.android: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.

Причём PendingIntent не используется на старте приложения. Однако, запускаются отложенные действия при помощи WorkManager версии 2.5.0, в котором как раз используется PendingIntent, но новое изменение с флагами не поддержано.

Заходя в документацию видим следующее:

Обновляемся до 2.7.0. Запускаем приложение.

Оно запустилось, но теперь начинают сыпаться ANR.

Смотрим в логи, видим:

java.lang.RuntimeException: Unable to create service com.yandex.metrica.ConfigurationJobService: java.lang.IllegalArgumentException: ru.yota.android: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.

Делаем вывод, что Yandex Metrica создаёт PendingIntent без указания флагов мутабильности. Это связано с тем, что в версии 3.13.1 не было поддержки этих флагов.

Обновляемся до последней версии — 4.0.0.

Хотелось бы отметить, что эта библиотека была блокером на пути поддержки Android 12. Поскольку это обновление вышло не за долго до официального релиза OS.

Заодно, проходимся текстовым поиском по “PendingIntent” и добавляем флаг PendingIntent.FLAG_IMMUTABLE. Из-за того, что у нашего приложения minsdk 22 необходимо прописывать:

if (VERSION.SDK_INT >= VERSION_CODES.M)

Ура! всё наконец-то заработало!

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

Deep links

Наткнулся на безобидный абзац не говорящий ничего конкретного:

Android App Links verification changes

On apps that target Android 12 or higher, the system makes several changes to how Android App Links are verified. These changes improve the reliability of the app-linking experience and provide more control to app developers and end users.

If you rely on Android App Link verification to open web links in your app, check that you use the correct format when you add intent filters for Android App Link verification. In particular, make sure that these intent filters include the BROWSABLE category and support the https scheme.

Но изменения оказались очень значимыми для пользователя.

Теперь, если у вашего приложения не настроен auto verify ваших диплинков, при переходе по ним будет открываться ВСЕГДА браузер, без показа диалога выбора: приложение или браузер.

Чтобы это изменить, пользователю необходимо идти в настройки

apps/Default Apps/Opening Links/выбор приложения.

Либо в информации о приложении открывать Open by default. И уже там добавить вашу схему диплинка в verified нажав Add Link и выбрав её:

После этого, по нажатию на диплинк вашего приложения будет открываться ВСЕГДА приложение, без какого-либо диалога.

Чтобы пользователю не приходилось проделывать все эти манипуляции (которые он, конечно же, скорее всего делать не будет), существует настройка auto verify.

В Android Studio встроен хороший инструмент, который очень упрощает нужную настройку. Находиться он в Tools -> App Links Assistant.

Если вкратце, то нам нужно сформировать файл assetlinks.json, который необходимо залить на сайт по пути:

https://$/.well-known/assetlinks.json
[ < «relation»: [ «delegate_permission/common.handle_all_urls» ], «target»: < «namespace»: «android_app», «package_name»: «$», «sha256_cert_fingerprints»: [%$ ] > > ]

И не забыть добавить параметр в ваш intent-filter:

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

adb shell pm get-app-links $

Если возникли, какие-то сложности полная инструкция есть здесь.

Splash screen

Когда мы запускаем приложение, происходит процесс загрузки ресурсов и классов. В этот момент ещё не произошла отрисовка контента первого Activity. Вместо него мы видим окно, которое раскрашено в тему Activity. Оно называется Splash Screen.

Раньше было 2 основных решения для splash screen:

1. Делаем отдельное splash activity с темой и устанавливаем туда android:windowBackground;
2. У стартовой activity устанавливаем также тему с android:windowBackground в manifest и меняем её до вызова super.onCreate в activity. Особенно популярно в Single Activity подходе, когда во всём приложении у нас только одно Activity.

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

У Activity появился getter, который возвращает интерфейс для настройки SplashView:

public final SplashScreen getSplashScreen()

Итак пытаемся запустить splash screen.

В целом всё нормально. Однако, при длительном запуске activity, происходит следующее:

1. у платформенного splash есть ограниченное время, и если система запускает приложение очень долго, то будет смена на старый background.
2. лого стало чуть больше;

Чтобы продлить показ Splash Screen Google рекомендует следующее решение и не забываем делать это только для Android 12 и выше.

решение от Google

// Create a new event for the activity. override fun onCreate(savedInstanceState: Bundle?) < super.onCreate(savedInstanceState) // Set the layout for the content view. setContentView(R.layout.main_activity) if (VERSION.SDK_INT >= VERSION_CODES.S) < // Set up an OnPreDrawListener to the root view. val content: View = findViewById(android.R.id.content) content.viewTreeObserver.addOnPreDrawListener( object : ViewTreeObserver.OnPreDrawListener < override fun onPreDraw(): Boolean < // Check if the initial data is ready. return if (viewModel.isReady) < // The content is ready; start drawing. content.viewTreeObserver.removeOnPreDrawListener(this) true >else < // The content is not ready; suspend. false >> > ) > >
Или же чуть-чуть элегантнее:
// Create a new event for the activity. override fun onCreate(savedInstanceState: Bundle?) < super.onCreate(savedInstanceState) // Set the layout for the content view. setContentView(R.layout.main_activity) if (VERSION.SDK_INT >= VERSION_CODES.S) < // Set up an OnPreDrawListener to the root view. val content: View = findViewById(android.R.id.content) val onPreDrawListener = OnPreDrawListener < false >content.viewTreeObserver.addOnPreDrawListener(onPreDrawListener) viewModel.isReadyState.observe(this) < isReady ->if (isReady) < content.viewTreeObserver.removeOnPreDrawListener(onPreDrawListener) >> > >

Из минусов этого решения: при открытии приложения не с иконки, платформенный splash screen остаётся без лого.

Слева Android 11, справа Android 12

С временем отображения лого разобрались.

Увеличение лого в целом не критично, но перфекционист во мне стал негодовать и решил с этим разобраться.

Для этого версионируем нашу тему с помощью папки value-v31:

Теперь с помощью свойства windowSplashScreenAnimatedIcon можем менять размер лого. Соответственно, для этого добавляем версионирование для лого в drawable-v31.

Подробнее по свойствам можно почитать здесь.

Ровно в день, когда хотели публиковать статью, вышло обновление на Samsung. И увидели мы следующее:

Лого стало заметно меньше. Причём, если убрать фикс для размера, то всё возвращается в норму.

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

С фиксами всё. Что ещё нового?

Для обратной совместимости анимаций появилась специальная библиотека. На момент написания статьи она находилась ещё в альфе.

implementation ‘androidx.core:core-splashscreen:1.0.0-alpha02’

Хотелось бы отметить, что добавили lint правило CustomSplashScreen, которое смотрит на ваши классы. Если в названии класса присутствует SplashActivity, то появляется ошибка:

Новая политика GEO разрешений

По Android 11 включительно запрос разрешения ACCESS_FINE_LOCATION выдавал только его одно:

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

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

Далее у нас открываются следующие пути действий:

1. Запрашивать только приблизительное местоположение.
2. Обрабатывать оба разрешения и подстраивать наш функционал в зависимости от того, какое разрешение дал пользователь;
3. Запрашивать оба разрешения, если пользователь дал только приблизительное, запрашивать ешё раз.

Путь 1 будет достаточен, если, к примеру, вам необходимо определить город пользователя. Если же вам нужно показать какие-то точки в городе, можно использовать путь 2. Путь 3 нужен только узкоспециализированным приложениям, в которых важна точность. Например для такси или приложениям для безопасности детей.

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

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

имплементация

fun locationUpdates() < val locationProvider: FusedLocationProviderClient = LocationServices.getFusedLocationProviderClient(context) val locationRequest = LocationRequest.create().apply < priority = LocationRequest.PRIORITY_HIGH_ACCURACY interval = 5L * 1000L fastestInterval = 2000L >val locationCallback = object : LocationCallback() < override fun onLocationResult(locationResult: LocationResult?) < // handle new location here locationResult?.lastLocation super.onLocationResult(locationResult) >> locationProvider.requestLocationUpdates( locationRequest, locationCallback, Looper.getMainLooper() ) >

В ходе проб и ошибок выяснил, что необходимо будет по разному конфигурировать создание LocationRequest в зависимости от того, какое разрешение было получено. Если было получено приблизительное местоположение, и ранее не была получена никакая локация, то при priority = LocationRequest.PRIORITY_HIGH_ACCURACY, ваше приложение не получит локацию пользователя. В этом случае нам необходимо либо
PRIORITY_BALANCED_POWER_ACCURACY(уровень квартала) либо PRIORITY_LOW_POWER (уровень города). Также желательно увеличивать интервалы получения координат. Более подробную информацию можно посмотреть здесь.

Что же нужно было для поддержки

• обновить Work Manger до 2.7.0;
• обновить App Metrica до 4.0;
• добавить всем PendingIntent флаг мутабильности;
• поддержать auto verify, добавить файл конфигурации на сайт и докрутить конфигурацию intent-filter;
• добавить версионированную тему для сплеша;
• выбрать свой путь работы с geo и следовать ему.

Заключение

По моим ощущениям Android 12 вышла интересной и приносящей много нового, как для пользователей, так и для разработчиков. Не обошлось без сложностей, как например со Splash screen. Также хотелось бы отметить, что наше приложение покрывает не абсолютно все кейсы. Например, нам не пришлось обрабатывать новый permission для точных будильников. Надеюсь эта статья поможет вам быстрее разобраться с обновлением и поддержкой изменений Android 12!

Источник: habr.com