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
am: 0010741
* commit '0010741818127e6c9449fc49490f0bad14a76240':
Ensure local settings caches are not stale
Change-Id: I26c4f1f72eda3b2ebfb3ca6e086a0381d357471c
am: f71d7fe
* commit 'f71d7feef22db9e0cab2f32edc7440aedb86fdfe':
Ensure local settings caches are not stale
Change-Id: I356b9ad0b6dc1e91bfad140de1b9fc79ab6efef3
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
Replace usages where the Long is immediately unboxed or thrown
away with Long.parseLong().
In TaskRecord.java, I also fixed up similar uses of
{Boolean,Integer}.valueOf()
Tested: built frameworks/base successfully.
Bug: 28289401
(cherry picked from commit 4bd017d6a5437f153b2b0a149a5dde0b85bf6907)
Change-Id: Icfa4708946e774f4a1bacf185c3fd11a7087017e
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
