*) 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
* Pass app info and number of installed packages to boot message UI
* Ui by Asher and Joey, based on Alexander's previous work
Change-Id: I9298d7e2b85a703921abf62f8b91157e6f88803b
Signed-off-by: Joey Rizzoli <joey@cyanogenmoditalia.it>
* We currently use the DisplayColorCalibration API for setting display
temperature which makes a lot of guesses about what temperature
the display really is. Some devices will support the new ColorBalance
API (via QDCM or other mechanism), which offers a calibrated
alternative. Add support for this, which will supercede DCC if
available.
* Additionally, define the available color temperature range as a
set of overlayable values so this can be specified per-device.
This range will be mapped to balance values using the power curve
calculations in the new MathUtils class.
Change-Id: I99608c09807b747d962680293c7b0cee8d669003
* Don't create the mode observer or try to publish tiles if none
of the adaptive modes are supported.
Change-Id: Iee6fe8131b0614e10f35b5a03d65fb44c71c0da9
RequestStatus holds only final constants and should not provide
public constructors. This class also should be final.
This patch also fix minor typos on RequestStatus javadoc
Change-Id: I0deb1d6a9b23eed83451dec352bb4c410e2378d6
TICKET: CYNGNOS-2441
The Weather Manager Service should not impose rules regarding how
a weather provide service wants to react to back to back weather
update requests, nor impose the time a caller should wait before
a new request can be submitted. These constraints vary between
weather services, so it's up the each implementation to enforce
these constraints.
With this patch, the Weather manager service will pass the requests
as they come from the requester and it will be up to the active service
provider decide whether process or reject the request.
Changes to API:
- Moved the request statuses to new inner class RequestStatus in
CMWeatherManager
- Pass status arg to onLookupCityRequestCompleted()
- Added reject(int) method to ServiceRequest
Change-Id: I3512490688255e25395e955d506fe42ed52f8fe0
TICKET: CYNGNOS-2430
Introduce WEATHER_TEMPERATURE_UNIT. This setting will be used to
store the temperature unit in which the weather data will be reported.
Users will be able to set this value in the weather settings menu.
Each weather service provider might choose to provide the user
with a way to overlay this value (for example via the settings
activity that each service provider can define)
Change-Id: Ib6e47c9790aba02e6c29bd7f783730efda9177f3
TICKET:CYNGNOS-2426
Instead of exposing the RequestInfo object created by the WeatherMgr
return an ID to identify the request. This ID can be later used to
cancel the request if needed. The WeatherProviderService base class
keeps track of the ongoing requests and can map this ID to the
corresponding request
This patch also include the following minor changes:
- Use List instead of ArrayList in API
- Update javadoc to public methods to reflect API changes
- Use UUID random generator in immutable classes to generate the
hashcode rather than relying solely in the hashcode of the builder
object.
Change-Id: Ib88dd0ecddd6fdb016b77ac29709fbae092dea29
TICKET: CYNGNOS-2425
TICKET: CYNGNOS-2423
