LiveCode Android Studio Setup Checklist

This guide assumes you have attempted to set up for Android deployment on MacOS or Windows through use of Android Studio and exists to quickly go over what may have been missed or done incorrectly.

1. Install JDK 8

At present, LiveCode can not deploy to Android with newer versions of JDK than 8. Anything more recent than this must be uninstalled. JDK 8 can be downloaded from: https://www.oracle.com/java/technologies/javase/javase8u211-later-archive-downloads.html

An Oracle account is required - creating one is free.

Please ensure that the version you download is appropriate to your OS and architecture; an ARM Mac requires the MacOS ARM64 DMG Installer. If installed correctly, you should see one of the following folders:

  • On MacOS: /Library/Java/JavaVirtualMachines/jdk-1.8.jdk
  • On Windows: C:/Program Files/Java/jdk-1.8

2. Install SDK platform Android 13/API 33

In Android Studio, go to the SDK Manager. From there, in the SDK Platforms tab, find either Android 13.0 ("Tiramisu") or Android API 33 (whichever you see) and if it is unchecked, check it. Click on Apply.

If installed correctly, you should see one of the following folders:

  • On MacOS: /Users/<username>/Library/Android/sdk/platforms/android-33/
  • On Windows: C:/Users/<username>/AppData/Local/Android/sdk/platforms/android-33/

3. Install SDK build-tools 31.0.0 (and nothing above)

LiveCode requires build-tools 30.0.0 or higher. However, LiveCode can not deploy to Android if it finds a higher version of build-tools than 31.0.0. As such, it is best to install 31.0.0 and necessary to uninstall anything newer.

In Android Studio, go to the SDK Manager. From there, in the SDK Tools tab, check the Show Package Details box. This will expand Android SDK Build-Tools X (where X is the latest version). While viewing the package details for that, check the box for 31.0.0 and uncheck all boxes for version numbers greater than 31.0.0.

If installed correctly, you should see one of the following folders:

  • On MacOS: /Users/<username>/Library/Android/sdk/build-tools/31.0.0/
  • On Windows: C:/Users/<username>/AppData/Local/Android/sdk/build-tools/31.0.0/

If in the /build-tools/ folder you find other subfolders with numbers greater than 31.0.0, delete them; LiveCode will need them gone.

4. Install Android SDK Tools (Obsolete)

In Android Studio's SDK Manager, in the SDK Tools tab, uncheck the Hide Obsolete Packages and Show Package Details boxes then look and check the box for Android SDK Tools (Obsolete). Click on Apply.

If installed correctly, you should see one of the following folders:

  • On MacOS: /Users/<username>/Library/Android/sdk/tools/
  • On Windows: C:/Users/<username>/AppData/Local/Android/sdk/tools/

5. Reset Android SDK root in LiveCode

To ensure LiveCode is expecting the setup you should now have, you will need to clear the SDK root folder setting and set it again, even if that location hasn't actually changed. Go to Livecode -> Preferences and then to the Mobile Support tab. There, click on the x on right end of the field for Location of Android development SDK root to empty it, then choose the SDK root folder. Depending on system and on whether or not you used default settings, this should be:

  • On MacOS: /Users/<username>/Library/Android/sdk/
  • On Windows: C:/Users/<username>/AppData/Local/Android/sdk/

With everything done correctly, a JDK filepath should be reported underneath, saying that it is now:

  • On MacOS: /Library/Java/JavaVirtualMachines/jdk-1.8.jdk
  • On Windows: C:/Program Files/Java/jdk-1.8

Troubleshooting

Deployment to Android stalls endlessly at "Installing app on target device"

It's possible that adb server is simply not responding. Thus, it is suggested to open command prompt/terminal, use cd to navigate to the platform-tools folder (this is a sub directory of the sdk root folder; see above for its default location on your system), use the following commands in order and try again:

On Mac/Linux:

./adb kill-server
./adb start-server

On Windows:

adb.exe kill-server
adb.exe start-server

15 Comments

Trevix

A few versions have passed since this post.
Having messed up with Android studio, LC 10 on Sonoma wasn't installing anymore my standalones on Android. So I disinstalled Java to restart from scratch.
In this post it is stated to use the MacOS ARM64 DMG Installer, so I did: in the infinite list of JDKs the oldest one with a Arm installer is the 8u381 but LC didn't like it (no Jdk accepted).
My previous JDK version was 8u231 but it is listed as x64. I tried to install it anyway but to no avail.
Question is: on a M1 Mac is it ok to use the latest version (JDK 8u391) or it matters? Thanks

Panos Merakos

Hello Trevix,

If you are on an ARM Mac, it is recommended you use the ARM64 installer. Using the (currently) latest version, that is JDK 8u391, it should work.

Currently the JDK path is detected by getting line 1 of shell("/usr/libexec/java_home") and then LiveCode checks if it is valid.

However, on an ARM mac, with the latest 8u391 JDK update, this might return:

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home and this fails the LC validity tests, so the JDK path returned is empty.

So if this is the case, you first have to delete /Library/Internet Plug-Ins/JavaAppletPlugin.plugin and then choose the SDK root folder. Hopefully now the correct JDK path will be auto-filled.

Hope this helps

Regards,
Panos

JereMiami

I seemed to have done all of this and the result is: (1) LC 9.6.11 deploys with no issue, and (2) LC 10 dp-8 does not, giving the "could not encode class bundle."

Am using:

Java: Java SE Development Kit 8u401 (most recent version of Java 8 as of this writing)

Platform: Android SDK 33 (Tiramisu) (and nothing else, except for its "sources for android 33")

SDK Tools: 31.0.0 (and nothing else)

Android SDK Tools (obsolete) is checked

Mobile support preference is set to "... appdata/local/android/sdk" and the auto link is found at "java/program files/jkd-1.8"

All other javas have been uninstalled.

All of this results in 9.6.11 deploying and 10.0 dp8 not.

JereMiami

One thing to add is that the LC 10 error is pointing to this folder:

C:\Users\username\AppData\Local\RunRev\Cache\Android\Repository\com\google\guava\guava\27.0.1-jre

It looks to be an associated with an earlier SDK 27.0.1....

But, again, 9.6.11 does not have an issue deploying. Only LC 10 versions.

Panos Merakos

Hello JereMiami,

What is the JDK path that is auto-filled when you choose the SDK root in LC 10 DP-8? Is it the same as in LC 9.6.11?

Also, how did the ...\Repository\com\google\guava\guava\27.0.1-jre end up there? The directory C:\Users\username\AppData\Local\RunRev\Cache\Android\ is expected to have just a "bundletool" folder. I suggest deleting the folder "Repository" in C:\Users\username\AppData\Local\RunRev\Cache\Android and try again.

Hope this helps.

Kind regards,
Panos
--

JereMiami

The path is Users/username/AppData/Local/Android/Sdk

I deleted the "repository" folder but every time I deploy to android it creates the "repository" folder again. How would you suggest I get it to stop doing that?

For example, I delete the folder, then I deploy to android, it throws the error, and I go back and the "repository" folder has been created.

JereMiami

I tried this on Mac too to no avail. On Mac, I am using:

MacOs- Sonoma
API- 31
Build Tools- 31.0.0/30.0.3
SDK/JDK 1.8.341

What are you using to get this to deploy on Android? Neither Windows or Mac work with this combo.

JereMiami

^regarding LC 10 DP-8

JereMiami

On both Windows and macOS, I delete the "Repository" folder and as soon as I deploy to Android, the folder is created and the same error is presented.

sam norris

Hello,

On the Android Studio side of things, it should be Build Tools 31.0.0 and API 33 that are installed. You have indicated that you have API 31.

If correcting that isn't enough, our best guess is that you may have two Java installations and LiveCode is using the wrong one. You can navigate to the Preferences → Mobile Support window and issue this command from the message box:

set the visible of button "chooseJDK" of card "Mobile Support" of stack "revPreferencesGUI" to true

This will reveal a button that will allow you to choose the desired path:

On MacOS: /Library/Java/JavaVirtualMachines/jdk-1.8.jdk
On Windows: C:/Program Files/Java/jdk-1.8

JereMiami

Thanks Sam.

I tried API 33 too. So let me give you a detailed run down of what I have so you might identify what I have done to mess it up. This is on macOS Sonoma:

In Mobile Support in the IDE:
SDK Root: /Users/username/Library/Android/sdk
JDK Path: /LibraryJava/JavaVirtualMachines/jdk-1.8.jdk

In Android Studio:
SDK Platforms (all ticked below, and nothing else ticked):
"Android SDK Platform 33" (API Level 33)
"Sources for Android 33" (API Level 33)

SDK Tools (all ticked below, and nothing else ticked):
"31.0.0"
"Android Emulator"
"Android SDK Platform- Tools"
"Android SDK Tools (Obsolete)"

The current SE Development Kit I am using is the latest: 8u401.

The following error points to the following folder on macOS (and its counterpart when attempting to deploy from windows):

/Users/username/Library/Application Support/ RunRev/Cache/Android/Repository/com/google/guava/guave/27.0.1-jre/guava-27.0.1-jre.jar.com/google/common/util/concurrent/ListenableFuture.class.

It says: "Type com.google.common.util.concurrent.ListenableFuture is defined multiple times" ... "compilation failed"

Panos said to delete the folder "Repository" located in the file path above, which I did. However, when I build on macOs or Windows, testing on a physial device will recreate the folder "Repository" and cause the error again. Stated differently, using "Test Target" with a physical device will create this "Repository" folder, which I am not quite sure it should be doing, per Panos. Panos sais that only the "bundletool" folder should be within the "Android" folder in the above path causing the error.

Any thoughts on this would be greatly appreciated!

Thanks in advance.

JereMiami

One more thing I would add to the above comment is that 9.6.11 successfully deploys to android with the same setup (described above) from both macOs and Windows. No errors with 9.6.11. However, in LC 10 DP-8, this "Repository" folder seems to be the issue, which leads me to believe there is a bug for Android deployment in LC 10 DP-8.

Panos Merakos

Hello JereMiami,

One more question - do you get this error with any stack you try to deploy to Android in LC 10 DP-8 - even with a simple stack that has e.g. just one button? Or just with a specific stack?

Kind regatrds,
Panos
--

JereMiami

Excellent idea.

I made a simple standalone stack for Android (i.e., a single card and a single button). First, I attempted to deploy it from 9.6.11 to see if it deploys there. It deployed as it should. Next, I deployed from 10 DP-8. It also deployed as it should.

So using the above combination of settings/paths in the IDE and Android Studio deploys a simple stack from 10 DP-8.

So that got me thinking...what other standalone setting could cause a conflict in that "google" subfolder?

Push notifications.

On a complex stack, utilizing android push notifications, deployment from 10 DP-8 will cause the error referenced above from both the macOs and Windows IDEs.

If you untick "Push Notification" in the Android Standalone Applications Settings, then the same complex stack deploys from LC 10 DP-8.

There appears to be some sort of conflict deploying to Android when building with push notifications enabled.

The push notifications do indeed work in the complex app successfully (of course, when deployed from 9.6.11). But, as stated above, building with the android push notifications enabled in LC 10 DP-8 causes a deployment build error when it is "Assembling Resources."

Any idea how to resolve this or should this be reported as a bug?

Panos Merakos

Hello JereMiami,

Nice detective work! This indeed sounds like a bug, so the proper way to resolve it is first to report it to https://quality.livecode.com

Then we will take it from there.

Thank you very much!

Add your comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.