Android sdk target api

Android environment setup

To build and run for Android, you must install the Unity Android Build Support platform module. You also need to install the Android Software Development Kit (SDK) and the Native Development Kit (NDK) to build and run any code on your Android device. By default, Unity installs a Java Development Kit based on OpenJDK.

Note: Unity supports Android 4.4 “KitKat” and above. See AndroidSdkVersions for details.

1. Install Android Build Support and the Android SDK & NDK tools

Use the Unity Hub to install Android Build Support and the required dependencies
See in Glossary : Android SDK & NDK tools, and OpenJDK.

Add Android modules

You can install Android Build Support, the Android SDK & NDK tools and OpenJDK when you install the Unity Editor, or add them at a later time.

For information on adding the Android modules:

If you are using a 2018 version of Unity, see the Unity 2018.4 documentation for information on manually installing these dependencies.

2. Enable USB debugging on your device

To enable USB debugging, you must enable Developer options on your device. To do this, find the build number in your device’s Settings menu. The location of the build number varies between devices; for stock Android, it’s usually Settings > About phone > Build number. For specific information on your device and Android version, refer to your hardware manufacturer.

After you navigate to the build number using the instructions above, tap on the build number seven times. A pop-up notification saying “You are now X steps away from being a developer” appears, with “X” being a number that counts down with every additional tap. On the seventh tap, Developer options are unlocked.

Note: On Android versions prior to 4.2 (Jelly Bean), the Developer options are enabled by default.

Go to Settings > Developer options (or, if this does not work, on some devices the path is Settings > System > Developer options), and check the USB debugging checkbox. Android now enters debug mode when it is connected to a computer via USB.

Connect your device to your computer using a USB cable. If you are developing on a Windows computer, you might need to install a device-specific USB driver. See the manufacturer website for your device for additional information.

The setup process differs for Windows and macOS and is explained in detail on the Android developer website. For more information on connecting your Android device to the SDK, refer to the Run Your App section of the Android Developer documentation.

ADB debugging for Chrome OS devices

For information on how to set up your development environment for Chrome OS devices, and enable ADB An Android Debug Bridge (ADB). You can use an ADB to deploy an Android package (APK) manually after building. More info
See in Glossary debugging, see Google’s documentation on Chrome OS Developer Environments.

Connecting to your Chrome OS device

Before you can deploy to your device you need to manually connect with ADB via the device’s IP address.

To begin you need the IP address. Open up the Settings app and choose Network in the sidebar. Next click on the active network interface.

If the interface is wireless then next choose the SSID that you are connected to. In the details you will see your IP address. Make a note of it.

If you are using a wired connection your IP address will be shown on the first details page.

Now we are ready to connect. For the sake of this example let’s say that the device’s IP is 192.168.0.100. In a shell or terminal run the following command

adb connect 192.168.0.100

If the connection was successful you will see a message such as connected to 192.168.0.65:5555 . And adb devices should verify that the device is connected. List of devices attached 192.168.0.65:5555 device

From now on you may run ADB commands to target the device just as you would over a USB connection.

Note: If your device or host machine goes to sleep or loses network connectivity you may need to reconnect.

Customizing the Android SDK & NDK Tools and OpenJDK installation

Unity recommends that you use the Unity Hub to install Android SDK & NDK tools, to ensure that you receive the correct versions and configuration. Unity installs Android SDK & NDK Tools and OpenJDK respectively in the SDK, NDK and OpenJDK folders under /Unity/Hub/Editor/[EditorVersion]/Editor/Data/PlaybackEngines/AndroidPlayer/.

If you have multiple versions of Unity with the same required dependencies (be sure to check System requirements for the latest) and you want to avoid duplicating the installation of Android SDK & NDK Tools and OpenJDK, you can specify a shared location in the Unity Preferences window. To do this, go to Preferences > External tools and enter the directory paths in the SDK and NDK fields:

Preferences window showing external tools settings for Android

Warning: Unity does not officially support versions of the OpenJDK, SDK, or NDK other than the ones it supplies.

To change the OpenJDK, SDK Tools, or NDK that Unity uses to build Android apps:

1. Open the Project.
2. Open the Preferences window (Windows and Linux: Edit >Preferences; macOS: Unity >Preferences).
3. In the left navigation column, select External Tools.

Change the OpenJDK path

1. Uncheck JDK Installed with Unity (recommended).
2. In the JDK field, enter the path to the JDK installation folder, or use the Browse button to locate it.

Change the Android SDK Tools path

1. Uncheck Android SDK Tools Installed with Unity (recommended).
2. In the SDK field, enter the path to the SDK installation folder, or use the Browse button to locate it.

Unity works with the most recent version of the Android SDK available at the time of the Unity version release.

Change the Android NDK path

1. Uncheck Android NDK Installed with Unity (recommended).
2. In the NDK field, enter the path to the NDK installation folder, or use the Browse button to locate it.

Each version of Unity requires a specific version of the Android NDK to be installed:

Unity version	NDK version
2018.4 LTS	r16b
2019.4 LTS	r19
2020.3 LTS	r19

See the System requirements page for a complete list of requirements.

Updating the Android SDK Target API

Unity Hub installs the latest version of the Android SDK Target API required by Google Play.

If you need to use a more recent version, you can change the Target API from the Target API Level field in the Player Settings window (menu: Edit > Project Settings > Player, then select the Android platform). You can find the Target API Level option in the Other Settings > Identification section.

Selecting a target API for the Android SDK

After you select an option other than the default, Unity prompts you to update the Android SDK API. You can choose to either:

• Update the Android SDK
• Continue to use the highest installed version of the Android SDK

Note: If you select an older version of the Target API, the Unity Android SDK Updater will not be able to perform the update and will give you this message:

Android SDK does not include your Target SDK of (version). Please use the Android SDK Manager to install your target SDK version. Restart Unity after SDK installation for the changes to take effect.

In this case, to update the Android SDK Target API, you must use the Android sdkmanager from either Android Studio or the command line tool. Regardless of the method you chose, make sure to select the correct Android SDK folder for Unity in the Edit > Preferences > External Tools window.

On Windows, if the Unity Editor is installed in the default folder ( /Program Files/ ), you must run the sdkmanager with elevated privilege (Run as Administrator) to perform the update.

Источник

Обновляемся на новую версию 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 и не беспокоиться про дедлайн, после которого загружать приложения версией ниже станет невозможно.

Источник