Note DPM.wipeData() on a secondary user is now blocking, just like
it's been always blocking on the primary user.
Bug 30681079
Change-Id: Ia832bed0f22396998d6307ab46e262dae9463838
It sometimes needs to launch OEM-supplied apps for processing, so make sure
it continues to do so.
Bug 34587823
Test: verified dispatch via logcat/dumpsys
Change-Id: Ic80e06582116cdd629492ed01a9b05b0e1b3822e
Specifically, tab focus should travel completely through all
views within a given viewgroup before traveling to a sibling
viewgroup. At each hierarchy level, viewgroups are sorted
according to the existing rectangle-based algorithm.
This is only the first of a couple focus-order tweaks to
adhere to the new keyboard navigation ux spec.
Bug: 33848452
Bug: 34084573
Test: Checked in a sample-app that focus order adheres much
more closely to our keyboard navigation spec. Also
verified that existing FocusFinder CTS tests still pass.
Change-Id: Ia0e59a2e0dd8b9773796e0aaebfca0deb3c14a3c
Create 2 jank tests and 1 macrobench that measure saveLayer
performance:
- Fling a ListView, which has a vertical fading edge.
- Draw a canvas with 20 saveLayer/restore interleaved with other
drawText and drawRect ops.
Test: built and ran UiBench jank and macrobench tests.
Change-Id: I5a50feb7431d597c92c7a49031505d41f397d175
Gaining access to a Handler's Looper can be problematic in custom
Handler implementations. Instead of creating a new internal Handler
to dispatch the method calls on we simply post Runnables to the
given Handler.
Test: adb shell am instrument -e class android.net.NetworkRecommendationProviderTest -w com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 34845471
Change-Id: I6fe380a92aebd630781abe5853f94737bcfeaa5f
This is a boolean field indicating if the given WiFi network is provided
by a Passpont home provider. This is useful for the Passpoint provisioning
app to determine if the current WiFi connection is allowed to perform
Passpoint subscription or policy updates when it needs to.
This field will be set by PasspointNetworkEvaluator when generating
a WifiConfiguration for a Passpoint network.
Bug: 34467212
Test: make update-api; make -j32
Change-Id: Ia8ec2508de9658a9ee520087359ff2cd68091b63
Merged-In: I47310cda078cbf1f2d1b0a9bf79f487230fb668f
match the Optional Steps fliters in setup wizard.
Also added some more logging.
Bug: 34460278
Test: cd tests/; mma
Change-Id: Id576a1a19daa473e203cef41d67f6ef0cfc06dbe
To make backward compatible, kills application when render process
is killed by system.
Bug: 30824898
Test: No test, this is document revision.
Change-Id: I12862ee9ed1986ec274fe627782542e8d8414856
Previously, the JNI upcall would contain only the current codec config.
In the new API, the upcall contains:
1. The current codec config
2. The list of codecs containing the local codecs capabilities
3. The list of codecs containing the selectable codecs capabilities.
This list is the intersection of the local codecs capabilities
and the capabilities of the paired device.
Also, refactored the Java internals to accomodate the extra information:
* Added new class BluetoothCodecStatus that contains the extra info:
current codec config, local codecs capabilities and selectable
codecs capabilities
* Renamed method getCodecConfig() to getCodecStatus() and return the
corresponding BluetoothCodecStatus object.
* Updates to class BluetoothCodecConfig:
new methods isValid(), getCodecName(), and updated toString()
so it is more user friendly
* Removed BluetoothCodecConfig.EXTRA_CODEC_CONFIG and
EXTRA_PREVIOUS_CODEC_CONFIG.
The former is superseded by BluetoothCodecStatus.EXTRA_CODEC_STATUS;
the latter is not really used.
Test: A2DP streaming with headsets and switching the codecs
Change-Id: Ia1af2c22e521e863e28a360610aca49f7e62d31b
Also mark with @SmallTest in the hope that this will enable the test to run!
Test: run FrameworksCoreTests
Change-Id: If332dca6c1393a77208b21d20f98760cb126085b
Messaging notifications now get an increased boost in size,
since those are usually important to the user.
Test: existing tests pass
Bug: 34469375
Change-Id: Idfc2d2403b04c4c2d17b821e3ccbbbd48d31654d
If activity was in process of becoming invisible and it needed to be
finished, we weren't actually finishing it if we tried to do it while
in STOPPING state. This lead to activity being removed from stopping
list and stuck in FINISHING state.
Bug: 34195099
Test: android.server.cts.ActivityManagerActivityVisibilityTests
Test: #testFinishActivityWithMoveTaskToBackAfterPause
Test: #testFinishActivityWithMoveTaskToBackAfterStop
Change-Id: Ic892f998b7fda7d5ede9a84b1ab837dbef40af21
