Home/ Questions/Q 8353981
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T09:25:20+00:00

Here’s our situation: We have some native code that scans user-defined directories at certain

  • 0

Here’s our situation:

We have some native code that scans user-defined directories at certain times. The goal is to collect data about specific types of file and build an SQLite database from it. There could be tens of thousands of files to query.

The problem is that each time a file is found, the data collected about that file must be ushered across the JNI boundary to Java-land before being comitted to the database via the SQLite classes provided by the Android SDK. This takes far too long.

The proposed solution is to download the SQLite source code, link it into our project and build the database natively as described here: SQLite with Android NDK. This would eliminate the time taken to pass the data from the C++ layer to the Java layer entirely.

The question is: if this is done, can the Android SDK (Java layer) still be used to open the database, obtain Cursor objects etc. as normal? We can keep the database extremely simple; no foreign keys, triggers, constraints etc. Although indexes are very desirable.

We have considered pipes and sockets to move the data across the JNI boundary. However, named pipes are not supported on Fat32 file systems (so this is not useable incase the user moves the application to a Fat32 formatted SD card). Sockets are also not usable because we will have to include internet permissions in the manifest which we feel would look suspicious.

If anybody has any information on this, we’d love to hear from you.

Many thanks,
P.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Just to follow up, we took the plunge and threw together a test application that compiled the latest SQLite Amalgamation (3.7.13) source code. We have found that we are indeed able to interface with the natively created database via the Android Java SDK.

    Performance wise, this was a great leap! By inserting our records at the native layer we found a massive performance increase. Previously, inserting 20,000 records into a non-complex database took approximately 4 minutes. Some simple profiling showed that pretty much the entire 4 minutes was spent passing the data from the native layer to the Java layer.

    Now, the insertions take between 4 and 6 seconds. We are also able to open, query etc. the database with the Java API as per normal.

    Performance tweaks to note are transactions and moving the journal to memory using:

    pragma journal_mode=memory;

    We decided not to turn off the synchronisation for stability reasons, plus we were more than happy with the performance we had already achieved.

    Hopefully, others will find this advice useful.

    P

    • 0