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
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
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: 1db5c20960
* commit '1db5c20960c2b56f7864adece4ecc17465252e5f':
Use the correct handler when persisting the settings state.
Change-Id: Ie2b13db04cb574d3dbe293801b23a0bb497447d2
am: 23d729deb8
* commit '23d729deb8d78d5806dec60453174ccfa28b843d':
Use the correct handler when persisting the settings state.
Change-Id: I1e6002fd970f9eda095a6c1c17f09937cee67aaf
am: 967fcfa593
* commit '967fcfa5939403017a6edc6d365b2996b915685d':
Use the correct handler when persisting the settings state.
Change-Id: I6939635dfc93015c4625e50b6431ceb850cfbd1a
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
