Problems compiling the project spatialite-android

[Jim]

I am using Eclipse with ADT on Windows 7 to build the spatialite-android project that comes with the source for the Spatialite 4.0.0 for Android from Sebastian Krysmanski.

The only compile errors I have left are those involving jsqlite, e.g., "import jsqlite.Exception;"

I just can't seem to find how to resolve these compile errors.

Anyone have any idea?

Regards,
Jim

[andrea antonello]

> I am using Eclipse with ADT on Windows 7 to build the spatialite-android
> project that comes with the source for the Spatialite 4.0.0 for Android from
> Sebastian Krysmanski.

Does that mean you are compiling the native project? Just to make sure.

> The only compile errors I have left are those involving jsqlite, e.g.,
> "import jsqlite.Exception;"
>
> I just can't seem to find how to resolve these compile errors.
>
> Anyone have any idea?

This looks like you have a project referencing the spatialite-android
libs, but they are not there.

If you download:
http://www.gaia-gis.it/gaia-sins/spatialite-android/spatialite-for-android-3.0.1.zip
You will get in the zip:
* the native spatialite libraries: they are placed in a folder named
libs and contains several folders for different platforms that hold
the main library, called libspatialite.so
* the basic API classes, contained in the jsqlite package -> these
seem the ones you are missing

Cheers,
Andrea


>
> Regards,
> Jim
>
> --
> You received this message because you are subscribed to the Google Groups
> "SpatiaLite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to spatialite-use...@googlegroups.com.
> To post to this group, send email to spatiali...@googlegroups.com.
> Visit this group at http://groups.google.com/group/spatialite-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jim]

I have downloaded the link you mention but there is no libspatialite.so anywhere to be found. 

I did find libjsqlite.so and placed it in the libs directory.

Nothing changed.

I then tried Sebastian Krysmanski's Spatialite 4.0.0 which is based on your 3.0.1 work.

It has both libraries (libspatialite.so and libsqlitex.so) which I placed in the libs directory, still no joy.

I must be missing something in the way Eclipse works (I am new to it) so I will continue trying.

Oh yes, I am building for Android 4.2.2 on a Nexus 7.

Regards,
Jim

[andrea antonello]

> I have downloaded the link you mention but there is no libspatialite.so
> anywhere to be found.
>
> I did find libjsqlite.so and placed it in the libs directory.
>
> Nothing changed.
>
> I then tried Sebastian Krysmanski's Spatialite 4.0.0 which is based on your
> 3.0.1 work.
>
> It has both libraries (libspatialite.so and libsqlitex.so) which I placed in
> the libs directory, still no joy.

I apologize, something has changes since I wrote the tutorial or I am
gone completely crazy.
Anyways I downloaded the link and there are complete projects in there.
So the new way to do so is:

Assuming you unzipped the folder and have the following inside it:
COPYING
COPYING.LESSER
README.txt
spatialite-android

then you have to copy in your new project (or the one online on bitbucket):

1) the complete folder (exactly as it is):
spatialite-android/spatialite-android-library/libs/
it contains all the native libs already in the right structure

2) the folder: spatialite-android/spatialite-android-library/src/jsqlite/
inside the src folder of your new project.

Then you should really be good to go. Sorry for the confusion caused,
not sure what happened.

> I must be missing something in the way Eclipse works (I am new to it) so I
> will continue trying.

I think you are just missing the java packages that link to the
aforementioned native libraries.
That would be the "jsqlite" mentioned above.

Regards,
Andrea

> Oh yes, I am building for Android 4.2.2 on a Nexus 7.
>
> Regards,
> Jim
>
> On Friday, May 10, 2013 9:56:07 PM UTC-6, Jim wrote:
>>
>> I am using Eclipse with ADT on Windows 7 to build the spatialite-android
>> project that comes with the source for the Spatialite 4.0.0 for Android from
>> Sebastian Krysmanski.
>>
>> The only compile errors I have left are those involving jsqlite, e.g.,
>> "import jsqlite.Exception;"
>>
>> I just can't seem to find how to resolve these compile errors.
>>
>> Anyone have any idea?
>>
>> Regards,
>> Jim
>

[Jim]

OK, that did it.

I can now compile cleanly with 13 Warnings in jsqlite which are mainly about unused variables and that "Vector is raw....".

So the next step was to try and run spatialite-android on the emulator through Eclipse.

The apk is built and sent to the emulator.

During the apk install the error "INSTALL_FAILED_MISSING_SHARED_LIBRARY" is posted to the console with no additional information.

I have made absolutely no changes to the source other than what you mentioned.

I have the Google APIs installed via the Android SDK Manager.

I tried to build SpatialiteCookbook but it tries to "import eu.geopaparazzi.library.util.ResourcesManager;" which isn't available so I can't try it.

I  built my own Spatialite app which is the "Hello World" app with an attempt to open a database. It also gets the error on install.

The usual "Hello World" app works fine.

I am building for and trying to execute on Android 4.2.2.

Any ideas would be greatly appreciated.

Regards,
Jim

On Friday, May 10, 2013 9:56:07 PM UTC-6, Jim wrote:

[Jim]

I am sorry but I am having trouble getting my posts straight.

I can find libspatialite.so nowhere in the download?

Should it be in the download and in the libs directory I copied into spatialite-android?

Could this be the cause of the error I am seeing when the app is installed on the emulator?

Regards,
Jim

[Jim]

OK, all fixed, well sort of.

I have compiled spatialite-android on Eclipse and can run it on a real Nexus 7 with the only problem being that the map doesn't display, only the grid.

I believe the problem may be a missing permission or the Maps API key, both of which I will look into.

The problem I reported last night was that the Emulator is not setup to run maps and while there are some "fixes" they are not only somewhat convoluted and none are for Android 4.2.2.

If I am able to fix the Emulator problem, I will report back as I will when I get the map display issue resolved on the real machine.

I appreciate all of the help,.

Regards,
Jim


On Friday, May 10, 2013 9:56:07 PM UTC-6, Jim wrote:

[Jim]

Regardless of what I try (remember I am a novice with things Android) I can't get the example 'spatialite-android' to display the map of Italy.

I've setup an Android application key for 'Google Maps Android V2', updated the Manifest with it and other required keys, and assorted other changes.

The app compiles fine and I load it on a Nexus 7 where all functions work except the map is not displayed within the grid.  Even the 'tap' functions works by displaying the name of the place I tapped (I guess it is the place I tapped as I am just randomly tapping on the grid).

At this point I must move on to my own Spatialite application which, for now, doesn't use Google Maps.

If anyone has any ideas, please post them.

Regards,
Jim

On Friday, May 10, 2013 9:56:07 PM UTC-6, Jim wrote:

[Jim]

I fixed the emulator issue. 

Originally, I had defined the emulator for Android 4.2.2.

I changed that to Google API Version 17 and the error about the missing shared library disappeared.

The app runs just as it does on a real device including not displaying the map in the grid.

Regards,
Jim

On Friday, May 10, 2013 9:56:07 PM UTC-6, Jim wrote:

[Diren Dantanarayana]

I apologize, something has changes since I wrote the tutorial or I am
gone completely crazy.
Anyways I downloaded the link and there are complete projects in there.
So the new way to do so is:

Assuming you unzipped the folder and have the following inside it:
COPYING
COPYING.LESSER
README.txt
spatialite-android

then you have to copy in your new project (or the one online on bitbucket):

1) the complete folder (exactly as it is):
spatialite-android/spatialite-android-library/libs/
it contains all the native libs already in the right structure

2) the folder: spatialite-android/spatialite-android-library/src/jsqlite/
inside the src folder of your new project.

Then you should really be good to go. Sorry for the confusion caused,
not sure what happened.

> I must be missing something in the way Eclipse works (I am new to it) so I
> will continue trying.

I think you are just missing the java packages that link to the
aforementioned native libraries.
That would be the "jsqlite" mentioned above.

Regards,
Andrea

Hi,
i'm trying to get this app working on Android Studio(Eclipse Indigo) Android API 15.

I added the libraries as you mentioned in this post but still there is another import which i cannot figure out from which library it comes from.
Here's that line

import eu.geopaparazzi.library.util.ResourcesManager;

I am really a newbie to this spatialite and android. Can you please help me figure this out?  

Thank you!

[Damien Smith]

Thanks, Jim.  That fixed the problem for me.

All I need to do now is figure out how to get GEOS working with Android...I'm guessing it's not compiled in the spatialite-for-android-3.0.1.zip binaries package because of LGPL or something but I'm just making a small open source tool so I'm keen to have it - will save me a lot of math ;)

If anyone knows how to get GEOS working in Android, please help! 

Damien

[Brad Hards]

On Wed, 1 Jan 2014 11:04:34 PM Damien Smith wrote:
> All I need to do now is figure out how to get GEOS working with
> Android...I'm guessing it's not compiled in the

> spatialite-for-android-3.0.1.zip<http://www.gaia-gis.it/gaia-sins/spatialite
> -android/spatialite-for-android-3.0.1.zip> binaries package because of LGPL

> or something but I'm just making a small open source tool so I'm keen to
> have it - will save me a lot of math ;)

It looks like that download contains GEOS 3.2.2.

Brad

[Damien Smith]

> It looks like that download contains GEOS 3.2.2.

 

You're right - "Select geos_version()" is returning 3.2.2 on the emulator so that's fine.

I seem to be having trouble with the Line_Locate_Point function though.  It works fine in QGIS with QSpatiaLite.  This is the query that I'm running -:

Select Line_Locate_Point(geom, Transform(MakePoint(152,-28,4326),28356)) From LineStringTable Where Distance(geom, Transform(MakePoint(152,-28,4326),28356)) < 50;

If I substitute "Line_Locate_Point" with "Distance" I get the expected result on both platforms.

Are the GEOS_Advanced functions not supported on Android?

Damien

[a.fu...@lqt.it]

> Are the GEOS_Advanced functions not supported on Android?
>

Hi Damien,

this is a short summary of version-dependant GEOS-related
settings when building libspatialite:

GEOS < 3.3.0
------------
please note: these versions are nowadays completely obsolete
and always impliy: --disable-geosadvanced=yes

GEOS 3.3.x
----------
accepts: --enable-geosadvanced=yes
but always implies: --disable-geostrunk=yes

GEOS > 3.4.x
------------
accepts both: --enable-geosadvanced=yes --enable-geostrunk=yes
(e.g. suppprting the Delaunay Triangulation)

=================

you are currently using GEOS 3.2.2 on Android, and this
has the obvious consequence to forbid any possible
activation of both "geosadvanced" and "geostrunk"
simply because the underlaying GEOS-library is unable
to support any sophisticated option recently introduced.

bye Sandro

[Damien Smith]

you are currently using GEOS 3.2.2 on Android, and this
has the obvious consequence to forbid any possible
activation of both "geosadvanced" and "geostrunk"
simply because the underlaying GEOS-library is unable
to support any sophisticated option recently introduced. 

Thanks, Sandro.  That clears it up.  I'm guessing that creating nice, integrated Android libraries like the 3.0.1 package is a PITA since it's getting a bit old now.  What are my options given that -:

a)  I'm VERY keen to use these functions on Android with the Java ADK.

b)  My background is C# and a little Java.

c)  All of my previous attempts over the years to compile anything remotely related to Linux have resulted in obscure errors.

Cheers

Damien

[JaakL]

On Thursday, January 2, 2014 3:10:06 PM UTC+2, Damien Smith wrote:

you are currently using GEOS 3.2.2 on Android, and this
has the obvious consequence to forbid any possible
activation of both "geosadvanced" and "geostrunk"
simply because the underlaying GEOS-library is unable
to support any sophisticated option recently introduced. 

Thanks, Sandro.  That clears it up.  I'm guessing that creating nice, integrated Android libraries like the 3.0.1 package is a PITA since it's getting a bit old now.  What are my options given that -:

You can try our AdvancedMap3D [1] for Android which includes GEOS 3.3.8 and Spatialite 4.1.0. I really don't know if the advanced geos functions work there, so your feedback would be nice. You can use it different ways:

a) checkout whole project and use Android sample apps with Nutiteq SDK, adjust it to your needs

b) use only prebuilt binaries (libs/ folder) and jni wrappers from this project

c) checkout project, change Android.mk configuration parameters and rebuild with latest NDK. You can try to update sources also. There is a readme file which summarises how this was built.

[1] https://github.com/nutiteq/hellomap3d/tree/master/AdvancedMap3D/jni  

[JaakL]

On Friday, January 3, 2014 11:23:35 AM UTC+2, JaakL wrote:

Thanks, Sandro.  That clears it up.  I'm guessing that creating nice, integrated Android libraries like the 3.0.1 package is a PITA since it's getting a bit old now.  What are my options given that -:

You can try our AdvancedMap3D [1] for Android which includes GEOS 3.3.8 and Spatialite 4.1.0. I really don't know if the advanced geos functions work there, so your feedback would be nice. You can use it different ways:

a) checkout whole project and use Android sample apps with Nutiteq SDK, adjust it to your needs

b) use only prebuilt binaries (libs/ folder) and jni wrappers from this project

c) checkout project, change Android.mk configuration parameters and rebuild with latest NDK. You can try to update sources also. There is a readme file which summarises how this was built.

[1] https://github.com/nutiteq/hellomap3d/tree/master/AdvancedMap3D/jni  

I started updating this project to GEOS 3.4.2, now you can get prebuilt binaries from "2.3RC" branch: https://github.com/nutiteq/hellomap3d/tree/2.3RC/AdvancedMap3D/libs

GEOS advanced functions seem to work there, at least with couple of test SQLs like SingleSidedBuffer().

Jaak

 

[Damien Smith]

I started updating this project to GEOS 3.4.2, now you can get prebuilt binaries from "2.3RC" branch: https://github.com/nutiteq/hellomap3d/tree/2.3RC/AdvancedMap3D/libs

GEOS advanced functions seem to work there, at least with couple of test SQLs like SingleSidedBuffer().

Wow.  Thanks, Jaak.  I simply copied the "armeabi" binaries in place of the old ones and now the geos_advanced queries are working in my app.  Is there any reason that there's no armeabi-v7a binaries and does it make much difference?  (Please excuse my ignorance)

Damien

[JaakL]

Just to take less space. Apk will have all possible architectures, and with armeabi, armeab-v7a, x86 and mips and all the goodies (gdal/ogr,proj.4,spatialite/sqlite) you would have 50+MB APK just for library binaries. In real application you probably want to make separate APKs because of this, but just for testing lighter one is convinient. I have not found yet proof that armeabi-v7a binary will be faster, and there are devices which would not work with it (and need armeabi), so armeabi felt like universal and good enough. But I have not done benchmarking and some have claimed that armeabi is not ok on some armeabi-v7a devices (I have no proof for this either). 

So, do you have specific reason for armeabi-v7a?

Jaak

[Damien Smith]

Wow.  Thanks, Jaak.  I simply copied the "armeabi" binaries in place of the old ones and now the geos_advanced queries are working in my app.  Is there any reason that there's no armeabi-v7a binaries and does it make much difference?  (Please excuse my ignorance)

Just to take less space. Apk will have all possible architectures, and with armeabi, armeab-v7a, x86 and mips and all the goodies (gdal/ogr,proj.4,spatialite/sqlite) you would have 50+MB APK just for library binaries. In real application you probably want to make separate APKs because of this, but just for testing lighter one is convinient. I have not found yet proof that armeabi-v7a binary will be faster, and there are devices which would not work with it (and need armeabi), so armeabi felt like universal and good enough. But I have not done benchmarking and some have claimed that armeabi is not ok on some armeabi-v7a devices (I have no proof for this either). 

So, do you have specific reason for armeabi-v7a?

Hi Jaak,

Not really.  I was just curious as I'd seen a lot of other native libs with armeabi-v7a versions and I'd heard that it was faster for floating point calcs.  At the time, my GPS-based spatial query was taking 2500ms but I've managed to get it down to 70ms so performance is no longer an issue.  I've been wrestling with running the spatial queries as an Async task and dealing with screen rotation issues etc. but it's all good now.

Part of speeding up my query was to store the GPS point in a temporary table but for some reason temporary tables aren't working on Android.  I'm currently updating a DB table with every GPS update and it's fine but I'd rather use a temporary table.

Are you able to create temporary tables with Android Spatialite?

Damien 

[Pepijn Van Eeckhoudt]

On 07-01-14 07:54, JaakL wrote:
> Just to take less space. Apk will have all possible architectures, and
> with armeabi, armeab-v7a, x86 and mips and all the goodies
> (gdal/ogr,proj.4,spatialite/sqlite) you would have 50+MB APK just for
> library binaries. In real application you probably want to make
> separate APKs because of this, but just for testing lighter one is
> convinient. I have not found yet proof that armeabi-v7a binary will be
> faster, and there are devices which would not work with it (and need
> armeabi), so armeabi felt like universal and good enough. But I have
> not done benchmarking and some have claimed that armeabi is not ok on
> some armeabi-v7a devices (I have no proof for this either).
>
> So, do you have specific reason for armeabi-v7a?

armeabi only supports software floating point calculations while
armeabi-v7a uses VFP hardware instructions. For plain SQL operations
that won't make any difference, but once you touch the rtree or start
executing geometry operations the difference should be noticeable. I
haven't benchmarked this, so this is just a theoretical remark.

Pepijn