Обновляемся на новую версию API Android по наставлению Google
Скоро выходит Android 12, но в этом августе уже с 11-й версии разработчикам придётся использовать новые стандарты доступа приложений к внешним файлам. Если раньше можно было просто поставить флаг, что ваше приложение не поддерживает нововведения, то скоро они станут обязательными для всех. Главный фокус — повышение безопасности.
Переход на новую версию API — довольно трудоёмкая операция, требующая больших затрат на её поддержку при введении крупных апдейтов. Далее расскажу немного про наш переход и возникшие при этом трудности.
Что происходит
Если вы уже знакомы с теорией, то этот раздел можно пропустить — тут я хочу поверхностно сравнить подходы к предмету в разных версиях операционной системы.
В Android есть внутреннее Internal Storage (IS) и внешнее хранилище External Storage (ES). Исторически это были встроенная память в телефоне и внешняя SD-карта, поэтому ES был больше, но медленнее и дешевле. Отсюда и разделение — настройки и критически важное записывали в IS, а в ES хранили данные и большие файлы, например, медиа. Потом ES тоже стал встраиваться в телефон, но разделение, по крайней мере логическое, осталось.
У приложения всегда есть доступ к IS, и там оно может делать что угодно. Но эта папка только для конкретного приложения и она ограничена в памяти. К ES нужно было получать доступ и, кроме манипуляции со своими данными, можно было получить доступ к данным других приложений и производить с ними любые действия (редактировать, удалять или украсть).
Но после разделения на внутреннее и внешнее хранилища все равно оставались проблемы. Многие приложения могли хранить чувствительную информацию не только в IS, но и в ES — то есть ответственность лежала целиком на разработчиках и на том, кто хочет завладеть файлами.
В Android решили всё это переделать ещё в 10-й версии, а в 11-й это стало обязательным.
Чтобы минимизировать риски для пользователя в Google решили внедрить Scoped Storage (SS) в ES. Возможность проникнуть в папки других приложений убрали, а доступ есть только к своим данным — теперь это сугубо личная папка. А IS с 10-й версии ещё и зашифрована по умолчанию.
В Android 11 Google зафорсировала использование SS — когда таргет-версия SDK повышается до 30-й версии API, то нужно использовать SS, иначе будут ошибки, связанные с доступом к файлам. Фишка Android в том, что можно заявить совместимость с определённой версией ОС. Те, кто не переходили на 11, просто говорили, что пока не совместимы с этой версий, но теперь нужно начать поддерживать нововведения всем. С осени не получится заливать апдейты, если не поддерживаешь Android 11, а с августа нельзя будет заливать новые приложения.
Если SS не поддерживается (для девайсов ниже 10-й версии), то для доступа к данным других приложений требуется получить доступ к чтению и записи в память. Иначе придётся получать доступ к файлам через Media Content, Storage Access Framework или новый, появившийся в 11-м Android, фреймворк Datasets в зависимости от типа данных. Здесь тоже придётся получать разрешение доступа к файлу, но по более интересной схеме. Когда расшариваемый файл создаёшь сам, то доступ к нему не нужен. Но если переустановить приложение — доступ к нему опять потребуется. К каждому файлу система привязывает приложение, поэтому когда запрашиваешь доступ, его может не оказаться. Особо беспокоиться не нужно, это сложно отследить, поэтому лучше просто сразу запрашивать пермишен.
Media Content, SAF и Datasets относятся к Shared Storage (ShS). При удалении приложения расшаренные данные не удаляются. Это полезно, если не хочется потерять нужный контент.
Хотя даже при наличии SS можно дать доступ к своим файлам по определённой технологии — через FileProvider можно указать возможность получения доступа к своим файлам из другого приложения. Это нормально, потому что файлы расшаривает сам разработчик.
Также добавилась фича — если приложение не использовалось несколько месяцев, то снимаются все пермишены и доступы к системным элементам. По best practice разрешение запрашивается по необходимости (то есть непосредственно перед использованием того, на что спрашиваем разрешение), поэтому мы просто перед выполнением какого-либо действия проверяем, есть ли у нас пермишены. Если нет, то запрашиваем.
В то же время перекрыли доступы к приложениям внутри девайса. Если раньше можно было отследить, что установлены определённые приложения и отправлять к ним соответствующие интенты, то сейчас мы должны прямо в манифесте прописать, что работаем именно с этими приложениями, и только после этого получить доступ.
В качестве примера можем взять шаринг — мы шарим множество приложений, и их всех нужно указывать в манифесте, иначе они не обнаружатся. Начнём перебирать пакет установленных приложений — будет информация, что не указанного в манифесте приложения нет и при шаринге всё отвалится.
Перейдём к практике.
Переход на новую версию
Основная функциональность по работе с файлами в приложении iFunny представлена в виде сохранения мемов в память и расшаривания их между приложениями. Это было первое, что требовалось починить.
Для этого выделили в общий интерфейс работу с файлами, реализация которого зависела от версии API.
FilesManipulator представляет собой интерфейс, который знает, как работать с файлами и предоставляет разработчику API для записи информации в файл. Copier — это интерфейс, который разработчик должен реализовать, и в который передаётся поток вывода. Грубо говоря, мы не заботимся о том, как создаются файлы, мы работаем только с потоком вывода. Под капотом до 10-й версии Android в FilesManipulator происходит работа с File API, после 10-й (и включая её) — MediaStore API.
Рассмотрим на примере сохранения картинки.
Так как операция сохранения медиафайлов достаточно длительная, то целесообразно использовать MediaStore.Images.Media.IS_PENDING , которая при установлении значения 0 не дает видеть файл приложениям, отличного от текущего.
По сути, вся работа с файлами реализована через эти классы. Шаринг в другие приложения автоматически сохраняют медиа в память устройства и последующая работа с URI уже происходит по новому пути. Но есть такие SDK, которые ещё не успели перестроиться под новые реалии и до сих пор используют File API для проверки медиа. В этом случае используем кеш из External Storage и при необходимости провайдим доступ к файлу через FileProvider API.
Помимо ограничений с памятью в приложениях, таргетированных на 30-ю версию API, появилось ограничение на видимость приложения. Так как iFunny использует шаринг во множество приложений, то данная функциональность была сломана полностью. К счастью, достаточно добавить в манифест query, открывающую область видимости к приложению, и можно будет также полноценно использовать SDK.
Для неявных интентов тоже приходится добавлять код в манифест, чтобы задекларировать то, с чем будет работать приложение. В качестве примера выложу часть кода, добавленного в манифест.
После проверок запуска UI-тестов на девайсах с версиями API 29-30 было выявлено, что они также перестали корректно отрабатываться.
Первоначально в LogCat обнаружил, что приложение не может приконнектиться к процессу Orchestrator и выдает ошибку java.lang.RuntimeException: Cannot connect to androidx.test.orchestrator.OrchestratorService.
Эта проблема из разряда видимости других приложений, поэтому достаточно было добавить строку
Тест удачно запустился, но возникла другая ошибка — Allure не может сохранить отчёт в память устройства, падает с ошибкой.
Очевидно из-за Scoped Storage стало невозможно сохранять файлы в другие папки, поэтому снова почитав документацию по управлению файлами в памяти на девайсе, обнаружил интересный раздел. Там рассказано, как для нужд тестов открыть доступ к папкам девайса, но с существенными ограничениями, которые можно почитать тут.
Так как нам нужно использовать этот пермишен только для тестов, то нам условия подходят. Поэтому я быстренько написал свой ShellCommandExecutor, который выполняет команду adb shell appops set —uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow на создании раннера тестов.
На Android 11 тесты удачно запустились и стали проходить без ошибок.
После попытки запуска на 10-й версии Android обнаружил, что отчет Allure также перестал сохраняться в память девайса. Посмотрев issue Allure, обнаружил, что проблема известная, как и с 11-й версией. Достаточно выполнить команду adb shell appops set —uid PACKAGE_NAME LEGACY_STORAGE allow . Сказано, сделано.
Запустил тесты — всё еще не происходит сохранения в память отчёта. Тогда я обнаружил, что в манифесте WRITE_EXTERNAL_STORAGE ограничен верхней планкой до 28 версии API, то есть запрашивая работу памятью мы не предоставили все разрешения. После изменения верхней планки (конечно, для варианта debug) и запроса пермишена на запись тесты удачно запустились и отчёт Allure сохранился в память устройства.
Добавлены следующие определения пермишенов для debug-сборки.
После всех вышеописанных манипуляций с приложением, можно спокойно устанавливать targetSdkVersion 30, загружать в Google Play и не беспокоиться про дедлайн, после которого загружать приложения версией ниже станет невозможно.
Источник
In-app updates
When your users keep your app up to date on their devices, they can try new features, as well as benefit from performance improvements and bug fixes. Although some users enable background updates when their device is connected to an unmetered connection, other users might need to be reminded to install updates. In-app updates is a Play Core library feature that prompts active users to update your app.
The in-app updates feature is supported on devices running Android 5.0 (API level 21) or higher, and requires your app to use Play Core library version 1.5.0 or higher. Additionally, in-app updates are only supported for Android mobile devices, Android tablets, and Chrome OS devices.
Update flows
Your app can use the Play Core library to support the following UX flows for in-app updates:
Flexible updates
Flexible updates provide background download and installation with graceful state monitoring. This UX flow is appropriate when it’s acceptable for the user to use the app while downloading the update. For example, you might want to encourage users to try a new feature that’s not critical to the core functionality of your app. 
Figure 1. An example of a flexible update flow.
Immediate updates
Immediate updates are fullscreen UX flows that require the user to update and restart the app in order to continue using it. This UX flow is best for cases where an update is critical to the core functionality of your app. After a user accepts an immediate update, Google Play handles the update installation and app restart. 
Figure 2. An example of an immediate update flow.
Support in-app updates in your app
Learn how to support in-app updates in your app, depending on your development environment:
Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.
Источник
How to update Google Play Services for Android Studio 2.2 emulators?
There are a number of variations of this question, however most are very old, and don’t really answer the question at all. I’m NOT asking how to install Play Services, that is installed in the Studio 2.2 emulators.
The problem is that these emulators are using an old version of Play services.
When I run a test app that uses Firebase to facilitate Google login I get this alert dialog from a Nexus 5 API 23 emulator:
In the onCreate method of my login activity I have this code:
This always returns SERVICE_VERSION_UPDATE_REQUIRED.
Clicking update in the alert dialog does nothing that I can detected. In the debug log I get this message when Play Services startup fails:
My application runs fine on a real Android device.
What simple thing am I missing?
8 Answers 8
This may not be relevant to this question now, but wanted to post it here for future explorers, so that they see some land at the end of the sea. I had been struggling with this out of date Google Play Service on my Nexus 5 x86 emulator running API 25 and trying Firebase notification. I am using Firebase 10.0.1 which needs Google Play Services 10.0.1. But on my emulator, I always used to get the message
W/GooglePlayServicesUtil: Google Play services out of date. Requires 1008400 but found 9874900
W/FA: Service connection failed: ConnectionResult
I had searched extensively a way to update the Google Play Services on my emulator, and whatever was suggested never worked. Finally, I tried creating a new emulator Nexus 5 x86_64 and API 24. Voila. It has Google Play Services 10.0.1 and my app works now.
It really beats me why the x86 image does not have the latest Google Play Serviecs and it does not allow me to update it in any manner, while the x86_64 image has the latest Google Play Services.
Hope this helps someone struggling with Google Play Services.
As for my case, I tried checking for updates on Android Studio, as well as the Google Play Services, and restarted Android Studio. Then the update dialog appeared, which allows me to update the emulator images with the correct Google Play Services version.
Wait for the update to finish, then create new AVDs based on the newly updated images, and everything is good to go.
Assuming you’re using Android’s default AVDs, as opposed to Genymotion, you just have to make sure everything has been updated.
This is what’s working for me. If you are using using the current version of play services, 9.6.1 or higher, make sure of the following:
- Your build tools version is 24.0.3 or higher
- In the SDK Manager (SDK Platforms tab):
- If testing Nougat, your emulator is using Google APIs System Image Revision 8 or higher (I’m using «Google APIs Intel x86 Atom_64 System Image»)
- Google APIs is installed and updated (For me, «Google APIs, Android 24» — Revision 1.0.0)
- In the SDK Manager (SDK Tools tab):
- Android SDK Platform Tools is version 24.0.3 or higher
- Android SDK Tools is version 25.2.2 or higher
- Google Play Services is installed and using version 33 or higher
- (Probably optional) Google Repository is installed and version 36 or higher
After ensuring all of that, and restarting Android Studio (because better safe than sorry), make a new AVD. I mainly use the following settings: — Nougat (API 24) — ABI — x86_64 — Target — Android 7.0 (with Google APIs)
This is working for me, as I was having the same problem this morning until I updated everything. Good luck 🙂
In case people are still looking for an answer and haven’t found any solution that fixes or updates the Google Play Services on their emulators, here’s what helped me. I had followed multiple SO posts that recommend getting latest SDK build tools but missed a very important update. That is, from the SDK Platforms you must update/download
Google Play Intel x86 Atom System Image
A picture is worth a thousand words:
This packages will only work for Android 4.2.2 and higher in these answer i am taking an example of (API 17).and it will do work .
Let’s begin by launching the SDK manager. We will first need to ensure that Android 4.2.2 (API 17) and higher is installed.
If not, check the top level element, “Android 4.2.2 (API 17)”, click “Install 6 Packages”, and accept the license agreement.
Setting up the image
To get the right image for your virtual device manager:
- Open the Android SDK Manager
- Open the group Android 4.2.2 (API 17)
- Check Google APIs
Check ARM EABI v7a System Image
[![Google Android sdk required tool][1]][1]
Once installed, close the SDK manager and launch the AVD manager. Here we’ll need to create a new AVD which utilizes the Android 4.2.2 platform and has snapshots enabled so that any changes we make are persistent.
Next we need to pull down the appropriate Google Apps package. Using Android 4.2.2 (API 17) and higher we must use the appropriate package according to below link.
Once downloaded, extract the archive. In order to install Google Play, we’ll need to push the following 3 APKs to our AVD (located in ./system/app/):
- GoogleServicesFramework.apk
- GoogleLoginService.apk
- Phonesky.apk
However, before we do, we need to make some minor modifications to our AVD. Let’s launch the newly created AVD using the following command. Note that we’ve specified a partition size of 512MB. This is to ensure that our AVD has enough capacity to install the Google Play Store and its dependencies.
This may take several minutes the first time as the AVD is created. Once started we need to remount the AVD’s partition and modify the permissions of “/system/app/” as this is where our packages will be installed to.
And finally, we can push these APKs to our AVD:
Now if your emulator is as slow as mine it may take a few minutes for the package to be installed. You’ll know if the installation hasn’t yet completed if the launcher process repeatedly crashes on you 😉
After a few minutes, we should see the Google Play package appear within the menu launcher. After associating a Google account with this AVD we now have a fully working version of Google Play running under your emulator.
Источник
