* Hotspot is not assigning DHCP addresses correctly if enabled
through the profiles codepath using WifiManager.
Change-Id: I9b67748d1b51c873864cf11f9240372e367a0c53
* With the changes introduced by the commit
If04e19891e778d1203241b03f398022400a531c8,
the new integer overlay contains the device
configuration for LEDs in a bit field
* However if a device does not set this value,
the build will fail with the following error
"String types not allowed (... with value '')."
* Therefore define the overlay to the default
behaviour LIGHTS_PULSATING_LED = 8
Change-Id: I237cf2c0df856660a06bf45e8aa38a3552c8e901
Add a unified and extensible overlay that encompasses
all the current LED capabilities, while allowing for
new future LED capabilities.
Change-Id: If04e19891e778d1203241b03f398022400a531c8
* 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
* the WifiInfo object may be null if there is no active connection
which should trigger an ON_DISCONNECT
* by using the already existing "getActiveSSID"-method there is no
need to cleanup UTF-8 encoded SSIDs
Change-Id: I69e4db55753ca1e02afde59b186dae822adf7b63
* 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
After creating the theme directory it will be labeled as a
system_data_file. By calling SELinux.restorecon() the directory
will be correctly labeled as a themeservice_app_data_file
Change-Id: I73a28da883a467bf8859d879dbe22962424e4a23
TICKET: NIGHTLIES-3349
* 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
* Google changed the way TwilightService works in N, which was never
a public API to begin with. Create a local version to avoid this
problem in the future, which also contains the logic we expect
and have tested extensively.
Change-Id: I11098b14fa75664ce8efbc34888c6f97e3af5ca1
As long as the light sensor is providing values, each value change will
enqueue a transition message, which may queue up. Stop doing that and
ensure only one transition message is queued at any given time.
Change-Id: I6e9c5b265066089ff9e0cea7237c2023ed1af30c
As long as the light sensor is providing values, each value change will
enqueue a transition message, which may queue up. Stop doing that and
ensure only one transition message is queued at any given time.
Change-Id: I6e9c5b265066089ff9e0cea7237c2023ed1af30c
* The public SDK build is currently including AIDLs which are
meant to be used for internal purposes only. My assumption
is that this particular implementation was done before we
split off an "internal" SDK, which is used by the platform itself.
* The issue came up when adding an AIDL which has a backing
Java data object which was not included.
* It should be safe to simply hide this interface. All references
to it are hidden already. It is only used for internal purposes
and does not change the API.
* With the internal dependencies removed from the public SDK, we
can completely remove the reference in the makefile.
Change-Id: I0515815543feb077ee5e289b9f900e28758c6e98
* 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
