Use the newly exposed WifiManager API's for backing up/restoring wifi
related data. Remove all other wifi related logic from
SettingsBackupAgent.
There are 3 API's exposed by WifiManager for backup/restore:
1. retrieveBackupData - Data to be backed up in new format.
2. restoreBackupData - Restore from the new backup data format.
3. restoreOldBackupData - Restore from the old backup data format.
BUG: 29075035
BUG: 28967335
Change-Id: I2dc379bc36af0a0824ed51fbe9aaebfd0a0114b0
(cherry picked from commit 7a2491fa3b42dd22c829eea3690239545f16f124)
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: I6939635dfc93015c4625e50b6431ceb850cfbd1a
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
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: 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
