-
|
Please fill out as much known and relevant information as possible. Version Information:
Expected Results:Add geopackage-android dependency to gradle, have it compile correctly for an ATAK plugin app. Observed Results:
Output:
Task :processDebugManifest FAILED See http://g.co/androidstudio/manifest-merger for more information about the manifest merger. Execution failed for task ':processDebugManifest'.
Steps to Reproduce:
Relevant Code:// Code to reproduce the problem?Test Files:
Additional Information:
|
Beta Was this translation helpful? Give feedback.
Answered by
bosborn
Mar 23, 2021
Replies: 12 comments 2 replies
-
|
Appcompat ( Manifest Merging should be handled by the utilizing library or application. The best option would be to migrate to AndroidX. The other option is to resolve it through the error message suggestion. This stack overflow question might be helpful. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thanks Brian.
I was able to get it to compile. Thank you for those suggestions!
I have another challenge now with the basic methods in geopackage-android.
It's a bit complicated to explain over email. But if you would be OK with a
phone conversation, much obliged.
I am working directly with a special ops homegrown application called ATAK.
I have been working with it for some time now. And I would like to discuss
how to get the methods in geopackage-android specially to work with ATAK
(challenges specifically with the creation of the manager using the ATAK
context) or go back to geopackage-java, which is what I was doing before. I
can find no version of sqlitejdbc.so that is 64-bit compatible to Android
though unfortunately, arm64-v8a.
When this is done, and I'm somehow successful, I'll write something up on
GitHub for others working with ATAK and Geopackage manipulation.
My direct email is: jason.doster@vethresearch.com
My cell is: 937-475-2032
Thx!
Jason
…On Tue, Mar 9, 2021, 2:11 PM Brian Osborn ***@***.***> wrote:
Appcompat
<https://developer.android.com/jetpack/androidx/releases/appcompat> (
androidx.appcompat:appcompat) is a required dependency for this library
<https://github.com/ngageoint/geopackage-android/blob/f84161ee80cd06131962a059f60004545eac1d6b/geopackage-sdk/build.gradle#L156>
to build and can not be removed. The SQLite Android Archive file is provided
by SQLite <https://sqlite.org/download.html> and does not have that
dependency.
Manifest Merging should be handled by the utilizing library or
application. The best option would be to migrate to AndroidX
<https://developer.android.com/jetpack/androidx/migrate>. The other
option is to resolve it through the error message suggestion.
Suggestion: add 'tools:replace="android:appComponentFactory"' to element
at AndroidManifest.xml:20:5-50:19 to override.
For example, an allowBackup value specified in the SQLite manifest is replaced
in this project
<https://github.com/ngageoint/geopackage-android/blob/f84161ee80cd06131962a059f60004545eac1d6b/geopackage-sdk/src/main/AndroidManifest.xml#L8>
.
This stack overflow question
<https://stackoverflow.com/questions/52135251/manifest-merger-fails-for-appcomponentfactory>
might be helpful.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#65 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKQB36Y7ISULTTCABFY2CLTTCZXGTANCNFSM4Y4CLAKQ>
.
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
You'll need to get a
|
Beta Was this translation helpful? Give feedback.
-
|
The context is indeed the issue. What I am developing is a plugin within
ATAK. I only have access to the context that is the plugin level context.
It doesn't have the permissions, or does not have the full Android library
accessible through that plugin context, to execute all the
geopackage-android methods. This is the specific fault I am getting
currently trying to run a simple GeoPackage database creation from a file
within an ATAK plugin:
2021-03-10 21:38:52.025 15888-15888/com.atakmap.app W/VRACameraLifecycle:
Unhandled exception trying to create overlays MapComponent
android.content.res.Resources$NotFoundException: Resource ID #0x7f040005
at
android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:202)
at android.content.res.Resources.getBoolean(Resources.java:1898)
at
mil.nga.geopackage.GeoPackageManagerImpl.<init>(GeoPackageManagerImpl.java:93)
at
mil.nga.geopackage.GeoPackageFactory.getManager(GeoPackageFactory.java:27)
at
com.atakmap.android.VRACamera.VRACameraDropDownReceiver.<init>(VRACameraDropDownReceiver.java:918)
at
com.atakmap.android.VRACamera.VRACameraMapComponent.onCreate(VRACameraMapComponent.java:359)
at
com.atakmap.android.VRACamera.plugin.VRACameraLifecycle.onCreate(VRACameraLifecycle.java:89)
at com.atak.plugins.impl.LifecycleMapComponent$2.run(SourceFile:142)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6692)
at java.lang.reflect.Method.invoke(Native Method)
at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1468)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1358)
The "MapComponent" is basically the ATAK plugin. It won't allow the
creation of the plugin overlay because the overlay context doesn't support
the GeoPackage methods, or Android methods that GeoPackage is using
inaccessible by the plugin.
Before I went down this road, I was using geopackage-java, on 32-bit
construction, and using that NGA repository and it's methods to open a
GeoPackage file and decode it. I am prevented from doing that now (I think)
because the support native library to geopackage-java (libsqlitejdbc.so)
has no 64-bit arm64-v8a version compatibility, to my knowledge, unless you
know something I don't. Xerial (https://github.com/xerial/sqlite-jdbc) is
who I have been following to get the most updated on that. He has an Arch
64-bit version, but it is not compatible with Android arm64-v8a as I have
discovered. In reality I would love to just go back to using a pure java
library to do this simple GeoPackage data extraction, but for the moment I
don't think I can with the native library that supports it.
The native library that supports geopackage-android (libsqliteX.so) by
definition should be compatible with arm64-v8a, but I can't get around this
context issue. I just wish there was a way in the geopackage-android
version to simply open a geopackage file and extract the data without going
through the formality of using GeoPackageFactory to create a manager with a
context, then creating a database with that manager, and then extracting
the data. I don't see that process as compatible with my ATAK plugin, which
is a sub to the ATAK app, and I have no ability to access the ATAK app
context. I only have the ability to access an ATAK MapComponent context
(the plugin), and that context doesn't apparently give me enough visibility
into Android methods and support libraries to allow geopackage-android to
function properly.
I have had to deal with this before with ATAK plugins. Another example is
the Camera. I can't access the Android camera2 library from within the ATAK
plugin. It is also not supported from a plugin within ATAK. In order to use
the camera from the plugin, I have to create a whole new activity outside
of ATAK using an intent call within the plugin, start the new camera
activity, take the picture, and broadcast/receive the photo (or path to the
photo) back to the ATAK plugin for use, and finally destroy that camera
activity. I really don't want to have to create a whole new activity to
execute a geopackage file opening and extraction of data, and then
broadcast that back to myself. I am trying to avoid that strongly right
now.
Any thoughts are appreciated.
Thx!
Jason
…On Wed, Mar 10, 2021 at 3:37 PM Brian Osborn ***@***.***> wrote:
You'll need to get a GeoPackageManager from the GeoPackageFactory using
an Android Context
<https://developer.android.com/reference/android/content/Context>. This
context is heavily used throughout this library. The context is usually an
activity, application context, fragment activity, etc. So hopefully your
"ATAK context" inherits from or contains an Android Context. Or potentially
you have an alternate way of retrieving the Android application-specific
context.
GeoPackageManager manager = GeoPackageFactory.getManager(context);
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#66 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKQB36ZRZOJCJ5L4YGR2PMDTC7J7TANCNFSM4Y65VUIQ>
.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
In reference to trying to install geopackage-java onto Android 64-bit (vice
geopackage-android), and trying to use aarch64 64-bit version (see attached
screenshot) of the libsqlitejdbc.so native, I get an error where I need "
libc.6.so". I have no idea what that is, but there must be some difference
between aarch64 64-bit version and arm64-v8a 64-bit version that doesn't
allow the aarch64 version to run on Android correctly. However, if I was
able to run 32-bit Android on the older phone, I could use the
"android-arm" version of the native library, and it works just fine. I
don't see anything from Xerial yet that allows 64-bit compatibility for his
native library, unless you know something I don't, and I hope you do.
Thx,
Jason
2021-03-10 22:35:27.211 23034-23034/com.atakmap.app
E/LifecycleMapComponent: error with plugin
com.atakmap.android.VRACamera.plugin (please uninstall):
com.atakmap.android.VRACamera.plugin.VRACameraLifecycle
java.lang.UnsatisfiedLinkError: dlopen failed: library "libc.so.6" not
found
at java.lang.Runtime.loadLibrary0(Runtime.java:977)
at java.lang.System.loadLibrary(System.java:1567)
at org.sqlite.core.NativeDB.<clinit>(NativeDB.java:39)
at org.sqlite.core.NativeDB.load(NativeDB.java:60)
at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:235)
at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:61)
at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:21)
at org.sqlite.JDBC.createConnection(JDBC.java:115)
at org.sqlite.JDBC.connect(JDBC.java:90)
at java.sql.DriverManager.getConnection(DriverManager.java:569)
at java.sql.DriverManager.getConnection(DriverManager.java:237)
at
mil.nga.geopackage.GeoPackageManager.connect(GeoPackageManager.java:259)
at
mil.nga.geopackage.GeoPackageManager.open(GeoPackageManager.java:164)
at
mil.nga.geopackage.GeoPackageManager.open(GeoPackageManager.java:119)
at
mil.nga.geopackage.GeoPackageManager.open(GeoPackageManager.java:105)
at
com.atakmap.android.VRACamera.VRACameraDropDownReceiver.<init>(VRACameraDropDownReceiver.java:921)
at
com.atakmap.android.VRACamera.VRACameraMapComponent.onCreate(VRACameraMapComponent.java:359)
at
com.atakmap.android.VRACamera.plugin.VRACameraLifecycle.onCreate(VRACameraLifecycle.java:89)
at com.atak.plugins.impl.LifecycleMapComponent$2.run(SourceFile:142)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6692)
at java.lang.reflect.Method.invoke(Native Method)
at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1468)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1358)
On Wed, Mar 10, 2021 at 10:02 PM Jason Doster ***@***.***>
wrote:
… The context is indeed the issue. What I am developing is a plugin within
ATAK. I only have access to the context that is the plugin level context.
It doesn't have the permissions, or does not have the full Android library
accessible through that plugin context, to execute all the
geopackage-android methods. This is the specific fault I am getting
currently trying to run a simple GeoPackage database creation from a file
within an ATAK plugin:
2021-03-10 21:38:52.025 15888-15888/com.atakmap.app W/VRACameraLifecycle:
Unhandled exception trying to create overlays MapComponent
android.content.res.Resources$NotFoundException: Resource ID
#0x7f040005
at
android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:202)
at android.content.res.Resources.getBoolean(Resources.java:1898)
at
mil.nga.geopackage.GeoPackageManagerImpl.<init>(GeoPackageManagerImpl.java:93)
at
mil.nga.geopackage.GeoPackageFactory.getManager(GeoPackageFactory.java:27)
at
com.atakmap.android.VRACamera.VRACameraDropDownReceiver.<init>(VRACameraDropDownReceiver.java:918)
at
com.atakmap.android.VRACamera.VRACameraMapComponent.onCreate(VRACameraMapComponent.java:359)
at
com.atakmap.android.VRACamera.plugin.VRACameraLifecycle.onCreate(VRACameraLifecycle.java:89)
at
com.atak.plugins.impl.LifecycleMapComponent$2.run(SourceFile:142)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6692)
at java.lang.reflect.Method.invoke(Native Method)
at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1468)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1358)
The "MapComponent" is basically the ATAK plugin. It won't allow the
creation of the plugin overlay because the overlay context doesn't support
the GeoPackage methods, or Android methods that GeoPackage is using
inaccessible by the plugin.
Before I went down this road, I was using geopackage-java, on 32-bit
construction, and using that NGA repository and it's methods to open a
GeoPackage file and decode it. I am prevented from doing that now (I think)
because the support native library to geopackage-java (libsqlitejdbc.so)
has no 64-bit arm64-v8a version compatibility, to my knowledge, unless you
know something I don't. Xerial (https://github.com/xerial/sqlite-jdbc) is
who I have been following to get the most updated on that. He has an Arch
64-bit version, but it is not compatible with Android arm64-v8a as I have
discovered. In reality I would love to just go back to using a pure java
library to do this simple GeoPackage data extraction, but for the moment I
don't think I can with the native library that supports it.
The native library that supports geopackage-android (libsqliteX.so) by
definition should be compatible with arm64-v8a, but I can't get around this
context issue. I just wish there was a way in the geopackage-android
version to simply open a geopackage file and extract the data without going
through the formality of using GeoPackageFactory to create a manager with a
context, then creating a database with that manager, and then extracting
the data. I don't see that process as compatible with my ATAK plugin, which
is a sub to the ATAK app, and I have no ability to access the ATAK app
context. I only have the ability to access an ATAK MapComponent context
(the plugin), and that context doesn't apparently give me enough visibility
into Android methods and support libraries to allow geopackage-android to
function properly.
I have had to deal with this before with ATAK plugins. Another example is
the Camera. I can't access the Android camera2 library from within the ATAK
plugin. It is also not supported from a plugin within ATAK. In order to use
the camera from the plugin, I have to create a whole new activity outside
of ATAK using an intent call within the plugin, start the new camera
activity, take the picture, and broadcast/receive the photo (or path to the
photo) back to the ATAK plugin for use, and finally destroy that camera
activity. I really don't want to have to create a whole new activity to
execute a geopackage file opening and extraction of data, and then
broadcast that back to myself. I am trying to avoid that strongly right
now.
Any thoughts are appreciated.
Thx!
Jason
On Wed, Mar 10, 2021 at 3:37 PM Brian Osborn ***@***.***>
wrote:
> You'll need to get a GeoPackageManager from the GeoPackageFactory using
> an Android Context
> <https://developer.android.com/reference/android/content/Context>. This
> context is heavily used throughout this library. The context is usually an
> activity, application context, fragment activity, etc. So hopefully your
> "ATAK context" inherits from or contains an Android Context. Or potentially
> you have an alternate way of retrieving the Android application-specific
> context.
>
> GeoPackageManager manager = GeoPackageFactory.getManager(context);
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#66 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AKQB36ZRZOJCJ5L4YGR2PMDTC7J7TANCNFSM4Y65VUIQ>
> .
>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I made some changes that should work for you (currently on
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
That's awesome Brian. I'll check out the "develop" branch and try it out,
let ya know on Monday how it went. Crossing fingers.
Thx!
Jason
…On Fri, Mar 12, 2021, 3:20 PM Brian Osborn ***@***.***> wrote:
I made some changes
<54c01f2>
that should work for you (currently on develop
<https://github.com/ngageoint/geopackage-android/tree/develop>). A
context-less GeoPackage Manager can be retrieved that will allow you to
open an external GeoPackage. All app internal metadata, databases,
GeoPackages, indexes, etc are not accessible in this mode. It will operate
more like the Java library.
- Get an external GeoPackage Manager
<https://github.com/ngageoint/geopackage-android/blob/54c01f254df6220a16200874f9bf0522731d6c05/geopackage-sdk/src/main/java/mil/nga/geopackage/GeoPackageFactory.java#L36>
GeoPackageManager manager = GeoPackageFactory.getExternalManager();
- Open an external GeoPackage
<https://github.com/ngageoint/geopackage-android/blob/54c01f254df6220a16200874f9bf0522731d6c05/geopackage-sdk/src/main/java/mil/nga/geopackage/GeoPackageManager.java#L735>
(6 methods)
GeoPackage geoPackage = manager.openExternal(location);
...
geoPackage.close();
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#66 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKQB3642LPHSJB5HBPZFEILTDJZQDANCNFSM4Y65VUIQ>
.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Brian, the update to those classes look like they will work awesome. The
methods allow me to open an external GeoPackage wtihout specificing a
context. Appears you made changes to the following:
features/index/FeatureIndexManager.java
GeoPackageFactory.java
GeoPackageManager.java
GeoPackageManagerImpl.java
I am still having issues with the android appcompat v4 that ATAK requires
for plugin compilation, versus the one that is used within the
geopackage-android, androidx. I can't use androidx with ATAK plugins. The
way I have gotten around this is to use the classes within
android-geopackage-5.0.0.aar as a library in the libs folder, while
allowing the other dependencies (except for androidx) to be called out in
the gadle. That seems to work fine. The "develop" branch you modified is
part of an sdk. All I need really are the new src/main classes in an
Android library.
Is there any way you can make an .aar from your develop branch, or lead me
to a way to do that, similar to this .aar for geopacakge-android-5.0.0.aar
in the attached picture?
Thx!
Jason
On Fri, Mar 12, 2021 at 4:54 PM Jason Doster ***@***.***>
wrote:
… That's awesome Brian. I'll check out the "develop" branch and try it out,
let ya know on Monday how it went. Crossing fingers.
Thx!
Jason
On Fri, Mar 12, 2021, 3:20 PM Brian Osborn ***@***.***>
wrote:
> I made some changes
> <54c01f2>
> that should work for you (currently on develop
> <https://github.com/ngageoint/geopackage-android/tree/develop>). A
> context-less GeoPackage Manager can be retrieved that will allow you to
> open an external GeoPackage. All app internal metadata, databases,
> GeoPackages, indexes, etc are not accessible in this mode. It will operate
> more like the Java library.
>
> - Get an external GeoPackage Manager
> <https://github.com/ngageoint/geopackage-android/blob/54c01f254df6220a16200874f9bf0522731d6c05/geopackage-sdk/src/main/java/mil/nga/geopackage/GeoPackageFactory.java#L36>
>
> GeoPackageManager manager = GeoPackageFactory.getExternalManager();
>
>
> - Open an external GeoPackage
> <https://github.com/ngageoint/geopackage-android/blob/54c01f254df6220a16200874f9bf0522731d6c05/geopackage-sdk/src/main/java/mil/nga/geopackage/GeoPackageManager.java#L735>
> (6 methods)
>
> GeoPackage geoPackage = manager.openExternal(location);
> ...
> geoPackage.close();
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#66 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AKQB3642LPHSJB5HBPZFEILTDJZQDANCNFSM4Y65VUIQ>
> .
>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Give this a shot... |
Beta Was this translation helpful? Give feedback.
-
|
Damn, I'm going to have to figure out this androidx support library. I am
sure there are a bunch of calls to that library that is just going to crush
this. See picture.
I don't suppose it's possible to set it up so one could open up a GeoPackge
file by simply instantiating it with a file path using the GeoPackage class
itself. That's similar to the way it was done with the geopackage-java
methods:
GeoPackage gpkg = GeoPackageManager.open(file);
Now I am creating a manager, and documenting that manager is calling a
method in androidx. Ugh,
GeoPackageManager manager = GeoPackageFactory.getExternalManager();
GeoPackage gpkg = manager.openExternal(file);
After I open the file, I only have to use Featurecursor and Featurerow
methods, don't know if those require androidx, need to look. Then
everything else I do just pulls information from the file. My guess is
those methods are androidx free.
// Load GeoPackage image feature information into data structure
String file_path = "/storage/emulated/0/gridlock/smartmap.gpkg";
File file = new File(file_path);
GeoPackageManager manager = GeoPackageFactory.getExternalManager();
GeoPackage gpkg = manager.openExternal(file);
Log.i(TAG, "SmartMap file path = " + file.getPath());
if (gpkg.isFeatureTable("image_features")) {
FeatureCursor resultSet =
gpkg.getFeatureDao("image_features").queryForAll();
while (resultSet.moveToNext()) {
FeatureRow featureRow = resultSet.getRow();
GeoPackageGeometryData geometryData = featureRow.getGeometry();
Geometry geometry = geometryData.getGeometry();
if (geometry instanceof mil.nga.sf.Point) {
mil.nga.sf.Point point = (mil.nga.sf.Point) geometry;
int node_id = resultSet.getInt(2);
byte[] pngBytes = resultSet.getBlob(3);
GpkgImageStructure gpkgRow = new GpkgImageStructure(point,
node_id, pngBytes);
gpkgRowList.add(gpkgRow);
Log.i(TAG, "SmartMap node_id " + gpkgRow.node_id + "
image_size = " + gpkgRow.pngBytes.length);
Log.i(TAG, "SmartMap geopoint = (Long) " +
gpkgRow.geopoint.getLongitude() + ", (Lat) "
+ gpkgRow.geopoint.getLatitude() + ", (Alt) " +
gpkgRow.geopoint.getAltitude());
}
}
Log.i(TAG, "SmartMap GeoPackage images # = " + gpkgRowList.size());
resultSet.close();
}
gpkg.close();
One last wonder. Would it be possible to compile the libsqlitejdbc.so for
arm64-v8a. I am guessing you don't have access to that source code, which
is why you make libsqliteX.so, I get it. Just thought I'd ask. If not, I
have to get this Android version working somehow. It has the only native
library that works on Android 64-bit. Thank you so much for your help. I
know I am being a pain.
Jason
…On Mon, Mar 15, 2021 at 1:16 PM Brian Osborn ***@***.***> wrote:
Give this a shot...
geopackage-android-5.1.0.zip
<https://github.com/ngageoint/geopackage-android/files/6143581/geopackage-android-5.1.0.zip>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#66 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKQB364NPJCC2ACMKTJQSTDTDZFJNANCNFSM4Y65VUIQ>
.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
OK, I have verified all the methods I need to use, except for
GeoPackageManager, do NOT invoke androidx libraries . I could simply delete
any androidx library from the dependencies if I was able to open a
GeoPackage file without going through the manager.
Perhaps in GeoPackageFactory there could be another like:
GeoPackage getExternalfile() {}
and then under the GeoPackage (although I see it's an interface, not a
methods class), or the GeoPackageImpl class, there could be a way to load
data from a file directly into the GeoPackage class structure without going
through the manager.
Thx,
Jason
On Mon, Mar 15, 2021 at 5:56 PM Jason Doster ***@***.***>
wrote:
… Damn, I'm going to have to figure out this androidx support library. I am
sure there are a bunch of calls to that library that is just going to crush
this. See picture.
I don't suppose it's possible to set it up so one could open up a
GeoPackge file by simply instantiating it with a file path using the
GeoPackage class itself. That's similar to the way it was done with the
geopackage-java methods:
GeoPackage gpkg = GeoPackageManager.open(file);
Now I am creating a manager, and documenting that manager is calling a
method in androidx. Ugh,
GeoPackageManager manager = GeoPackageFactory.getExternalManager();
GeoPackage gpkg = manager.openExternal(file);
After I open the file, I only have to use Featurecursor and Featurerow
methods, don't know if those require androidx, need to look. Then
everything else I do just pulls information from the file. My guess is
those methods are androidx free.
// Load GeoPackage image feature information into data structure
String file_path = "/storage/emulated/0/gridlock/smartmap.gpkg";
File file = new File(file_path);
GeoPackageManager manager = GeoPackageFactory.getExternalManager();
GeoPackage gpkg = manager.openExternal(file);
Log.i(TAG, "SmartMap file path = " + file.getPath());
if (gpkg.isFeatureTable("image_features")) {
FeatureCursor resultSet = gpkg.getFeatureDao("image_features").queryForAll();
while (resultSet.moveToNext()) {
FeatureRow featureRow = resultSet.getRow();
GeoPackageGeometryData geometryData = featureRow.getGeometry();
Geometry geometry = geometryData.getGeometry();
if (geometry instanceof mil.nga.sf.Point) {
mil.nga.sf.Point point = (mil.nga.sf.Point) geometry;
int node_id = resultSet.getInt(2);
byte[] pngBytes = resultSet.getBlob(3);
GpkgImageStructure gpkgRow = new GpkgImageStructure(point, node_id, pngBytes);
gpkgRowList.add(gpkgRow);
Log.i(TAG, "SmartMap node_id " + gpkgRow.node_id + " image_size = " + gpkgRow.pngBytes.length);
Log.i(TAG, "SmartMap geopoint = (Long) " + gpkgRow.geopoint.getLongitude() + ", (Lat) "
+ gpkgRow.geopoint.getLatitude() + ", (Alt) " + gpkgRow.geopoint.getAltitude());
}
}
Log.i(TAG, "SmartMap GeoPackage images # = " + gpkgRowList.size());
resultSet.close();
}
gpkg.close();
One last wonder. Would it be possible to compile the libsqlitejdbc.so for
arm64-v8a. I am guessing you don't have access to that source code, which
is why you make libsqliteX.so, I get it. Just thought I'd ask. If not, I
have to get this Android version working somehow. It has the only native
library that works on Android 64-bit. Thank you so much for your help. I
know I am being a pain.
Jason
On Mon, Mar 15, 2021 at 1:16 PM Brian Osborn ***@***.***>
wrote:
> Give this a shot...
> geopackage-android-5.1.0.zip
> <https://github.com/ngageoint/geopackage-android/files/6143581/geopackage-android-5.1.0.zip>
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#66 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AKQB364NPJCC2ACMKTJQSTDTDZFJNANCNFSM4Y65VUIQ>
> .
>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Give these changes a shot. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Dude, you rock....that worked! Compiled and working......
The Samsung 20 NetWarrior (Army thing) has ATAK 4.0 baselined, so I had to
get a build done for the version that is on that phone. HOWEVER, it looks
like the most recent version of ATAK 4.3 uses AndroidX now, so I am going
to go beyond their current fielded build, and see if I can just use your
geopackage-android repository straight up in the gradle dependencies and
not have to have such a modified one. I think all the AndroidX/support
28.0.0 conflicts will definitely be taken care of with that, but I do think
I may still have to modify some of the AndroidManifest files.
For note, under the following .aars, there are callouts in the
<application> section of the manifest that interferes with my top level
manifest, not easily gotten around I found out. Perhaps a lot of that goes
away when I go to ATAK 4.3 build gradles, I don't know. But for these
specific .aars, I had to take them out of the gradle, put them into the
local library section directly, and remove all the callouts in the
<application> section of these specific manifests to work around.
geopackage-android-5.1.0.aar
sqlite-android-3340100.aar
Attached is my current library configuration from your work to get it to
happen with your modified "geopackage-android-5.1.0.aar".
BTW, I SO appreciate you having a 64-bit compatible GeoPackage build for
Android. You rock again, and appreciate all your support.
Thx!
Jason "Nooner" Doster
…On Thu, Mar 18, 2021 at 2:22 PM Brian Osborn ***@***.***> wrote:
Give these changes
<9206603>
a shot.
geopackage-android-5.1.0.zip
<https://github.com/ngageoint/geopackage-android/files/6166700/geopackage-android-5.1.0.zip>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#66 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKQB362KOVRHGOA4444DM33TEJHF7ANCNFSM4Y65VUIQ>
.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Officially released in 5.1.0 |
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
bosborn
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Officially released in 5.1.0