Setting build environment android

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.

Источник

Android Environments

Предисловие

Из далекого 2012, на просторах Хабра мне запомнился коммент:

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

Недавно ко мне обратился заказчик, который попросил добавить в его проект поддержку нескольких сервисов. Задача заключалась в том, что мне нужно было подключить сервис «А» и перед выкладкой приложения в продакшн, обкатать этот сервис на тестовом окружении. Я решил проанализировать свои предыдущие решения и… ужаснулся.

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

Проблема

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

После анализа build.gradle скрипта, android tools заберет все значения buildConfigFileds из buildTypes и productFlavors и сгенерирует BuildConfig файлы для каждого типа сборок:

Никакой проблемы, на первый взгляд. Особенно, когда в вашем приложении не столь много флейворов и кастомных значений. В моем проекте их было >20 и 3 окружения (internal/alpha/production). Очевидно, что проблема для меня была одна — избавиться от бойлерплейта.

Не менее важная проблема — значения перменных окружения не должны быть отражены в вашем проекте. Даже в конфигурационном файле. Вы обязаны затрекать через VCS ваш build.gradle конфиг. Но вы не должны прописывать ваши ключи напрямую, для этого, вам необходим сторонний механизм(например файл, сервисы вашего CI). В моей практике было несколько проектов, где для release production сборки у меня не было доступа к значениям некоторых библиотек. Это уже проблема бизнеса и в его интересах не делать лишних затрат. Вы не должны использовать ключи предназначенные для продакшена во время отладки или внутреннего тестирования.

Способ решения проблемы

В одном из старых проектов, для хранения значений переменных окружения, мы использовали простые .properties файлы, которые предоставляли доступ к полям через классический key:value map. Проблему биндинга данный подход не решает. Но он решает проблему поставки данных, который следует применить. Кроме того, мы можем взять за основу .properties файлы как определенного рода контракт предоставления данных.

Если вернуться чуть назад, у нас есть промежуточный этап: из buildConfigField в поле класса BuildConfig. Но кто же это делает? Все довольно банально, за это отвечает gradle plugin который вы подключаете абсолютно во всех проектах Android.

Именно он отвечает за то, что после анализа вашего build.gradle файла будет сгенерирован класс BuildConfig для каждого флейвора со своим набором полей. Таким образом, я могу написать свое лекраство, которое расширит возможности com.android.application и избавит
меня от этой головной боли.

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

Решение

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

А вот тут сразу же возникли те трудности, о которых я и не задумывался — пыльная полка.Я решил «продать» свое реше коллегам. Я подготовил доку, пнул дело на обсуждение и… Понял, что все мы люди, а программисты — это ленивые люди. Никому не хочется вставлять неизвестный ему участок кода в проект, его же по хорошему нужно изучить, прочитать? А вдруг он нерабочий? А вдруг он делает еще что-то не так? Это же груви, а я его не знаю и непонятно как с ним работать. А уже давно переехал на котлин скрипт, а портировать с груви я не умею и проч.

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

А какие же проблемы решит плагин и его удаленная поставка пользователю?

• проблему ленивого програмиста. Нам лень углубляться в корень проблемы и возможные способы его решения. Нам куда проще взять что-то, что былоуже сделано до тебя и использовать это.
• поддержка. Она включает в себя поддержку кода, его развитие и расшириения возможностей. При решении своей проблемы, я решал только проброспеременных окружения только лишь в код, совсем позабыв о возможности проброса в ресурсы.
• качество кода. Бытует такое мнение, что некоторые разработчики даже не смотрят на open source код, который не покрыт тестами. На дворе 2019 и мы с легкостью можем подключить себе сервисы для отслеживания качества кода https://sonarcloud.io либо https://codecov.io/
• конфигурация. Расширение билд файла заставляет меня изучить этот код и внести изменения вручную. В моем случае — мне не всегда нужно использовать конфигурацию для buildTypes либо productFlavors, хочу что-то одно или все сразу.
• уборка пыльной полки. Я наконец-то навел порядок на одной из них и смог это решение по-дальше своей комнатушки.

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

Источник