am skip reason: Change-Id I1d23910cbd282f6702785c9dfb059d7be6b0e895 with SHA-1 6a56247200 is in history
Change-Id: Ia661b6d4d41f53088160da1fb2970da538173f02
Block TYPE_PRESENTATION windows on default display
... and any other display that isn't considered a public presentation
display, as per Display.isPublicPresentation()
Bug: 141745510
Test: cts-tradefed run cts -m CtsActivityManagerDeviceTestCases -t android.server.am.PresentationTest
Change-Id: I2aaab1903dee54190338f7b6e49888aa51437108
Block TYPE_PRESENTATION windows on default display
... and any other display that isn't considered a public presentation
display, as per Display.isPublicPresentation()
Bug: 141745510
Test: cts-tradefed run cts -m CtsWindowManagerDeviceTestCases -t android.server.wm.PresentationTest
Change-Id: I2aaab1903dee54190338f7b6e49888aa51437108
am skip reason: Change-Id I50ee768e792266ad2091f1913168e89d5d1463ed with SHA-1 adc39de3a1 is in history
Change-Id: Id8dbe594ef4015254755fd61373bf3c226987811
Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.
Also forbid attaching null application thread to avoid unexpected state
in process record.
Bug: 144285917
Test: atest ActivityStackTests#testNavigateUpTo
Test: atest CtsSecurityTestCases:ActivityManagerTest# \
testActivityManager_attachNullApplication
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.
Also forbid attaching null application thread to avoid unexpected state
in process record.
Bug: 144285917
Test: atest ActivityStackTests#testNavigateUpTo
Test: atest CtsSecurityTestCases:ActivityManagerTest# \
testActivityManager_attachNullApplication
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
Check dalvik.vm.dex2oat-cpu-set in AndroidRuntime and pass to ART
with "--cpu-set=" as a compiler option, if found.
Check dalvik.vm.image-dex2oat-cpu-set in AndroidRuntime and pass
to ART with "--cpu-set=" as an image compiler option, if found.
Bug: 141446571
Bug: 149395059
Test: manual
Change-Id: Ica6a39048292d3d43aeb58d25f79f1398a7d5a79
Merged-In: Ica6a39048292d3d43aeb58d25f79f1398a7d5a79
(cherry picked from commit 870ce3f6d7)
To help find the root cause of high authentication failure rate in enterprise network, add EAP method and authentication phase2 method in connection event metrics.
Bug: 150237135
Test: manual
Test: atest com.android.server.wifi
Merged-In: I7f3268b2842783f99c0a43d8b4996d0a7dd46c6e
Change-Id: Id4ac7947871785d16b81c0806986f54d64fdb0ce
ConfigurationChangedReceiver is removed. Classes that want to be
notified of configuration changes should implement
ConfigurationController.ConfigurationListener instead and register
themselves with the ConfigurationController.
This CPs http://ag/9762349
Change-Id: I00c08a30b6d8dcac7e26230cb4354bc1fda74b10
Merged-In: Id2c3fe5ae2729b181769fb31b8050da264299d72
Bug: 150541820
Test: atest SystemUITests
Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.
Also forbid attaching null application thread to avoid unexpected state
in process record.
Bug: 144285917
Test: atest ActivityStackTests#testNavigateUpTo
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
Do not call AudioSystem.setAllowedCapturePolicy directly in
AudioManager. Instead, send the request to AudioService and calling the
function in AudioService. In that case, AudioService can cached the
request so that it benefits returning correct playback configuration.
When querying capture policy, AudioManager will query AudioService first
to see if there is cached capture policy. If there is exception, return
cached capture policy in AudioManager.
Test: dumpsys audio, query active audio playback configuration
Test: atest AudioManagerTest, AudioAttributesTest
Test: atest AudioPlaybackCaptureTest, AudioPlaybackConfigurationTest
Bug: 145115448
Change-Id: I170571d8a67839bc5a53991d6c89127b99b5c794
Merged-In: I170571d8a67839bc5a53991d6c89127b99b5c794
(cherry picked from commit b33f36971d)
Originally, if the caller of navigateUpTo is alive, even the calling
uid is set to the caller who launched the existing destination activity,
the uid from caller process has higher priority to replace the given
calling uid. So this change doesn't modify the existing behavior if
the caller process is valid. Besides, the case of delivering new intent
uses the source record as calling identity too, so the case of starting
new activity should be consistent.
Also forbid attaching null application thread to avoid unexpected state
in process record.
Bug: 144285917
Test: bit FrameworksServicesTests:com.android.server.am.ActivityStackTests
Change-Id: I60732f430256d37cb926d08d093581f051c4afed
* changes:
DO NOT MERGE: Revert Move startInput for WINDOW_FOCUS_GAIN to background thread
DO NOT MERGE: Revert: Freeup lock when IME is set inactive and unbound
Reason for revert:
Caused an unexpected regression Bug 144174015
Bug: 139806621
Bug: 144103599
Fix: 144174015
Test: Manually verified Bug 144174015 disappeared as follows
1. Open Gmail then start composing an email
2. Swipe up the home button to recents then re-launch Gmail
3. Do the step 2 several times.
4. Make sure that you can still type something on Gmail.
Change-Id: I9265f01ed2f6e4aca7728d278f06ceea5633dac5
Reason for revert:
Caused an unexpected regression Bug 144174015
Bug: 139806621
Bug: 144103599
Fix: 144174015
Test: Manually verified Bug 144174015 disappeared as follows
1. Open Gmail then start composing an email
2. Swipe up the home button to recents then re-launch Gmail
3. Do the step 2 several times.
4. Make sure that you can still type something on Gmail.
Change-Id: I04a77afea17f9d3eb05017fa00313fad4e48cd5c
