As per similar changes made in
frameworks/base/core/java/android/provider/Settings.java
Whilst not strictly necessary, also renamed
SELECT_VALUE to SELECT_VALUE_PROJECTION
as it is now named in frameworks.
Original AOSP change here:
ea93fe7539
Change-Id: Ib79bdc9a9c1f45d5f8405c7ecea30f68652f2839
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
Use the same base theme used for Settings so that our preference
tiles look like the default ones (e.g. add ripple effect).
Change-Id: I27a5569535d8d614a0c0d26dd5b9fcd12f2af1e4
AOSP recently introduced a new power hint, POWER_HINT_LAUNCH,
to indicate the start-up of an activity.
We now use that instead of using our own.
Change-Id: I3ed1ae52a67da37e87a46ca5cc5411de95f00926
Issue-Id: LINN-6
- We might get see attach() calls from multiple prefs, so stop assuming
there's only one per key. Namely, a new activity might be created and
attached before the previous one is destroyed
- The passed-in context is likely to be an activity one. As the manager
instance is static, this can cause leaks and the receiver might be
attached to a destroyed activity. Just hold onto the application
context instead, which is a singleton anyway.
Change-Id: Ica17c19ab6e1cdfd402968ce2594d3ed362e23ee
JIRA:LINN-3
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
Many new devices have available flip cover cases with some form
of view window or notification options. Currently we support a
dotcase app for HTC and a View window app is under development.
Provide a new Intent to allow a common way to launch a variety
of device specific cover apps.
Change-Id: Ic986b239b75bfc6d76142451826b3f996e242a29
* Hiding the clock is now possible using the icon blacklist.
* Since the the hide option in the clock position tunable
isn't currently implemented let's remove it
Change-Id: I2412051289a922dfc72cdf266b47f32cf7aaa31a
* Hotspot is not assigning DHCP addresses correctly if enabled
through the profiles codepath using WifiManager.
Change-Id: I9b67748d1b51c873864cf11f9240372e367a0c53
* The preferences constraints system uses reflection to look up
fields via strings, we need to ensure they are not optimized
out by Proguard. Alternatively we can manually enumerate them,
but it's yet another list of constants to maintain. We should
have used a proper enumeration to begin with, but so it goes.
* The @VisibleForTesting annotation is honored by the platform for
ensuring that Proguard doesn't stomp fields. The support library
has an @Keep annotation, but it's only supported by Gradle. If
it becomes supported by the platform in the future, switch to
it instead.
* Also add tests for all of this.
Change-Id: I9f324e003e2a9de5604085b978d5f95bdd098d32
* 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
* Allow CMParts to update the summary (or any detail) of a preference
so it can be shown correctly in the UI.
* Also some cleanup and refactoring around the parts list.
Change-Id: Idc16a7eb1a1e4170671fd068bd240b88fadfb577
* This patch will make it easy to hide preferences based on the
lack of a CMHardware feature. In the preference, specify this:
cm:requiresFeature="cmhardware:FEATURE_KEY_DISABLE"
..and the preference will magically be removed if the feature
is not supported.
Change-Id: I51699df7b39bb38b9ea69c93ade658736f89b988
* 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
* Add a Preference subclass which queries CMParts and handles all
the work needed to add a new part into Settings with a single
line of XML.
* The parts list lives in the CMParts app as res/xml/parts_catalog.xml
* We also support receiving a broadcast to update the title/summary.
Change-Id: Iaceddc85272718ba93e4086cc2577c3b016419e2
