android binary release problem.

[adderly]

Hey @yvanvds , i've been trying to set up the library for linux and android. In the linux system, i cannot find a way to build it because the binary is not provided. Not even build files for it. In android i tried to integrate it with a qt app that i have, but the library fails when i try to use the system, init it or whatever. The problem is with the android: The code i execute:

bool inited_yse = YSE::System().init();

The result i get : I/Timeline(16078): Timeline: Activity_idle id: android.os.BinderProxy@1fb70daf time:162989616 I/JUCE (16078): JUCE Assertion failure in juce_android_SystemStats.cpp:106 F/libc (16078): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 16260 (QtThread).

From what i could see the juce_android_SystemStats.cpp, is that the AndroidEnv is null which leaves me nowhere as i don't know anything about JUCE.

Any ideas?

[yvanvds]

Hey,

did you build YSE yourself or did you use the provided binary? And are you using it in linux or with windows?

[adderly]

@yvanvds I used the provided binary, i am in linux and i came across that the build file for android is PowerShell. You think could be a Juce problem? I really want to test it out, is there any test i could use to check if it works?.

[yvanvds]

Ok, the binary is built on Windows, but I think that should not matter. I did create an app with the dynamic library (the YSE demo found in the playstore) and had no such problems.

However, I made that with a game engine (esenthel) which takes care of most of the configuration issues for me. To be able to recreate your problem I would have to set up a native application myself. I've never worked that way, so it won't be done in a few hours, i suppose.

I'll see when I can find some spare time to do that.

[adderly]

Great, i can help if needed. Lets put some of those demos into android.

[yvanvds]

Ok, I just recompiled my android demo and it does have the same problem. Something is changed in JUCE. I'll try to figure it out today.

[yvanvds]

I did some research and concluded this problem will take several steps to solve.

1. The assertion failure comes from the fact that juce projects now also setup some java classes to retrieve SDK information that cannot be retrieved with the NDK alone. Juce developers work with the introjucer, which generates these classes automatically. There's quite a lot of those, and there's a good chance we will need only one to get YSE back to work. It's even possible that the info is not really needed and that commenting out a few lines in JUCE would be enough to fix this.
2. To do that, I must run an android app in debug mode, with breakpoints. The game engine I work with makes it very easy to compile crossplatform, but this it cannot do. Since you (and other people) are also asking for a decent android demo I think it is best to create one and use that to debug the error. This way I solve two issues at once.
3. Last time I made a `plain' android app, I used eclipse. Since eclipse is deprecated for Android development, and this also has to serve as some sort of example application, that will not do. So I have to figure out android studio first.
4. Android studio has NDK support, but there's the old way of doing things and the new `experimental' way. It does not make sense to start working on a demo app using the old way that eventually be deprecated. But the new approach is not stable yet. And there's not a lot of info or tutorials about it, so I'm limited towards gazing at the google examples.

This means I will have to explore android studio first, study the new NDK approach, and find out how to use an external library in there. And of course I won't be able the game engine I normally use for the visual side of the app. So I'll have to dabble into openGL or find a very simple way to provide some screen info and interaction. (It is meant to be a demo app, so I'm not sure if it is wise to include another 3rd party library.) After that, I can start solving the actual problem :-).

I'll get started on this now, but it will take time.

[adderly]

Ok, i see. I had that presumption about the bug. You can actually create the app without android studio if you want, a gaddle file and the JUCE java classes will do. The thing that i think its not good about android keeps coming around all the time and that is; the sdk is not accesible from the NDK.

With the java classes to implement, it is really not library like the way users(me,other) to integrate the yse, imagine i have my app with my already java code probably i will need to add some glue code there and there. Anyways that's the only way to go, untill google grow up in that area.

I'll wait patiently for the good news. Anything you know where to find me. ;)

[yvanvds]

I'm sorry, but there's no good news. I've tried several approaches over the last two weeks, but none of them works. Over the last year, Juce started to use a lot of JNI code and Java classes to go with it. As a result, the gui, threads and audio properties are all intertwined. I cannot initialize audio anymore without using the full Juce ecosystem.

You could try reverting to an old github version of Juce. The one from august last year should work, because I did build an app with that one. But that one does not compile with the current NDK version, nor does it support MSVC 2015.

Right now, I cannot spend any more time on this, nor do I have any good ideas left for a way around this. So the android version of YSE will be placed on hold for the moment. I'll update the documentation accordingly. Maybe during the summer I will find some time to look into alternatives.

[adderly]

Sad news man.
Summer!? That's a long gap, i guess i'll need to work around it. Supposedly it could be easily done with the whole JUCE ecosystem? Maybe now this inspire you to move a little away from JUCE, hopefully.

[yvanvds]

Glad to be able to close this now. I finally found some time to remove the JUCE dependency.