The migration happened in lineage 15.1,
we only support direct upgrades from 17.1.
This partially reverts commit e7008a222e.
Change-Id: Ic2acd93565e21475ea6f896941107230d880e890
It is only possible to upgrade from 17.1 to 20.0 directly,
let's just drop all the old migration steps.
Change-Id: I04ec638f3b7c75d53629c8fec5523a0ccc7eabb5
* We usually shouldn't touch existing migrations,
they would have already ran for most (if not all) users,
and don't run for existing users since they start at
the latest version.
* However, we've recently discovered many issues with these
migrations, and past reported issues are now starting to make
sense (they can be explained by migration running over and over again)
* As such, let's fix this once and for all to make things clearer.
* We also tend to copy older migrations when writing soemthing new so it
should help having these done :)
Change-Id: Ic45efc823da7ea8a137e79b3769a9ca53c2f8667
Add new private methods readSetting, readIntegerSetting,
readLongSetting, writeSetting, and writeSettingIfNotPresent
to reduce boilerplate and potential for code errors.
Change-Id: I9872cc50db86056cdc1588741600b66ee9d40f9f
There is no need to use database transactions to simply read settings.
We also were not setting the transaction as successful, which was
causing the outer transaction for the whole onUpgrade operation to be
rolled back, meaning that some devices would be stuck at old db
versions and perform repeated migration attempts on every boot.
Issue: calyxos#1290
Change-Id: Icefe994379152f9a3aa6c0c5b447cc55d5c4cf46
* Really shouldn't have touched an existing migration before
* Anywho, let's change it back to what it was but make it compile
* Then, let's migrate that old setting to the new AOSP setting,
but flip it since it works differently.
Change-Id: I342d8c78aa8faeda5dcaafe9199deb51c570efd0
There's no need to have our own settings for this when we can simply
override the existing AOSP ones.
Change-Id: I84e1f7286cd6b4ee68c62f17ad104c76031ee0ff
* This has been untouched since 2016 and it depends on LockClock
which has been dropped and was also untouched for years.
There is no good weather provider without API restrictions,
so just remove this dead code.
Change-Id: I6540006ce0d7339b7794b6ab207593afb161aa3d
Audio files were moved to /product on Android 10.
Moreover, align with AOSP and use the wireless sound
for wired usecase too.
In order to perform upgrade properly, handle the migration
for custom charging sound setting.
Change-Id: Ifb2085e3f56d777091d66544a72cdd75c843fb56
* Handle the migration for old settings and default
to Android's stock battery style.
* Hiding battery icon is now achieved using icon blacklist
via system tuner settings.
Change-Id: Ie41d71c774a34abe225e2c0a6a0a9fd4316189cd
* It was moved from Global to System but no migration was in place
to handle upgrades from previous versions.
Change-Id: If76243b0224dbc0138cf3c5dbc8aaeefa69f06a4
* The upgradeVersion < newVersion part is never reachable because we
increase upgradeVersion unconditionally. Make it back to stage by
nuking it as no one has experience issues before.
Change-Id: Icac1e18c192292ad3147fd4af4c862e93ef34ba5
* Since we removed onehand from settings
we need to make sure user doesn't have them
set in settings otherwise we will hit
ArrayIndexOutOfBoundsException exception.
* Fixes : BUGBASH-1525
Change-Id: I7a5737ecfe5e70c3f0108c03b3e8745eade80433
(cherry picked from commit eb8fc0648f645a265ce8d1b6daf575795eb69510)
*) This was initialized from Settings.Global.DEVICE_PROVISIONED and it is no
longer possible to access system settings during provider startup since:
235272a216
*) LINEAGE_SETUP_WIZARD_COMPLETED has been deprecated since 14.1:
797a45aa69
*) We will later cleanup the unused setting during topic:pie-db-upgrade
Change-Id: I185648ca25995fae80362642d297573795d04bfa
*) Migrate database from cmsettings.db to lineagesettings.db
*) Remove old CMSettingsProvider.xml shared_prefs.
*) Remove the code to disable the PreBootReceiver component.
PackageManager is not yet ready for component lookups when
LineageSettings is called during fw/b service startups.
However, the preboot intent is only sent when the build
fingerprint changes so disabling it doesn't really buy us
anything. We also track and check migration state in
sharedPrefs anyway.
Change-Id: I636f8315ce8a36f6d223d6a5accfe11c40ef9570
*) Support separate normal and dnd led brightness levels for battery
and notifications.
*) Move lineage-specific notification bundle extras definitions from fw/b
to LineageNotification here in the sdk.
*) In addition to the existing bundle extra EXTRA_FORCE_SHOW_LIGHTS, add
a new extra EXTRA_FORCE_LIGHT_BRIGHTNESS that can be used to override
the brightness level set by a Lineage system setting brightness level
on a per notification basis. This is used by the brightness sliders
in LineageParts that otherwise would have to juggle changing / restoring
the system led brightness setting whenever the a slider is on display.
*) Disable all lights in dnd mode when lineage setting ZEN_ALLOW_LIGHTS
is set to 0.
Change-Id: I917f402a291682b582f68c8324a33c461357dad9
* The feature was used only on Huashan since 2015
* It serves only for a small part of the users
who wanted to restrict to one light instead
of three lights from the LEDs bar
* Due to Oreo's new HIDL interfaces stack,
the additional data holder would need
a custom lights interface which is useless
for a single device and a rare use case
Change-Id: Ie08a1d625c7ce00fefff5bc1159522207be69dbc
Signed-off-by: Adrian DC <radian.dc@gmail.com>