Since we started supporting Android platforms fully in the XRTK, we’ve been through the mill working through all the possible combinations of testing, debugging and banging heads against tables to make Android platforms behave.
Today I’ll share some hints, tips and advice for making the insanity of working with Android in Unity a little clearer.
Since we started supporting Android platforms fully in the XRTK, we’ve been through the mill working through all the possible combinations of testing, debugging and banging heads against tables to make Android platforms behave.
Today I’ll share some hints, tips and advice for making the insanity of working with Android in Unity a little clearer.
##
(Feel free to skip if you have already installed Android as a platform in Unity)
You want to target Android with Unity, are you crazy? Well if you are, or just want to build for some of the many platforms now adopting Android as their operating system (Oculus Quest, Lenovo, Magic Leap and so on), then let us first get Android inserted into your Unity installation
I’d recommend using the Unity Hub for managing all your Unity installations (especially if like me, you have many), you can use the old download installer if you wish, it should look fairly similar.
Open the Unity Hub and click on the Installs tab (as shown above) and you’ll see all the Unity versions that the Unity hub has detected on your machine. From here you can either modify an existing installation (by clicking the three dots … ) or click ADD to install another, this will show you the optional components for your Unity installation.
Once you have opened your Unity Installation (or started installing) you will have a list of modules that can be added to your installation. For Unity, you simply need to select the Android Build Support module to enable the Android platform. Additionally, I’d recommend expanding the Android platform (if your version of Unity support it) and also select any options for the Android SDK & NDK as this will install Unity compatible versions of these (not mandatory, but highly recommended)
Now you have Android setup against your Unity installation, so is it time to party yet? I wish that was the end of the story but let us move on.
##
Congratulations, you have installed the Android module in your Unity installation (if not, go back to 1 😀 ) but still, there is more to do.
If you open your Unity project in the editor and then open the Editor Preferences window (Menu -> Edit -> Preferences), on the “ External Tools ” tab you should see the following now:
(I’ve unchecked some boxes to highlight some config here)
With Android installed, you will have an entire section dedicated to the Android module detailing the various tools needed in order to produce an Android build.
For each of these, you can either use the default install provided by Unity (as shown in Figure 3 above) or you can also install your own, as detailed here:
So long as Unity doesn’t complain and each of the relevant tools and paths are configured correctly, you should be good to go.
It is Unity after all, and if the recommended Unity defaults don’t work (I have had it happen twice on new builds) then simply switch to the Google or Microsoft versions.
If you’re using Google or Microsoft and it stops working after an upgrade, check you have the correct version of the SDK/NDK installed that Unity is complaining about, likely you’ll need to upgrade. If that fails, fall back to using the Unity default versions.
It’s a pain, but then again, It is Android.
##
Before you can start building and deploying to your Android device, you will need to ensure that you have enabled “ Developer Mode ” on the device and that you have also installed the Google “ADB Drivers” for the respective device on your development PC.
In most cases, you can use the default Google USB ADB Driver, depending on your device however, (Oculus Quest has its own for example) you may need to go back to the device manufacturer and get a specific one.
Simply put, if Unity cannot find your device to build to it, it is almost always down to:
##
Now that your Unity installation is setup for Unity and your device is hooked into your machine, the last step is to get your project ready for Android, and so to enter madness.
The Android settings can be found in your Player project settings (“Edit -> Project -> Player Settings” – like most platforms) with the key area being the “ Other Settings ” tab:
I’ve highlighted some of the most common settings you’ll need to configure for your target devices, although mileage will vary depending on what you want to support:
Tinker and play with the rest, but it should not affect development much (except permissions). You will have to review this as you go to publish, but that is tomorrows problem :D.
##
Once you can actually produce a Unity build and deploy to a device, it is time to get acquainted with the base Google tool(s) used to manage your device.
You can read/watch many tutorials, but the only tool (outside of Unity) that you will need to use is the Google ADB tool and in that, only 2 commands at most really.
First, you’ll need to set up a PATH on your PC to enable you to use the ADB tool anywhere using the installation path for your Android SDK, simply follow the instructions here for updating the PATH environment variable on your PC using the relevant location from the selection below:
I also recommend setting up a Command-Line (CMD) shortcut on your desktop that “Starts in” the above folder, to also give you quick access to the tool.
Once the ADB tool is accessible, the two main commands you are going to use are:
You can do more with the adb tool, including getting logging information, getting device statistics and killing the services used by adb (useful when Unity crashes and you don’t want to reboot).
To learn more about the ADB tool, use the following command to see everything it does:
adb /?
But in all honesty, the only two I use are the Install and Uninstall commands.
##
Before Unity released this preview tool, the only way to get information from the device was using the “adb logcat” command. This did give you output but it was very heavy, it was raw text and almost unintelligible to the untrained eye. For a long time, this was all we had (without going down the paid tools route), thankfully Unity built (or bought?) a handy UI for the default adb logcat information.
To install this tool, you will need to open the Unity Package Manager window (Window -> Package Manager) and enable the Advanced -> Show Preview Packages option as shown below:
This will enable you to see all the packages that the Package Manager has been scoped to see. To find logcat, it is best to simply type “ logcat ” into the search area in the top right and select the package to install.
And that’s it. Once installed, every time you now run an Android build from Unity, the logcat viewer will appear and connect to the device (assuming you have selected a “Development” build in the Build Settings Window looking like this:
This shows a nice graphically formatted view of the raw logcat data with Yellow text for warnings (albeit hard to read) and nice Red for errors. You can also filter the data by process, e.g. Unity, Android or your project itself.
##
Debug info and logs are all well and good, but at some point, you are going to want to step through your code (or spend endless hours pasting in debug log messages). Thankfully this is still possible, although a little tricky at times.
First off, you will need to ensure your build is set up as a development build and enable script debugging in the Build Settings window (File -> Build Settings), as shown below:
With these set, once you run the project on a device connected to the PC (although WiFi debugging is available, I still recommend doing this connected to your PC via USB) it will enable the Unity Debugger in the project ready for Visual Studio to connect to.
When you are ready, switch over to Visual Studio (assuming you actually have a version of Visual Studio installed) for the project (Assets -> Open C# Project) to see the latest state of your code. Once open, you will find Unity debug options under the “ Debug ” menu item in Visual Studio as seen here:
Once clicked, you will be presented with a new window listing all the Unity debugging instances available:
If you do not see an instance for your project yet, do not fret. Just check the device is plugged into your PC and the project has actually started, the instance won’t show up until your Unity project is at least past the Unity splashscreen.
Once it’s started, Visual Studio will be hooked up and running, allowing you to set breakpoints and walk through your code as normal.
If you need to attach Visual Studio while your project is starting up, you have two options:
Things are a little trickier when the Unity editor cannot connect to a platform, such as with Android, but everything is still possible.
(Subtle note, the experience is the same with ARM platforms, such as those on the Microsoft HoloLens)
A lot of the above is based on timing, being ready and building your experiences with the Android platform for Unity projects.
There are probably a ton of other tips I can pass on but this article is long enough already. The biggest being about Android manifests for multiple devices, which is an entire other article on its own.
For now, try to enjoy your Android journey, especially if it is with the Oculus Quest device and ensure you have a lot of hot drinks available, as well as a fresh supply of goodies while you wait for those many many builds to complete and push to the device to test.
Comments