Android beginner: how add the library?


#1

So embarrassing :-(((((((((((((
Of course TestLibMuseAndroid works. But creating my own new project with NavigationDrawer already fails at
MuseManagerAndroid.getInstance(); -> System.loadLibrary(“muse_android”)
with
"Failed to load libmuse_android.so. Make sure the jni symbols are accessible somehow."

WTF is “somehow” ?

build.gradle:
dependencies { testCompile 'junit:junit:4.12' compile 'com.android.support:appcompat-v7:23.4.0' compile 'com.android.support:design:23.4.0' compile files('libs/libmuse_android.jar') }

Please point me to a stupid step by step tutorial.

So embarrassing to again and again and again waste hours and hours and days and days with all this linux legacy crab :-/

one hour later :-/

Adding D:\StudioProjects\MuseShit\app\src\main\jniLibs\armeabi-v7a\libmuse_android.so

and
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.BLUETOOTH" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

sometimes works :-/

And when i do that with my full project,
System.loadLibrary(“muse_android”);
hangs with the error java.lang.NoSuchMethodError: no non-static method “Lcom/choosemuse/libmuse/MusePlatformInterface;.connect()Z”

WTF is “Lcom/…:” ???

There is no “Lcom” in my entire project folders files.


#2

From what you have described, the gradle file looks correct.

The location of the JNI library (libmuse_android.so) looks correct as well.

Note that JNI libraries are specific to CPU architecture and LibMuse only contains a library that works on ARM processors. If you are running your application on a x86 architecture, you can run into problems loading the library.

When you are testing the full project, are you testing on an architecture other than ARM?


#3

Thank you for taking my WTF lightly :slight_smile:
I am testing directly on my LG G3 so only ARM.

I don*t think you can help me with a specific problem as by now i somehow(!) succeeded.
But it took me two days and i really fear to do a new project from scratch.

Your beginner tutorial to simply download a finished Android Studio project is not that helpful when starting with a new project.
So i really would like to see a video tutorial that shows building a basic Muse app from scratch.

Maybe someone can point me to a nice tutorial :slight_smile:


#4

Good to hear that you were able to get it working.

Thanks for the feedback about the getting started example. I agree a video tutorial would definitely help.

In the meantime, perhaps this will help for future reference. To start a new project, you need to do the following:

  1. Copy libmuse_android.jar to the “app/libs” directory of your project.
  2. Create a “jniLibs” directory under “app/src/main”.
  3. Copy the “armeabi-v7a” directory from the “libs” directory of your LibMuse installation to the “jniLibs” directory you just created.
  4. Add the following line to “app/build.gradle” under “dependencies”:
    compile files(‘libs/libmuse_android.jar’)
  5. Make sure that you set the context for MuseManagerAndroid at the start of your program:
    manager = MuseManagerAndroid.getInstance();
    manager.setContext(this);

#5

Here are the 4 rules for picking android libraries that I swear by:

  1. It is open-source with commerical-friendly licenses

    Since I write most of my code for my clients, whatever libraries I bring in MUST be commercial-friendly (Apache/MIT/similar) – otherwise my neglect will put my clients in a legally precarious position. Personally, I like to open-source under MIT and Apache as well.
    I understand the spirit and the benefits of GPL, but it just doesn’t sit well with me to be handcuffed by it (this is a huge flame-war topic, which I want to stay out of).

  2. It has more than 1,000 stars on Github

    To me, 1000 signifies enough traction that the library won’t suddenly go away. There is often enough of a community to keep it going, keep updating, finding bugs, etc…
    Also, when you’re > 1000 stars, you can sometimes start calling that library the ‘de facto XYZ library’ which I find comforting.

  3. It has made it past v1.1.0

    I know according to SemVer and other systems, 1.0.0 means production-ready, but it really doesn’t. v1.0.0 is when the masses start using a library, and that’s when a lot of flaws come out of the woodwork too. I like to first see some patches come out (and maybe a small feature addition or two), before I use it.
    Keep in mind, I’m referring to third party libraries, not platforms/frameworks/languages, which are usually pretty solid when they hit 1.0.0 (NodeJS is a great example of a prolific platform in production that hasn’t even hit 1.0.0!).

  4. It is maintained by people/companies I trust

    When Google, Twitter, Facebook, etc… are putting libraries out there, you can bet they’re used internally a fair amount. My take away from this is that these should be battle-tested libraries, with a commercial backing that won’t disappear overnight.
    A prime example of this is protocol buffers. I can use protobufs in production without worrying that Google with suddenly stop supporting it, or make massive, non-backwards-compatible API changes – because they just can’t do that, as protobufs are used extensively internally.
    A potential downside of libraries with massive backing is that they’re not really updated as often, which I personally don’t view as a downside. If I’m putting something in production, I don’t want to see 5 patches come out within a week! That’s a library that’s not ready for prime-time (aside: take a wild guess what happened to a ‘production-ready’ library I was using last week that caused 14,000 crashes in the field in three days).