Posts Tagged java

Posted on Programming

Trigger vibration on Android from Heaps/Hashlink

I wanted to trigger vibrations in Hexlock – so I did, and here’s how! I am not saying this is the best, correct, or even a good way to go about it. It’s just what I did. Maybe it will help.

I added a static function to my Main class, the idea being that it would do nothing unless I was compiling for Android. (I added -D android to my compile-to-c.hxml for just this purpose). There may already be a hlNative one, but who knows at this point. I didn’t see one, and adding -D android was easy enough.

#if android
public static function vibrate(i:Int) : Void { }

When compiling to C code for Hashlink, calls to that function (Main.vibrate(i)) get replaced with Java_io_heaps_android_HeapsActivity_vibrate(i), which I defined in my jni.c1 file.

JNIEXPORT void JNICALL Java_io_heaps_android_HeapsActivity_vibrate(int duration) {
    (*jvm)->AttachCurrentThread(jvm, &thisEnv, 0); 
    jclass cls = (*thisEnv)->FindClass(thisEnv, "io/heaps/android/HeapsActivity");
    jmethodID method = (*thisEnv)->GetStaticMethodID(thisEnv, cls, "vibrate", "(I)V");

    __android_log_print(ANDROID_LOG_DEBUG, "JNI.c", "Vibrating: %d", duration);

    if (method > 0)
        (*thisEnv)->CallStaticVoidMethod(thisEnv, cls, method, duration);

You’re probably wondering where thisEnv comes from, and if you are I can help! I modified my startHL() function to be:

JNIEnv* thisEnv; // I want access to these from other functions
JavaVM  *jvm;
JNIEXPORT int JNICALL Java_io_heaps_android_HeapsActivity_startHL(JNIEnv* env, jclass cls) {
    thisEnv=env; // Store the JNIEnv for later use
    (*env)->GetJavaVM(env, &jvm); // Also the JVM
     return main(0, NULL);

As you can see from two functions back, the code assumes there is a vibrate() function in, and there is, because I added one.

    static public void vibrate(int duration) {
        Log.d("", "static vibration call");
        Vibrator v = (Vibrator)instance.getSystemService(Context.VIBRATOR_SERVICE);

And now it vibrates! You can find out more about the files I’m referencing (including a Git repo hosting them) here.

Posted on Programming

Presenting Hexlock, a really fun game™

Hexlock, a simple counting-based puzzle game, now available for your Android device.

Select a level, defeat it, and repeat.

There are twenty-one levels in total, each represented by a different tile on the level select screen, and you can play them in whichever order you like.

In each level, you start by clicking the middle tile. From there, just form a path from neighbour to neighbour until the two numbers at the top match up. Once they do, you’ve won!

The hex tiles each have a value, represented in hexadecimal. The goal is in binary. All you need to do is form a path such that the hex values add up to the binary goal. You can do that by adding and converting between bases in your head, or, you know, just click around until it unlocks.

Once you’ve defeated a level, how well you did will be reflected in that level’s tile on the level select screen. Grey if you have yet to complete the level; green if you scored par or under; blue if you scored under 2 par; orange for less than 3 par; or red if your path was longer than 3 par.

Only your highest score for each level will be saved, and if you ever want to review that path, long press the hexagon for that level in the level select.


  • Clicking on the most recently selected hexagon will unselect it.
  • Press and hold (long press) the middle tile to reset your current level.
  • Press and hold (long press) a level to load your highest scoring path.
  • Press the back button on your phone, or escape or backspace on a keyboard to return to the level select menu.

Download it today in the Google Play store!


Or, if you don’t have an android device, you can play the web version here.

1. This is not true; very few people rate things in hexagons these days

Posted on Programming

Hello World; Heaps on Android

Hello, and welcome.

As there’s no way for you to reasonably know, I built a puzzle game recently – in Haxe, using Heaps which I had only used once before, for a website that required a 3D can. Which may seem strange, but I assure you it made sense at the time. Anyway, Heaps seemed fairly nice, so I figured I should try it again.

But I wanted it to be an Android app.

Which is okay, because Heaps works on Android. It says it right there on the website! Unfortunately, there’s not much info on it beyond that, and compiling Heaps for Android turned out rather less straight forward than I had hoped.

Fast forward five days of debugging Android Studio configurations and C code, and I now have a simple Heaps app running on Android. And it’s on GitHub!

It’s built based on a couple of repos1, 2, the second of which was particularly helpful, but I had to mix and match some things between them.

I don’t intend to keep it up-to-date unless I have a use for it, but it works as of November 11, 2022.

How it works

The Haxe code lives in app/src/main/haxe. It’s a basic Heaps hello world project set up for VS Code, as described in the documentation section of the Heaps site. There’s a compile.hxml file which tells the compiler to place the generated C code in the out/ directory of the cpp folder.

The C code lives in app/src/main/cpp. It contains git submodules to some of the necessary libraries, as well as a CMakeLists.txt. Android Studio uses that during its build process. You can find out more about the other things there at the link, above.

This is also where the JNI function for the heaps app lives (in jni.c).

The Java code lives in app/src/main/java, is the entry point to the Heaps hello world and triggers it to run. It extends which handles a bunch of the SDL stuff. Add your own classes as necessary if you want, I probably won’t!

Each of those directories contains a readme with some info about what they contain.

One important note: The NDK version.

It didn’t work with any of the NDK versions I had installed. I ended up having to download r18b and use that. I placed it in the ndk/ folder of my Android SDK directory. You can find this under File > Project Structure, and then by clicking SDK Location.

So I placed it in C:\Users\Brad\AppData\Local\Android\sdk\ndk.

But that’s not all – apparently Android Studio expects the ndk version directory to be named a certain way, so I named mine 18.1.1.

The Android Studio project in the Git repo expects that, so if you name it something else, update build.gradle to reflect that.

After that it should just be a matter of clicking build in Android Studio.

Problems along the way

As you can imagine from the heading nearby I ran into so many problems along the way. So many problems, and so many android log statements.

But my memory is terrible, and Google found surprisingly few results, so I’m going to catalogue some of them here. You know, for next time. You should be able to ignore this portion, they should all be addressed already in the repo code.

OpenAL needs needed by not found.

I tried a bunch of things for this, but the solution turned out to be adding arguments -DANDROID_LD=lld to the app file.

hashlink/src/std/types.c error: undefined reference to 'hl_zalloc'

hl_zalloc is defined in hashlink/src/gc.c. I added that to CMakeLists.txt when building the Hashlink library.

fatal error: 'minimp3.h' file not found

Added hashlink/include/minimip3 to the target_include_directories for fmt.hdll, in CMakeLists.txt.

java unsupported major.minor version 52

I updated to Java 1.8.0.

E/EGL_emulation: eglCreateContext: EGL_BAD_CONFIG: no ES 3 support (and a bunch of other SDL / window creation errors)

These seemed to go away when I tracked down that Hashlink uses version 3.0 for mobile, added the appropriate declaration to my AndroidManifest.xml, and fiddled with the settings in the emulator. Honestly I’m not sure what ended up fixing these things because nothing did and then I restarted Android Studio and everything was magically working.

At which point I was just willing to accept that.

Posted on Programming

haxe java target for android demo code

Man, I am having the hardest time naming these posts, but I promise that I’m not just typing random words next to each other.

I’ve uploaded the code for my demo from Cauê’s presentation; which you should be able to browse or checkout if you want to try it for yourself. There’s a description.txt file in there that should.. you know, describe some things.

Hopefully I didn’t break it between then and now! That would be embarassing, but let me know if that is the case and I’ll try to fix it and feel shame simultaneously.


In case you missed it, the code is here: java toast/

If you want to read more about the demo, I’ve talked about it in a few of my past posts:

  1. My experience getting started with the Java target for Haxe
  2. How I set up my NME project directory for Haxe to Java for Android
  3. The Haxe code for java, and how I used Android’s native interface XML stuff

That’s all!

Your friend,


Posted on Programming

haxe to java for android (part 2)

Last time I discussed setting up a project to create java code, for android, from haxe. I left out some neat stuff because it was already pretty long. If you read it, you probably noticed.

For example, the program was called Haxe-Java Toast, which from the code presented is wildly inaccurate. Well, maybe not wildly, but you get the idea.

My goal was to do was create an android application with its interface defined by XML, and which called a function from the Android SDK (in this case triggered a Toast). What I pasted last time was a subset of the code in

There may end up being a lot of code here.


Posted on Programming

haxe to java to nme to android! (part 1)

NME is a great solution for writing applications for the Android platform, but sometimes it’s nice to escape the confines of This is fairly easy to do, but unfortunately until now it meant writing Java.

Which is fine for some people, but given the option I’d avoid it. (For one thing, it’s lead me to using two separate editors simultaneously: FlashDevelop and Notepad++.)

The convenience of using NME, along with the power and freedom that comes from using Java for Android, without ever having to leave HaXe, is one of the benefits of HaXe’s upcoming Java target. And for me, it’s a pretty major one.

There are three main steps. The first is writing the code, and the other two are the two-stage compilation process. I imagine most of the stuff I discuss will end up being automated nicely, but for now this is how I went about it.