I managed to deploy my project onto the phone by performing the following steps:
Build the project in jME (do not run it)
Import the resulting jME ‘mobile’ directory into Android Studio
When Studio asks, convert the project to use gradle
Upgrade gradle if asked to do so to enable instant run
Connect the phone
Run the Studio project (the phone automatically runs the app)
This worked, much to my surprise, but it’s a bit of a hassle to have to jump through these hoops every time I want to test on the phone. Hence, it would be great if I could get this working from within the jME SDK.
@aegroto: No I haven’t done that yet but I think that’s my next step. I have been trying to understand where this error is coming from and it seems it’s netbeans 8.2 and JDK 8 specific, that is, that particular combination. That’s at least what other projects unrelated to jME are saying about this error. To try to confirm that I executed the exact same ant command as NB is using but from the command line; it ran without errors and the app launched on the phone. That’s maybe not a confirmation but it sure is an indication that NB (or one of its plugins) might be causing this.
I’m trying the BootMonkey route but I don’t quite understand how it all fits together. Some questions:
Can I use the Android template @aegroto created from within the jME SDK? If so, how do I install it?
Do I somehow need to install BootMonkey explicitly (in the SDK, as a command line tool or somehow accessible by gradle)?
What I have tried so far is to clone the Android Template and run ‘gradle wrapper’. I have no idea if that’s what I’m supposed to do but running ‘gradlew’ directly complained about a missing jar. Googling turned up the wrapper command. After having fixed some Android SDK paths and version numbers it bombs out with the following error:
FAILURE: Build failed with an exception.
What went wrong:
A problem occurred configuring root project ‘JMEAndroidTemplate’.
failed to find Build Tools revision 25.2.5
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
Total time: 0.73 secs
I also tried SDK Tools version 25.3.1 with the same result.
What am I missing or am I doing this completely wrong? Some help appreciated
Well, the target issue only comes into play when you use Android SDK (ASDK) version 25.3.0 or newer, since the ‘android’ command has been deprecated in that version. The jME SDK uses the android command to get the list of available targets. Older versions of the Android SDK work fine in this respect.
I took a quick look at the new commands (sdkmanager and avdmanager) in ASDK 25.3 and I did not see a way to produce the list of installed targets in a similar way the ‘android list target’ command did. In fact I did not see any command options that shows me what actually was installed! I’m sure there is a way to get the list but it might require some digging, at least more than my brief look.
sdkmanager --list tells you what SDK tools are installed and the android platform serial numbers - I was kind of hoping to get the same target list (target version numbers) as from the android command and kind of just saw the ‘Available Packages’ output, which isn’t that helpful in this case. Ah well, I suppose it’s easy to map between the serial numbers and the version numbers …
Sure but isn’t NBAndroid capable of managing the targets and installing new images and such?
I tried to play around with sdkmanager and avd for nearly a day and well, it wasn’t that easy, let alone the fact that you need to configure the avd to point to the correct system images when you have a custom avd location and all that fuzz.
Plus that stupid text truncating does not help, you can use --verbose but yeah parsing isn’t that easy.
It also feels like doing what has been done three times already. In addition to that there seems to be a sdkmanager.jar at least for the old sdk version before the new tool came, maybe we can directly call that?
Honestly the best would be an android studio exporter I think because we have many things to consider otherwise, let alone debugging and all that stuff.
Well the current jME SDK functionality is nothing more than an exporter really. We use command line tools to create a - basically standalone - Android project and just inject the needed code and jars to that, then let that project do its thing, controlling it from the outside through ant.