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
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
This patch adds first validation information to:
- ValidationProbeEvent, by extending the probe_type int field of to
also include a bit indicating if the probe was part of a first
validation attempt or not.
- NetworkMonitorEvent, by defining new contants for the event_type
field.
Test: $ runtest frameworks-net
+ manually generating events and inspecting the
output of $ adb shell dumpsys connmetrics list
Bug: b/32198726
Change-Id: If5687e310ddd18ed3096f8ecbdfc2ef866519234
Bug: 32573798
Mark input uint32_t[] as const. Use Read-only JNI
array access for input as it's faster than critical access.
Use non-movable arrays for TypedArray so that the address can
be resolved and stored, avoiding the need to do JNI array
access for the output.
Indicies is always non-null, so remove the optional checks.
Eliminate unused return value.
Benchmark results:
twelveKeyInflate 4963us -> 4713us
simpleViewInflate 73us -> 60us
Test: Device boots, benchmarks show faster
Change-Id: Ic3bde5aee31407d8903913f97f2218daf074499a
Bug 33177567
Monkey was causing a commit() while the activity was shutting down.
This protects from an NPE in this unlikely situation.
Test: cts-tradefed run singleCommand cts -d --skip-preconditions
--skip-connectivity-check -m CtsFragmentTestCases
Change-Id: I832cfa8fb187c61b4d2f5a8a4d0f508d7a435171
UserManager.isUserUnlocked/isUserRunning now returns state from
UMS.mUserStates that is pushed from ActivityManager.
Test: manual
Bug: 33232933
Bug: 28957340
Change-Id: Ic5f56d7d577bc336acd2bf44fab7f74feac4f7b3
Previously, they weres using libcore.io.Base64, which is @deprecated.
The two implementations' encoders produce the exact same result.
The two implementations' decoders' behavior differs for malformed
input:
- In case of error, libcore.io.Base64.decode() returns null while
java.util.Base64.getDecoder().decode() throws.
- java.util.Base64 tends to be stricter about rejecting malformed
input; specifically, it allows neither whitespace nor unexpected
'=' characters (should only occur in the padding) whereas
libcore.io.Base64.decode() leniently allows them throughout the
input.
- if the input terminates prematurely, libcore.io.Base64 tends to
return fewer bytes (stops at a four byte boundary).
The behavior differences for malformed Base64 encoded data should
not affect ShortcutPackageInfo because it should only need to deal
with XML attribute values written by itself, which are well-formed.
Note that this CL does not lead to any known changes of the encoding
step, so values written by earlier versions should not cause problems
when read by later versions of ShortcutPackageInfo.
StrictJarVerifier may now reject or behave differently for .jar /
.zip files with malformed attribute values but this seems okay since,
per its name, it is meant to be strict. For example, after this CL,
StrictJarVerifier will no longer accept algorithm + "-Digest"
attribute values with extra whitespace or padding characters as valid.
Test: Confirmed that the two implementations' encoders produce the
same result by running the following code just before this CL:
assertEquals(
libcore.io.Base64.encode(allBytes()),
Base64.getEncoder().encodeToString(allBytes()));
where allBytes() returns a byte[] with values (byte) 0 .. (byte) 255
Test: Test that phone still boots after flashing code that includes
this CL.
Test: CtsLibcoreTestCases
Bug: 31292683
Change-Id: I775d32f329f693514a8f14d87e1ef0d7a757e6c3
Follows the same marshalling scheme as other list types, such
as lists of Strings etc.
Bug: 30792387
Test: ParcelTest
Change-Id: I2003f4fcf4de5a1bee060f3c2723cfb155105b14
