Java 1.7 compatibility problem
am2222 opened this issue · comments
Hi,
I wanted to add your project into my android stodio project using gradle but I faced this error
Error:Error converting bytecode to dex: Cause: Dex cannot parse version 52 byte code. This is caused by library dependencies that have been compiled using Java 8 or above. If you are using the 'java' gradle plugin in a library submodule add targetCompatibility = '1.7' sourceCompatibility = '1.7' to that submodule's build.gradle file.
Is there any solutions to fix it?
I am also facing same issue
@am2222 @mayurcools The trilateration library was compiled against java 1.8 (java 8). Can you use java 8 for your project, by adding something like the following to your gradle build?
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
Let me know if that works or doesn't work for you. Thanks!
@lemmingapex Hi,
I have tried this method before and faced lots of gradle errors. chiefly I faced installing jack on android studio. Here is my question in stackover follow http://stackoverflow.com/questions/41648012/java-1-7-compatibility-for-a-library-in-android-studio/41648160#41648160
I was about to come here and open an issue regarding this. I was facing the exact same problem. Then I enabled Jack Options. Now I am getting this error and I don't know how to get around it. What it says is not the issue I think, I am assuming this because I have tried every method and combination of heap size values as well. This is the error I am getiing:
` Error:Execution failed for task ':app:transformClassesWithPreJackPackagedLibrariesForDebug'.
com.android.sched.scheduler.RunnerProcessException: Error during 'CodeItemBuilder' runner on 'static void org.apache.commons.math3.util.FastMathLiteralArrays.() (FastMathLiteralArrays.java:28-5102)': Java heap space
e, the following line, in the gradle.properties file, sets the maximum Java heap size to 1,024 MB:
org.gradle.jvmargs=-Xmx1024m
Read Gradle's configuration guide
Read about Java's heap size`
Here is my app.gradle:
` apply plugin: 'com.android.application'
android {
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "com.example.junaidyasin.trilaterationexample"
minSdkVersion 21
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
jackOptions {
enabled true
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
compile 'com.android.support:appcompat-v7:25.1.0'
compile 'com.lemmingapex.trilateration:trilateration:1.0.1'
testCompile 'junit:junit:4.12'
} `
Here is my top level gradle:
`buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.2.3'
}
}
allprojects {
repositories {
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}`
@lemmingapex can you please be kind enough to assist me regarding this?
@junaidyasin Glad you were able to get jack options working for your build. Do you have any advice for @am2222?
Internally, the trilateration library uses the Apache Commons Mathematics Library. Judging by the error @junaidyasin posted, it looks like some of the apache common math library is being passed through the jack toolchain, and the virtual machine might be running out of memory. The section of apache common math that gets spit out in this error is in the file FastMathLiteralArrays.java, which contains several long arrays of doubles (these appear to be precomputed values that the math library uses). So a memory exception makes sense. If your machine has more available memory, you might see if it's possible to allocate more memory to this process. I'm not entirely sure how to do this, but the error suggests that adding something to gradle.properties might work. Something like this would give the vm a maximum of 4GB:
org.gradle.jvmargs=-Xmx4096m
Hope that information is helpful. Let me know if find something that works. Thanks.
@lemmingapex thanks for your answer. I could not manage to fix my problem with jack, I copied your code and created a new project to test if it works on 1.7 or not and it worked and compiled, I did not test it yet, I'll let you know the result.
@am2222 I got the Jack Options to work by simply putting jackOptions { enabled true}. Better yet, just match my gradle files with yours and make sure to include all the dependencies and repositories and use Java 1.8. That is how I got it working.
@lemmingapex thanks for your prompt and detailed answer. Your solution fixed the problem! I already tried the values upto 2048, it didn't occur to me try a greater value.
There is something off topic I need to ask you if you don't mind. I am working on an Indoor Navigation project using iBeacons. I already tried a trilateration solution with n=3. The result is not that accurate and makes a huge difference when applied in a real scenario. Do you know any similar project/case in which this library was used for Indoor Navigation using BLE beacons? The methodology is the same, I have N number of beacon coordinates and their respective distances. Thanks in advance!
Edit: Also, can you please enlighten me that does the distance unit or map unit have an effect on the calculation? Like currently I have my own assumptive latitude and longitude on our map plane, and the distance is in meters. Will it have an effect if I change my units to lets say, actual latitude and longitude and distance in feet? Thanks for bearing with my questions.
@junaidyasin Hi, I am trieng your solution. I am working on indoor mapping and I have faced the problems as you. It seems we can share some information to find a working solutions. I think the main problem is with beacons
As I know the unites must be in meters, So first project your point into UTM
@junaidyasin I have experimented a bit with iBeacons. In my experimentation, I assumed that the RSSI was strongly correlated to euclidian distance. Theoretically: in a world with ideal antennas, no surfaces that might cause unwanted effects (likely multi-pathing, or interference), and no other signal noise; then RSSI would likely correlated to distance (whether linearly, logarithmically, quadratically, etc.). Using RSSI and iBeacons the real world, my experience showed that this turns out to now be the case. The RSSI measurement error was too great to get anywhere close to accurate distances. That being said, many groups have used other methods and technology to obtain much better results. Clever uses of different frequencies other than bluetooth (such as wifi access points) could change results. Using other metrics instead of RSSI (such as time of flight, or methods based on frequency phase shifting) could alter matters. And of course smarter software like filter algorithms and noise detection could be used to increase accuracy. Hopefully that information helps.
Question: Does the distance unit or map unit have an effect on the calculation?
Good question. I don't know how much I've tested this. In a case where you are using centimeters instead of meters, I would hope that the results of trilateration should be consistent. See the first to tests: https://github.com/lemmingapex/trilateration/blob/master/src/test/java/com/lemmingapex/trilateration/TrilaterationTest.java#L14-L42
The second test is scaled by 1000; and results are consistent.
That being said, the coordinate system you use is very relevant. Trilateeration expects inputs in euclidean space. So if you are not converting (latitude, longitude) coordinate inputs to a euclidean system, your results will of course be incorrect. See this for more information: #1
Does that answer your question?
@lemmingapex thanks for your detailed answer, Which methodes you mentioned you think gives better results?
I'm not entirely sure which methods would be best @am2222. Depends on your application and use case I suppose.
It sounds like @junaidyasin got everything working with java 1.8. Did you get a working setup @am2222?
If you both got your builds working, I'm going to close this ticket.
@lemmingapex Hi, No I still have some problem with enabling jack on android studio, Now I am going to add org.gradle.jvmargs=-Xmx4096m in gradle
Do you know any sources about how to run time of flight in java?It seems it returns better results than RSSI method
@lemmingapex I used org.gradle.jvmargs=-Xmx4096m and it works fine now. thanks
@am2222 Great, glad you got it working. Feel free to hit me up if you have more questions. If you guys found the library helpful, please consider starring trilateration on github. Thanks!
Hey,
this isn't working for me. What are my options for Java 8 as Jack was discontinued?
@jossiwolf I don't know too much about Jack. It appears that the android folks a pushing more java 8 native support into newer version of android and android studio. The information here might help you: https://developer.android.com/studio/write/java8-support.html
Please share whatever you might find useful. Thanks!