Changes:
- Added getter for global style and current accent
- Added getter for a list of (available) trusted overlays
- Apps that want to change the global style now MUST specify their
package name when calling setGlobalStyle().
LineageParts will expose the name of the app that's currently managing
the global style
- Improved documentation
Change-Id: Iaa1b106f43684b4120aa0f39023ebfddcb379806
Signed-off-by: Joey <joey@lineageos.org>
This API will allow apps to change global style mode and accent.
Global style mode can be
* Automatic (wallpaper)
* Automatic (day of time)
* Light
* Dark
Accent colors are defined in the caller application that will have
to pass the package name.
It's possible for apps to pass a Bitmap and get a suggestion
of a global style + accent color that can be applied.
Restrictions:
* Only one accent can be enabled at time.
* We're not limiting this to system apps, but we're marking
this as dangerous permissions so apps will have to require
it at runtime to the user.
Change-Id: I921e8758c3ae093a88e897899612830258c97f8d
Signed-off-by: Joey <joey@lineageos.org>
LiveDisplayManager.getMode() returns MODE_AUTO when night mode is enabled
automatically, so there's no way to determine if night is on when livedisplay
changes automatically
Change-Id: Ia47fc127232c2bb3b6634b55712060a919f8c9c1
Signed-off-by: Joey <joey@lineageos.org>
*) 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
*) Add support for integer requiresConfig resources (previously supported
only strings and bools). Preference is removed if the int is 0.
*) Add a new attribute requiresConfigMask that takes a string decimal int.
If requiresConfig is an integer then the pref is removed if
(requiresConfig resource value & requiresConfigMask value) == 0.
If requiresConfig is not an integer type then requiresConfigMask
is ignored.
*) Code clean-up for the rest of checking requiresConfig.
Change-Id: Ic2622809c02a94d9cecf6f59ed6e689fdb835458
* 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>
This was in frameworks/base on lineage 14.1 and
earlier (https://review.lineageos.org/#/c/65797/).
Update api/lineage_current.txt to match the new location.
Change-Id: Ib852ab1bc04936828ef00e24f71783e6a41de33c
This is used to decide whether a user wants
to long-press the power button while the display
is off to activate the torchlight.
Change-Id: I3bfaa4bf5a5452b9af2c412596c6713a151e0ec8
* Factoring out the work done for CMParts into an actual API that can
be used for all of the various device settings apps.
Change-Id: Ie1b47c900c2b37457b90f1b0af0634d5fe12fd9a
* Add a bunch of helpers for dealing with settings URIs in
a transparent way.
* This also includes the "Observatory" which is an aggregator
of ContentObservers. Inspired by TunerService.
Change-Id: Ie30c3f712d3c6536af559d93f7debe2dcc5ead06
* Add support for negation- prefix with !
* Add requiresAction constraint, which checks if an application is
available to resolve the given action
* Fix issues with operations order
* Add flag to remove a preference if it's intent can't be resolved
* Add helper to allow setting minLines of a preference, since it's
common for things to get weird with the kinds of behavior we
are introducing everywhere
* Add support for nuking *other* preferences. For example with
Doze, many devices have custom features and a extra_settings
panel which is redundant with the switch. Now we can trivially
override the one we don't want.
Change-Id: Ibb14b05add56b403013e908db1105dce9d34faad
* Added a proper API for this thing
* Pass objects around with necessary metadata, pre-filtered and sorted
* Added event log and service dump
* Simplified locking and adjusted for performance / correctness
* Clarified/beautified code where possible
* TODO:
- Write profile descriptions
- Finish the UI
- Clean up javadocs
- Do something with per-app profiles, maybe
Change-Id: Ie2ef84031e81a18e95dcd62392c7e6939860d933
* Set "cm:requiresOwner=true" to enforce that the current user
is an owner, otherwise the preference will be removed.
Change-Id: I20d1348f58a855d07676882db773f73687396a6d
* Add a new set of attributes which can be declared in the
preference XML which will cause the preference to be
removed from the hierarchy if the constraint is not met.
Currently we can check for installed packages, system
properties, config references, and system features.
* CMPartsPreference is also updated to use similar logic
based on the external XML.
Change-Id: If8fb39cd3312623e38bb3498bfb3f29ed8b444d6
* These lived in the Settings app previously, but are now moved as
we need them in a few places.
* The support library required to use these helpers, but we
intentionally reference it using LOCAL_JAVA_LIBRARIES so the
application will need to declare a dependency.
Change-Id: I56844def5e1100ca0300d0027312cc9adcaab941
* Dexopt is no longer a thing on N.
Revert "You are now a developer!"
This reverts commit 2059ea6908.
Revert "[1/2] cmsdk: cm custom boot dexopt UI"
This reverts commit 6e5ab27fbb.
Change-Id: Ie50e8e6a77172d2b5b0659be831e7dd7a19fee04
