If the device being upgraded happens to have a timeout of
500ms it will be reset to 400. If the value is something
else it will be left alone upon upgrade.
Bug: 30159825
Change-Id: Ifec70e458ce0199b61d36f7504aea02b4a974990
- Removed Secure.ACCESSIBILITY_DISPLAY_COLOR_MATRIX, it's not desirable
to persist the actual color transformation matrix.
- Refactored all SurfaceFlinger transforms to DisplayTransformManager,
which allows color transforms to be set independently from the a11y
manager service.
Bug: 30042357
Change-Id: Iefa477dedb66aac90e1218e327802a3fab6899ed
Currently we used global setting to restrict user from enabling oem
unlock. As global settings can be chagned using adb, using user
restrictions instead.
Bug: 29893399
Change-Id: Ic83112a4838b8279bf50408a29ae205e0b8639ee
We send a handle to the generation tracker along with the first accessed
setting but don't send the generation id of when the setting was
actually looked up. So by the time the client gets the setting with the
generation tracker from which to get and cache the last generation the
setting may have changed. We need to pass the generation id along with
the value and the generation tracker.
bug:29458487
Change-Id: I0ac4955ba5b10b547f8fe653a7c28e048a4691eb
When merging backed-up configurations with the current supplicant
configuration, we read both configurations into a instance of
WifiNetworkSettings. No EAP configurations should be restored as
per b/25725016, however existing EAP configurations that already
reside in wpa_supplicant.conf (presumably configured in SUW)
should not be removed in the process.
This CL adds a parameter to the "readNetworks" method to allow it
to select whether or not EAP configurations should be read in. It
is used to allow the "restoreWifiSupplicant" method to copy in EAP
configurations from the existing wpa_supplicant.conf, but not out
of the backup data.
BUG: 28873992
Change-Id: I8b3e0c1a6629b3f1ca5055b1b2190e6b3ca4c033
am: 967fcfa593
* commit '967fcfa5939403017a6edc6d365b2996b915685d':
Use the correct handler when persisting the settings state.
Change-Id: I53fea39e5097512f080f62f3510cc6c7acf87e3c
Settings is using a MemoryIntArray to communicate the settings table
version enabling apps to have up-to-date local caches. However, ashmem
allows an arbitrary process with a handle to the fd (even in read only
mode) to unpin the memory which can then be garbage collected. Here we
make this mechanism fault tolerant against bad apps unpinning the ashmem
region. First, we no longer unpin the ashmem on the client side and if
the ashmem region is purged and cannot be pinned we recreate it and
hook up again with the local app caches. The change also adds a test
that clients can only read while owner can read/write.
bug:28764789
Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: I8e0cf7ffa32e86e36e777964eb0c3cc7de02d3c3
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: Icf38e72403b190a8fa9d0554b8dd83ce78da3bc8
+ By default, OEM unlocking setting is enabled.
+ Add a check to prevent oem unlock being flipped if the setting isn't
enabled.
Bug: 28163088
Change-Id: I087d8d5a1d99a611a8f66ff71a92ec9ea1da4e9f
We now have a null object instead of null values and
there was a place where we returned null instead of
the correct null object.
bug:28423485
Change-Id: I2626768acdf8d19fc94aa5e978eb057818450fa5
With I5a40675dd226564c0ee190d0d6f7eb2a7e4673b0, isNull() is used for
null check but accidentally the condition is flipped.
Bug:28406262
Change-Id: I776a6c259765210a7b334a81876233b594fd25ed
We no longer have a null settings value - instead it is a
null object. This change adds a missing null check that is
not changed to check against the null object.
bug:28406262
Change-Id: I5a40675dd226564c0ee190d0d6f7eb2a7e4673b0
A recent change replaced the null state during a setting
lookup with a null object, however missed to update some
null checks to be null object ones.
bug:28405145
Change-Id: I80f0fb3ac6e64f4283b6c617283a009e97a40efe
We used the system proterties as a shared memory mechanism
to propagate information to local settings caches when the
content has changed and the cache should be cleared. The
system properties are unfortunately updated asynchronously
leading to cases where clients may read stale data.
This change adds a simple int array data structure backed
by shared memory which guarantees individual values are
atomically read and updated without memory tear. Multi-
index opearations are not synchronized between each other.
The settings provider is using the new data structure to
propagate the settings generation which drives when caches
are purged.
We have a single memory array keeping the generation for
different settings tables per user. Since memory array is
not a compact data structure and the user space exceeds
the memory array size we use an in-memory map from keys
to indices in the memory array where the generation id of
a key is stored. A key is derived by the setting type in
the 4 most significant bits and the user id in the 28 least
significant bits.
The mapping from a key to an index is cleared if the user is
removed and the corresponding index in the memory arry is
reset to make it available for other users. The size of the
memory array is derived from the max user count that can be
created at the same time.
bug:18826179
Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
Copy the primary values of LOCK_SCREEN_SHOW_NOTIFICATIONS and
LOCK_SCREEN_ALLOW_PRIVATE_NOTIFICATIONS into managed profile upon upgrade.
Bug:27673591
Change-Id: I3207b7e5bf844f0df534324220082edbdabe8444
Previously many usages of UserManager.getProfiles and getEnabledProfiles
were only using ids of returned users. Given that the list of users needs
to be parceled and unparceled for Binder calls, returning array of ids
minimizes memory usage and serialization time.
A new method getProfileIds was introduced which returns an array of userIds.
Existing method calls were updated where appropriate.
Bug: 27705805
Change-Id: Ic5d5decd77567ba0f749e48837a2c6fa10e812c0
- While explicitly bound, the package for a single pre-installed
VrListenerService will be granted permission to access
notification policy, be bound as a notification listener service,
and draw system overlays.
Bug: 22855417
Change-Id: I568d5d9c032e0926e47c8ef4b46e3910b6bdf766
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
It's easy for apps to throw custom Parcelables into Bundles, but
if the system tries peeking inside one of these Bundles, it triggers
a BadParcelableException. If that Bundle was passed away from the
Binder thread that delivered it into the system, we end up with a
nasty runtime restart.
This change mitigates this trouble by "defusing" any Bundles parsed by
the system server. That is, if it encounters BadParcelableException
while unpacking a Bundle, it logs and delivers an empty Bundle as
the result.
Simultaneously, to help catch the system process sticking its
fingers into Bundles that are destined for other processes, a Bundle
now tracks if it's "defusable." For example, any Intents delivered
through ActivityThread are marked as being defusable, since they've
arrived at their final destination. Any other Bundles are considered
to be "in transit" and we log if the system tries unparceling them.
Merges several Parcel boolean fields into a flags int. Add better
docs to several classes.
Bug: 27581063
Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
