If the database needs to be created, it will not be upgraded. So, if the
device was provisioned and the table wasn't created, we don't upgrade
and so we cannot bring the old flag to the new location.
Fix this by setting the new cm provisioned flag on database creation.
Ticket: CYNGNOS-3017
Change-Id: I1e961f1cb2d06c55c1e92ef63c6dbaee17dbc304
Signed-off-by: Roman Birg <roman@cyngn.com>
Keep feature inline with 12.1, only allow owner to
control the feature and mirror across users.
Also add additional checks for moved settings.
Change-Id: Ida11b71bc5ce9463628f8c5d76e59902d47d59bb
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>
We need to store the state of _our_ setup wizard.
To not break existing devices' provisioning, copy the current state of the global
provisioned flag to the new key value.
Ticket: CYNGNOS-2431
Change-Id: I3d88361edc126788f42b28efd11f3c7598117138
Signed-off-by: Roman Birg <roman@cyngn.com>
This adds public cmsdk symbols to the bootclasspath. :(
2) testBootClassPathIsClean(org.cyanogenmod.tests.versioning.unit.ClassPathTest)
java.lang.AssertionError: Jar file /system/framework/telephony-common.jar should not have cyanogenmod.alarmclock.ClockContract$AlarmsColumns !
This reverts commit 3a590c3057.
Change-Id: I03cc2796e84e602933e7132f9181a5822c7f327c
With some mobile network operators, the presentation indicator of
outgoing calls is always set to either "unknown" or "restricted".
As consequence, the dialed number doesn't show up in clear in the
call history. Allow to ignore the presentation indicator of outgoing
calls to never hide the dialed numbers.
Change-Id: Ia7b9fef3a929e512d8ecb704204b36e3836a056b
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
If you've git blamed this commit because your build broke,
move your default tiles overlay to
`vendor/cmsdk/cm/res/res/values/config.xml`
with the entry value of config_defaultQuickSettingsTiles
TICKET: CYNGNOS-1908
Change-Id: Id721136ce669d420fde46322a339b9517b1a3677
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
Any "CALL" into the CMSettingsProvider on a new user triggers the load
default settings mechanism which may lead to attempting to load "global"
settings for non owner which is impossible.
Change-Id: Ic8535e3c211aeaccfd3d72c3f9b11eef4d9087b8
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
