gta4xl-common: Revert "overlay: configure SQLite to operate in MEMORY mode"
This reverts commit c238f12fb771ba5fcdce7c1b87d5939ec40368d9.
That configuration introduces some level of unsafety, that is supposedly
unlikely to occur but shouldn't be there at all, for what could, in real
usage, only be really minimal gains.
Change-Id: Ied07e702bbaa231bab05e90c7125c14c7a2f4ee0
diff --git a/overlay/frameworks/base/core/res/res/values/config.xml b/overlay/frameworks/base/core/res/res/values/config.xml
index cc42dc4..e4916ac 100644
--- a/overlay/frameworks/base/core/res/res/values/config.xml
+++ b/overlay/frameworks/base/core/res/res/values/config.xml
@@ -249,34 +249,6 @@
available to the system.-->
<bool name="config_freeformWindowManagement">true</bool>
- <!-- The default journal mode to use use when Write-Ahead Logging is not active.
- Choices are: OFF, DELETE, TRUNCATE, PERSIST and MEMORY.
- PERSIST may improve performance by reducing how often journal blocks are
- reallocated (compared to truncation) resulting in better data block locality
- and less churn of the storage media.
- The PERSIST mode results in data persisting in the journal beyond the life of
- a transaction, so it interacts poorly with SECURE_DELETE. -->
- <string name="db_default_journal_mode" translatable="false">MEMORY</string>
-
- <!-- The database synchronization mode when using the default journal mode.
- FULL is safest and preserves durability at the cost of extra fsyncs.
- NORMAL also preserves durability in non-WAL modes and uses checksums to ensure
- integrity although there is a small chance that an error might go unnoticed.
- Choices are: FULL, NORMAL, OFF. -->
- <string name="db_default_sync_mode" translatable="false">OFF</string>
-
- <!-- The database synchronization mode when using Write-Ahead Logging.
- From https://www.sqlite.org/pragma.html#pragma_synchronous:
- WAL mode is safe from corruption with synchronous=NORMAL, and probably DELETE mode is safe
- too on modern filesystems. WAL mode is always consistent with synchronous=NORMAL, but WAL
- mode does lose durability. A transaction committed in WAL mode with
- synchronous=NORMAL might roll back following a power loss or system crash.
- Transactions are durable across application crashes regardless of the synchronous setting
- or journal mode. The synchronous=NORMAL setting is a good choice for most applications
- running in WAL mode.
- Choices are: FULL, NORMAL, OFF. -->
- <string name="db_wal_sync_mode" translatable="false">OFF</string>
-
<!-- Enable lockscreen rotation by default -->
<bool name="config_enableLockScreenRotation">true</bool>