We don't need it because we don't support using the returned cursor
directly, and it can cause deadlocks when being called from platform
code.
Change-Id: I2f85be1152569ba27e4622d310d867e20965faa3
During an upgrade, we try to migrate values which are
considered to be LEGACY settings to the new provider, however
because of a bad upgrade path, we need to check if the key exists in the
new database AND the old database, and then we can skip it in that case.
Ticket: CYNGNOS-2740
Change-Id: I5d6bc8399ccc328f4190ed7508c27bd9d5de1b9d
Signed-off-by: Roman Birg <roman@cyngn.com>
If an application is writing to SECURE or GLOBAL they should only
be required to hold the WRITE_SECURE_SETTINGS permission and not
both.
Change-Id: Ife14b5e19340f04e2e3b7ebba121104253d1dc88
Since the migration is invoked even on a clean flash, with
no means of knowing what scenario we're coming from. Assume
that all null values are to be dropped and default values are
to be given precedence.
Change-Id: I10eb2f4650c379422268423dbc011b49f77ed910
TICKET: CYNGNOS-1721
The database is innaccessible during creation through
the android resolver interfaces, thus, no defaults were
loaded even though the code would execute.
So rewrite the DatabaseHelper to create a singular bulk transaction
per table when default settings are to be loaded, and provide
verification tests for the CMSettingsProvider.
TICKET: CYNGNOS-1706
Change-Id: I3d8c5f25704ec9620fe57b82865531fb976a516f
Move validators from CMSettings.System into CMSettings,
add validators for CMSettings.Secure, and move protected apps validator
from CMSettings.System to CMSettings.Secure
Change-Id: I9f4e1bef7ff5be100376d2d03d34483d12938158
The previous migration step should've never happened,
change the default shared pref to a different location to
force trigger a migration on devices where the previous iteration
of settings migration already happened.
Change-Id: I6b466d37910c31dbf58d37fd631807d7dd2dbae3
Danny Baumann