What's the deal with Godot's version of Mobile Remote?

Godot Version 4.1.2 (v4.1.2-stable_win64)


Unity Remote was invaluable the last time I tackled a Unity project for my family. It’s sort of a given that such a luxury would be a bit different to hook up on a completely different game engine like Godot 4, which, aside from the hiccups in names, has been very easy to work with for me so far. (Input Mapping alone makes Unity’s input map system look like spaghetti!)

…But the convolutions involved in getting SDK/one-click deploys method of has made me wonder: Why is the process to get it’s equivalent up and running for Godot involve so many external program hoops? Off the top of my head, it involves some kind of SDK program before another SDK program, then getting the right Android SDKs, installing a build template inside/outside(?) Godot, and so on.

It seems like quite the headache, even though I have the developer options and USB settings down pat for my phone.

Also, it may have something to do with how many external programs I can’t install because of my family not allowing me the password to, well, install any application

TL;DR: Are there any plans for Godot to have more mobile remote support built into the engine itself? Or are there reasons for the process to be reliant on more complicated external programs?

The process of one-click deploy will always have to rely on external programs, as this is the nature of mobile SDKs that are proprietary[1] and difficult to embed into programs.

As for export templates, they’ll remain a separate download outside of the Steam version as not everyone needs to export a project for all platforms. Many users don’t even need to export a project for any platform (e.g. if they’re just prototyping with the engine or are evaluating it for their needs). We don’t want to impose large download sizes when there’s no need for it, as many people still have slow, metered Internet connections.

It would be possible for Godot to download and install the required SDK components automatically, but there are a few issues:

  • The Android SDK uses click-through licensing, with a prompt that requires you to accept licenses in the command line – or use hacky workarounds to do so (the typical approach on CI).
  • The list of required components and the URL to the Android SDK command-line tools keeps changing over time. A valid URL and components list in 2023 may not be valid anymore in the future. I think Google keeps old SDK versions available for a certain amount of time, so it shouldn’t be too problematic while a given Godot version is still supported, but this should still be noted.
    • Installing SDK components is also not required to export a project to Android using official export templates. It’s only required compile an Android export template or a custom Gradle build.

Automatically generating a debug keystore and saving it to the user data directory shouldn’t be too difficult once the Android SDK is configured. This would remove the need for users to manually generate this debug keystore, although it’s best to make backups of this debug keystore in case you need to move it to another PC. Reusing an existing debug keystore allows you to update your existing debug-deployed apps on a device instead of having to reinstall them from scratch.

Also, it may have something to do with how many external programs I can’t install because of my family not allowing me the password to, well, install any application

The Android SDK command-line tools should be installable without administrator privileges, as they’re just a ZIP file you need to extract somewhere. This doesn’t apply to Android Studio, unless a portable version of it exists.

You don’t need the entirety of Android Studio to export or compile for Android – the command-line tools suffice.

  1. Most individual Android SDK components are open source under the Apache 2 license, but the entire SDK distribution from Google is proprietary. ↩︎

1 Like

As far as I can remember Unity also requires you to install the android SDK … which parts of the process are different?

The main difference I remember - it’s been months since I touched Unity, to be honest - is that there was basically only one way to do it. That’s probably quite limiting in the long run, but starting out? Multiple tutorials on different ways to go about it + smaller internet community to steer me in the right direction + tendencies to get lost somehow = A C K .

The very fact that Android Studio isn’t needed and has it’s own Visual-Studio-esque setup requirements and installs, but some clunky UI stuff which I won’t need since I have a phone ready with developer settings turned on and ready to plug and playtest with my computer, is a rabbit hole I went down yesterday, and that was on the Godot 3.4 Docs when I’m using 4.2!

Put into words, the process is jank, but is fixed with one-on-one help, Youtube tutorials, or community efforts.

Thank you SO much for helping me with this. I do have a few more questions, though:

Which of the following list would actually be necessary, if I’m looking to sidestep Android Studio and whatever setup spaghetti is attached to reaching one-click-deploys?

  • OpenJDK 20
  • JDK 11 or JDK 17
  • keytools?
  • keystores?
  • Command Lines?
  • SDK Manager(s)?
  • Running “keytool -keyalg RSA -genkeypair -alias androiddebugkey -keypass android -keystore debug.keystore -storepass android -dname “CN=Android Debug,O=Android,C=US” -validity 9999 -deststoretype pkcs12” or smth similar in the Windows Command Prompt
  • Using the Windows Control Panel to go into Environment Variables through Advanced Settings and all that stuff

Or, heck, if you could type out a process for me, or tell me how to get along with this tutorial by “Gwizz”: (https://www.youtube.com/watch?v=dCLYMF32ZBE) without needing Android Studio, that’d be amazing!

I just double-checked the Godot 4.2 Exporting for Android documentation page, and in my opinion, it provides very detailed instructions how to set up the Android export functionality, even without installing Android Studio.

In general, Godot has very detailed and easy-to-follow official documentation, my recommendation is to use it as the source of truth rather than random Godot tutorials, YouTube videos, or StackOverflow articles.

There are certainly places where the documentation could be improved. But it is also easier to get help if you report: I am following the documentation, but I don’t know how to proceed from this or that place. Such reports can be easily turned into PRs to improve the documentation itself for everyone’s benefit.

Sorry for replying to this late, but I wanted to provide some feedback on the current documentation, as per your recommendation:

  • In this instance, the Godot Docs are trusting the external websites a bit too much in terms of guidance. I remember them feeling more like each of them were its own product, when the Docs treat them as simple, one-and-done stepping stones.

  • The process is explained, but not what the individual steps do. As an ametuer programmer, I just wanted to look into Godot’s equivalent of Unity Remote, not install and manage multiple different unexplained external programs.

  • The Godot Docs would greatly benefit from a step-by-step process to undoing all of this, in case somebody needs to start from scratch. If the reasoning behind the process’ steps can’t be explained, it’d be nice to have a detailed guide to cleaning up the mess of files a failed attempt leaves behind. It may just be an organizing issue on my end, though, and dipping into “cleaning up your Windows File Explorer for dummies” is probably a lesson that requires its own wholy separate tangent.

  • From my experience, the process is relatively easy to follow up until it tells me to install OpenJDK and Android Studio…Oh, wait. I found the bullet points sent me down a rabbit hole of “are you sure I should be installing this, and how do I use this new program?”

  • Actually, one really nice way they could handle this is splitting up the different methods into their own pages. For example, the setup involving Android Studio, and the setup dodging Android Studio altogether.

  • Maybe even splitting up the process’ individual steps into their own mini-pages, like the First Game tutorials do, so that it feels less like a one-(hundred)-and-done setup marathon?

  • I’m not 100% a dummy when it comes to tech like this, but I think dummy proofing in general would benefit everyone here. Everyone gets stuck on different steps, and what-to-do info is always helpful!