Android Indoor Location sdk classdefnotfound error


#1

I am developing an Android app in Appcelerator, which complicates this a little because I have to manually include all of the sdk dependencies. However, I have included all of them as you can see here:

So everything should be working. However when I try to create an IndoorCloudManager using the IndoorCloudManagerFactory I get this error:

[ERROR] : HyperloopProxy: (main) [286107,286285] Exception thrown during invocation of method: public final com.estimote.indoorsdk.cloud.IndoorCloudManager com.estimote.indoorsdk.cloud.IndoorCloudManagerFactory.create(android.content.Context), args: [com.worthingtonindustries.estimote.EstimoteApplication@37dd9581]
[ERROR] : HyperloopProxy: java.lang.NoClassDefFoundError: com.estimote.indoorsdk.b.a.d

This is strange because when I open up the indoorsdk-1.0.1.aar using winRAR I can navigate to the class com.estimote.indoorsdk.b.a.d, and it does in fact exist in the aar file.

Similarly, if I try to call the .build() method on my IndoorLocationManagerBuilder I get this error:

[ERROR] : HyperloopProxy: java.lang.NoClassDefFoundError: com.estimote.indoorsdk.b.b.am

I cannot find any reason why this is happening since most of the indoorsdk-1.0.1 is working properly, so I was wondering if anyone has any insight into this problem, or if it is potentially a bug in the sdk. Thanks in advance!


#2

This problem I am facing seems to be because I need to use the dagger-compiler-2.9, which is a Java Annotation Processor, but in Appcelerator there seems to be no way to use this, as far as I know. So, I will need to find a way to make that work in Appcelerator.

Will the indoor sdk always be dependent on Dagger? Or is that something that might be phased out of the sdk at some point?


#3

Hi,
The plan is to keep Dagger 2 permanently. It’s pretty cool dependency injection framework and it help us a loot to manage internal SDK architecture. However, dagger-compiler is something which is used during our SDK compilation (it processes annotations and generates some classes based on them) and It should bring no impact on runtime, when SDK is included in client’s projects.
So it seems that we could slightly change the way we are defining dagger-compiler dependency to do not depend on it at runtime at all.
We’ll try to include this update in upcoming SDK release, Then we’ll see if it addresses your issue :slight_smile:

Regards
Wojtek


#4

Actually I was originally not using the dagger-compiler, which was causing the runtime error, but now I am trying to use it, which causes a compile-time error. So no need to make that change in your sdk (but thanks for considering sdk changes based on the needs of a single user! You guys are the best!).

I am getting this compile-time error:
[ERROR] : Failed to run dexer:
[ERROR] :
[ERROR] : PARSE ERROR:
[ERROR] : MethodHandle not supported
[ERROR] : …while preparsing cst 016c at offset 00001ceb
[ERROR] : …while parsing com/google/googlejavaformat/java/JavaInput.class
[ERROR] : 1 error; aborting

and discovered that when I open that JavaInput.class file with a java decompiler the decompiler gets an internal error because it can’t decompile it (although it can successfully decompile all other files in the jar). So I am still trying to track down the problem but it seems to possibly be something with the googlejavaformat jar or how Appcelerator handles it, and it likely has nothing to do with anything Estimote is responsible for. But I will update here if I find anything else relevant.