当前位置：文江博客话题详情

是否可以在 apk 中获得对 sqlite 数据库的只读访问权限？

发布于 2024-11-04 17:19:02 字数 266 浏览 0 评论 0原文

可能的重复：
如何将现有数据库放入 .apk 文件中？

是否可以获得对 apk 所在的 sqlite 数据库的只读访问权限？如果可以从 apk 内以只读目的访问数据库，我不想复制数据库。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

逐鹿 2024-11-11 17:19:02

我刚刚开始进行 Android 开发，并惊讶地发现捆绑静态数据库并不容易。所以我做了唯一合理的事情：创建一个库来做到这一点。

android-staticdb 是一个 Android 库，允许对应用程序 < 中包含的 SQLite 数据库进行只读访问代码>.apk 文件。这对于需要附带大量静态数据的应用程序（例如离线维基百科阅读器）来说是理想的选择。

它的工作原理是通过本机 C 代码向 SQLite 库注册一个新的“虚拟文件系统”层，该层能够拦截 SQLite 进行的文件系统调用。因为每个 VM 进程只有一份 SQLite 库副本，所以我们实际上最终会拦截与我们相同的进程中任何应用程序发出的任何 SQLite 调用！

在正常操作中，我们的 VFS 层只是代理所有对“默认”的调用
VFS，它只使用 open() 和 read() 来访问常规数据库文件。但
当遇到与 *.apk!filename 模式匹配的特殊文件名时，
我们的 VFS 夺取了控制权。使用 zlib 和 minizip，它打开 .apk 文件并
在内部查找数据库文件；然后它会读取该文件的块
满足来自 SQLite 的任何 read() 请求。

通过这种方式，应用程序可以继续使用标准
Android 数据库 API。

用法示例：

import android.database.sqlite.SQLiteDatabase;
import kiwidrew.staticdb.StaticDatabase;

public class BlahBlah extends Activity {
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    SQLiteDatabase db = StaticDatabase.openDatabase(this, "assets/foobar.db");
    // Do normal database stuff with 'db'...
  }
}

您返回一个标准的 SQLiteDatabase 对象，唯一的限制是它不支持写入。（显然！）

请注意，除非数据库未经压缩地存储在 .apk 中，否则这将失败。使用 aapt -0 命令添加 SQLite 数据库或修改 build.xml 以传递标记到标记...

注意：

我刚刚写完这篇文章，到目前为止只做了非常基本的测试。错误报告将不胜感激。

I've just started developing for Android, and was surprised to discover that bundling a static database is not easy to do. So I did the only reasonable thing: created a library which does just that.

android-staticdb is an Android library to allow read-only access to SQLite databases contained in an application's .apk file. This is ideal for apps which need to ship with a large quantity of static data (e.g. an offline Wikipedia reader).

It works by registering a new "virtual filesystem" layer with the SQLite library from native C code, which is able to intercept the filesystem calls made by SQLite. Because there is only one copy of the SQLite library per VM process, we actually end up intercepting any SQLite calls made by any application in the same process as us!

In normal operation, our VFS layer simply proxies all calls to the "default"
VFS, which just uses open() and read() to access regular database files. But
when a special filename matching the *.apk!filename pattern is encountered,
our VFS grabs control. Using zlib and minizip, it opens the .apk file and
looks inside for the database file; it will then read chunks of this file to
satisfy any read() requests from SQLite.

By doing this in this manner, applications can continue to use the standard
Android database APIs.

Example usage:

import android.database.sqlite.SQLiteDatabase;
import kiwidrew.staticdb.StaticDatabase;

public class BlahBlah extends Activity {
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    SQLiteDatabase db = StaticDatabase.openDatabase(this, "assets/foobar.db");
    // Do normal database stuff with 'db'...
  }
}

You get back a standard SQLiteDatabase object, with the only restriction being that it doesn't support writing. (Obviously!)

Note that this will fail unless the database is stored in your .apk without compression. Add the SQLite database using the aapt -0 command or modify your build.xml to pass the <nocompress extension="db" /> flag to the <aapt> tag...