When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
(cherry-picked from commit 58f27b5033)
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
Defining a new system API that will allow the system to request
network recommendations from a NetworkScoreService implementation.
Test: Coming in a future CL.
BUG: 32909424
Merged-In: I2d5c0a843b928b04e87c1862a78702a02fd54c31
Change-Id: Idd33095c6cd2f5b391796c900399f18a2c40fcc3
If the constuctor throws, then the handles would be closed without
setting "closed" to true. As a result, the finalizer would close
the handles again, which would cause a crash on the native side.
Test: Unit tests are no longer flaky.
Bug: 33301253
Change-Id: I527ba38d5d65ce844258d894441d4fe16bac6e23
This flag enables the NetworkScoreService.requestRecommendations API,
defined in b/32909424.
Bug: 32913919
Bug: 32909424
Test: runtest --path
frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
Change-Id: If592e4a2ec574929aa0c829c39ad4ce9b0317805
Instead of relying on the window animation system, in the special
case of a swipe-dismiss, disable any default window exit animation
and perform a custom animation. This bypasses some bugs in the
window animator codebase and allows us to have a nice "rebound"
animation if the user doesn't swipe far/fast enough to trigger a
dismiss.
Bug: 33041168
Change-Id: Ied45700d35a59950bacef1ba0650eaa5bc60fadb
Only the device owner will be able to set the restriction
and the restriction will prevent usage of Bluetooth on the
entire device - i.e. in all the users.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.UserRestrictionsTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Bug: 32895300
Merged-In: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Change-Id: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Only the device owner will be able to set the restriction
and the restriction will prevent usage of Bluetooth on the
entire device - i.e. in all the users.
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.UserRestrictionsTest
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest#testBluetoothRestriction
Bug: 32895300
Merged-In: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
Change-Id: I2875cf178cb16eca1965d0ba965d1cd3d8db2ad5
* changes:
BLE OOB Pairing - parse address type (5/5)
Fix Bluetooth OOB pairing not working for unseen devices
Add LE Secure Connection data parsing (1/4)
