a) The Livecode lesson is wrong (since 2016 Android Studio does not need a separate JDK install),
b) how LC preferences pane looks up the relevant JDK is way too complex (the IDE needs to just set the path based on the Android Studio (AS) install (which is different to the AS SDK path).
SDK path (Windows) in the LC Prefs windows looks like this:
Below it the JDK path needs to look like this:
JDK Path: D:/Programs/Android/Android Studio/jre
I'm not really surprised by this confusion, as there were plenty of other misleading trails when the fix is really simple.
Android Studio version is 4+ (the downloaded file has 201 in the crazy numbering).
If one looks inside some of the .bat files once AS is installed, these batch files branch depending on if Windows is version "NT" or not - if not, it's assumed to be Win95/WinME! Mind-boggling to think that at the cutting edge of Android development (1gb of RAM for AS/emulator to run) they are providing for Win95 users.
However, in investigating what AS installs I found that version 2.2+ comes with its own OpenJDK - see https://stackoverflow.com/a/42172066 (since June 2016 Google's install instructions for Android Studio dropped any reference to installing a JDK). What AS install does not do is set the variables/registry keys LC expects when looking for an appropriate JDK (so the JDK bundled inside AS is not found by the LC IDE).
Here's what the studio-config.html says:
"A copy of the latest OpenJDK comes bundled with Android Studio 2.2 and higher, and this is the JDK version we recommend you use for your Android projects". From <https://stackoverflow.com/questions/421 ... o/42172066> I found plenty of other instructions (external to Livecode) referring to parts of Android Studio which were wrong (either the referenced feature has been moved or renamed).
After installing Android Studio (v4.1 i.e. file named ide-201.xx version as in screenshot) I checked Android Studio worked and that an x86 emulator could be created. Once assured that was working, I knew that AS was finding and using a JDK even when LC could not. I needed to find out why LC was failing to find the needed JDK. I enabled the (hidden) "ChooseJDK" button on the LC prefs pane to inspect what LC was looking for in setting the JDK version. Depending on the platform, LC relies on the OS being able to provide a pointer to the right JDK. In my experience this failed on both MacOS and Windows.
With the relevant section of the Preferences window open, I put this in MessageBox
Code: Select all
set the visible of button "ChooseJDK" of group "Android SDK" of card "Mobile Support" of stack "revPreferencesGUI" to true
JDK Path: D:/Programs/Android/Android Studio/jre
Meanwhile the line above JDK Path (pointing to SDK root) will say something like:
After ensuring that the two Android relevant fields pointed to the SDK home and the (Android bundled) JDK, I created a test stack, saved it and set the standalone settings, then chose the Android emulator listed in the menu "Development/Test Target) and tested my basic stack on the emulator. Bingo.
So, here's what LC needs to do:
a) edit the lesson to remove any reference to JDK
b) change how the Prefs pane looks for a JDK e.g. let the user point to the root directory of the Android Studio binaries and build up a path to Android's included JRE directory.
Update: forgot to mention that one needs to set the PATH environment variable so that it points to the relevant (home) directory for the sdk java tools. LC in launching those tools could include the full path to that home. For anyone trying to do what I've done, once the path variable is set then opening a new terminal one should be able to call
and the OS should find those executables and launch them. My guess is that within the LC IDE is that these programs are called without a full path to them, hence the need to set the path.
On OS X the "home" folder is within the "Android Studio.app" and the path should point to that folder (javac is within a folder within home/).
To discover the location of the SDK of Android Studio, in the preferences/configuration of that tool under the "Android SDK" entry you can find a field marked "Android SDK Location". On OS X that will be something like /Users/bernard/Library/Android/sdk. To be able to choose that location using OS X (Big Sur at any rate) you will need to use cmd+shift+g to open up a field to be able to navigate to that location so that you can click on the "sdk" folder to satisfy LC's file dialog.
When it came to getting LC prefs to find the JDK with the one bundled with Android Studio even using cmd+shift+g was not sufficient to enter into the Android Studio package contents from inside LC's file dialog. I used Finder to open the AS app contents, then created an alias that pointed to the enclosed "jre" folder. I copied the alias to "jre" outside of the package (to the folder containing Android Studio). Then, from within LC's pref file dialog (accessed from the tip above to make the selection button visible), I navigated through the alias to the folder to select "jre/jdk/Contents/Home". This was accepted by LC prefs and inserted as the content of the field marked "JDK Path:" in LC prefs.
In compiling an app using 9.6.2 on a M1 Mac I'm getting an error "could not encode class bundle". This is being thrown at the point where LC tries to call Android's dx tool. By putting the following
answer (shell("which javac"))
before each point where LC shells out to the relevant Android compilation stages, it is clear that LC is switching from using the Android Studio Javac to using /usr/bin/javac at this point and then failing. This suggests to me that at this point the OS path used by LC is getting screwed up. The DX tool is being called without knowing how to find the JDK.
I finally got passed the "could not encode class" error, which was due to something strange the LC code is doing. When it comes to the DX part of the compilation/install to device, LC does not set the Java path when the OS is MacOS (this doesn't matter at the earlier steps in the process of compiling for Android, as the Java path is passed into the doShellCommand function in those steps, but now with the DX phase).
This is the change I made in the stack "edit the script of stack "revSaveAsAndroidStandalone":
Once I'd changed that conditional to have it include the Java path before calling the DX command, compilation for OS X works.private function doShellCommand pCommand, pArguments
[... snip.... ]
else if the platform is "macos" then
# put tCommandPath & ":" before $PATH
# above the line found in that stack is now disabled, my replacement is on the line below, making the Mac branch consistent with Win/Linux
put tCommandPath & ":" & sJavaRoot & "/bin" & ":" before $PATH
else if the platform is "linux" then
[... snip.... ]
I can't explain why this failure occurred on my new M1 Mac when my original use of Android Studio (with its JVM) was working on my old Intel Mac. I can only assume there was some step I had used before that I missed from my instructions, and that this missed step somehow set up the Java environment at the OS level, such that this DX step not setting that up did not matter. Maybe it's to do with Big Sur defaulting to /bin/zsh rather than /bin/bash?