Fix some instances of .*Locked() methods being called without
holding mNotificationLock.
Also, if this happens again, don't crash system server
Change-Id: I0a51310a6f6c8b07266092176e189e7cd08778cc
Fixes: 37444864
Test: runtest systemui-notification
- Corrected ActivityRecord.checkEnterPictureInPictureState() to return
false if the activity doesn't support Pip.
- Wait for previous activity that supports pip to pause before resuming
the next activity with FLAG_RESUME_WHILE_PAUSING so that the activity
has a chance to enter Pip before we resume the next activity. Currently
disabled until we figure-out if callers are passing in the right value
for prev.
- Changed stopActivityLocked() to call setVisible() instead of
setVisibility()...yeah this isn't confusing...
Change-Id: If2336ece4fe5b7104c9b301a4ded5cadc2c2f7cb
Bug: 37370508
Test: manual
Not sure why is complaining about the Looper.
(The toast is debug code that will be removed for ship.)
Change-Id: I5e2ecbe40687cd626b235e248fe6d12fea14204a
Fixes: 37455183
Test: runtest systemui-notification
Convert Wi-Fi Aware connectivity requests to use a custom
network specifier (as opposed to a string). Aside from
simplifying code, allows for more control of information
printed out, and of additional information to be packaged
and used in network decisions (uid - TBD).
(cherry-pick of commit a5028455a4)
Bug: 36275276
Bug: 36053921
Test: unit tests and integration (sl4a) tests passing.
Merged-In: I776fb348b15ec4830f890a8ac5c41f24594e12a7
Change-Id: I776fb348b15ec4830f890a8ac5c41f24594e12a7
Now, network logging will show one notification when it is enabled
and one after the next reboot.
Bug: 36254499
Test: CTS Verifier > Managed Provisioning > Device Owner Tests
> Network Logging UI
Change-Id: I60fc64e96ceb0ec0ae7ca832b74ac8b47e581be4
(cherry picked from commit 55dba53ed4)
When passing the characteristics of the current TextView
to the StaticLayout for auto-size measurements also take
the horizontallyScrolling into account similarly with how
the actual measurements are done (@ TextView#onMeasure).
Bug: 37254477
Test: cts-tradefed run cts-dev -m CtsWidgetTestCases -t\
android.widget.cts.TextViewTest
Change-Id: I44b85e77d9b1770f188a0f59f103e3fda284e97a
When deciding which volume stream is to be controlled by key
presses, give priority to the stream that is actually playing,
unless the user has selected a another volume to be controlled
by the key presses.
Test: play some music over headset, pause, go to home screen.
Press vol up, it changes ringer volume, immediately press play
and press vol up again, it should now change music volume
(and UI updates to indicate that).
Bug: 33355229
Change-Id: Ibad9b59a692e1c6375487b739c55fdbf07f107dd
VolumeStreamState.setAllIndexes():
- don't do anything if the target and source VSS have the same
stream type,
- javadoc of (old+new) behavior.
When STREAM_ACCESSIBILITY becomes independent of any other stream,
read the settings to restore the volumes previously set.
Test: see bug
Bug: 36286803
Change-Id: I2afcff3a93cc81f3958af252986ef1ac9c38899e
As discussed in Bug 33038203 on certain platforms there is a demand
that the power button can change the behavior depending on whether an
IME window is shown on the screen or not. The behavior requested here
can be summarized into two parts:
* Hide the IME window if it is shown [1]
* Go to the home screen if no IME window is shown
This CL implements the above request by introducing a new config mode
for config_shortPressOnPowerBehavior. Note the definition of when an
IME is shown is often tricky than people would expect. The way this
CL is implemented is to propagate IME window state from
InputMethodManagerService (IMMS) to PhoneWindowManager via
WindowManagerService regarding when the back button on the NavBar for
phones/tablets should be shown as an IME dismiss key [2].
[1]: Even with this CL the IME still is allowed to ignore the request
to hide the software keyboard. Currently there is no official
protocol to forcefully hide the software keyboard. How to deal
with such a situation is a long standing TODO task.
[2]: Internally this is controlled by the following IMMS fields:
- InputMethodManagerService#mImeWindowVis
- InputMethodManagerService#mBackDisposition
Note that those fields rely on self-report from the IME. To be
precise, the base implementation of InputMethodService is
responsible for report back its internal state to IMMS when
necessary. The important point is that, although this could
allow a malicious IME to confuse the system UI to some extent,
supporting malicious IMEs is not clearly a goal of Android.
Anyway, the definition of when an IME is shown is a kind of
hot topic in several system services recently. Hopefully we
can come up with better definition and reliable mechanism in
a future release.
Fixes: 33824860
Test: Manually verified as follows
1. Change config_shortPressOnPowerBehavior to "5"
2. Rebuilt the OS image and flash it to the device
3. Make sure that the power button works like a home button
if software keyboard is not shown.
4. Open dialer and focus in to the text field shown on top
5. Make sure that the AOSP keyboard is shown.
6. Run 'adb shell dumpsys input_method' to observe the
following line:
mImeWindowVis=Active|Visible
7. Tap the power button to make sure that the AOSP keyboard
gets dismissed.
8. Tap the power button again to make sure that it works
as if a home button.
Test: Manually tested as follows
1. Open dialer and focus in to the text field to show an IME
2. Run 'adb shell dumpsys window policy' to make sure
mDismissImeOnBackKeyPressed=true
3. Tap the back button to dismiss the IME
4. Run 'adb shell dumpsys window policy' to make sure
mDismissImeOnBackKeyPressed=false
Change-Id: I20721547c73360a70b5fc5cbe06824d577d1768a
Add version number to dexopt command. Current version is "2."
37256688
Test: m
Test: Manual OTA O (v2) -> O (v2)
Change-Id: I9fff673f3ba99833e88cf1c5c9625f42436ec150
This was causes additional churn in the system delaying the visibility
of the activity behind the one we are pipping. We now delay starting the
pip menu activity until the enter pip animation is done.
This doesn't fix the real issue where we don't wait for app transition
to be finished before starting pip, but it does make it much harder to
the user to trigger the case. Will do that in a follow-up CL.
Test: manual
Bug: 37420370
Change-Id: Ic0271d693d45c3e414b3abdf0ad24be44ff5ae5c
