This patch fixes multiple static analyzer warnings:
frameworks/base/media/mca/filterfw/jni/jni_gl_environment.cpp:66:10:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_native_frame.cpp:38:10:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_native_program.cpp:31:10:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_shader_program.cpp:50:12:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_shader_program.cpp:57:12:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_vertex_frame.cpp:27:10:
warning: Potential memory leak
Note that the changes in jni_gl_frame are purely cosmetic; those aren't
fixing any warnings. I'm happy to back them out if anyone wants.
Bug: None.
Test: All of the static analyzer warnings mentioned above are now gone.
Change-Id: I49dc6d7c789233d6497f8bcc766ca66aec72b27b
Update the title layouts of AlertDialog and Preference for
nonround watches with proper padding.
Bug: 31271003
Change-Id: I9305c1f52297ee6658de2e84295509d5f06f8aaf
Cleanup:
- Make sure all the state is nicely dumped.
- Remove some unused stuff.
- Fix a flicker when occluded -> unlocked
Bug: 32057734
Change-Id: Id87e26adccef740d608b325c2dc1f6db14dd4ec3
Also save surface for the home task, so unlocking to the homescreen
is as fast as before. Note that originally it was not possible to
save surface for home task because of artifacts when clicking the
home button. However, we added logic since then to disallow save
surface if it's a different intent, which is the case when pressing
the home button.
Also consolidate some relayout for less overhead.
Bug: 32057734
Change-Id: I53ede527cb1ff438001d4023ee3740283ee302ee
Nuke KeyguardScrim
Test: Kill SystemUI while lockscreen is showing, make sure nothing
is visible when being killed.
Bug: 32057734
Change-Id: I9f8d1e5a0e0f968460d8170627a849623c6a7245
Notify activity manager when dreaming showing state changed so
KeyguardController can update the occluded state when the device
is dreaming.
Test: Set dreaming while charging, wait until screen times out,
make sure that dream is occluding Keyguard.
Bug: 32057734
Change-Id: Ied6f485d9b4a1526cb4cd5f0701f86b1ea05830a
Currently there is no way to get the profiles supported by the Bluetooth
adapter. Asking for a profile proxy of an unsupported profile does not
fail and can lead to code indefinitely waiting for the proxy response. This
new code will allow for checking the supported profiles before asking for
the proxies.
Bug: 26451648
Change-Id: I4b48e7151f5ca53851aa3b967c143fae140ecd34
(cherry picked from commit b1301fa284)
Introduce UnknownVisibilityController, which keeps track of apps that
may or may not be visible when launching an activity behind Keyguard.
When Keyguard is occluded and we launch another activity, we don't
know whether we still have to keep Keyguard occluded until the app
has gone through the resume path and issued a relayout call to update
the Keyguard flags.
This class keeps track of that state and defers the app transition
until the unknown visibility of all apps is resolved.
Test:
1) Have an occluding activity that starts another occluding
activity, ensure that there is no flicker.
2) Have an occluding activity while the Keyguard is insecure, start
a DISMISS_KEYGUARD activity, ensure there is no flicker.
3) runtest frameworks-services -c com.android.server.wm.UnknownVisibilityControllerTest
Bug: 32057734
Change-Id: I5145b272722ab8c31dd7c5383286f5c9473e26a4
Test: Manual, ensure that the accessibility focus is still visible on
a moved window (enable talkback, focus a view, then move the
window).
Change-Id: Ifd67afe355cac2f1df01ddd16f960282f4d36132
The heart of this change are two things:
1) Instead of using the force hide mechanism to hide windows behind
Keyguard, we actually make the activities invisible in activity manager.
2) When Keyguard is going away, we change the visibilities in activity
manager and run an app transition.
At the very core we move the responsibility of hiding activities to
ActivityStack, which checks whether Keyguard is showing, and then
hides all non-show-when-locked activities. For that, we need to check
whether any window of an activity has SHOW_WHEN_LOCKED set. We
introduce a callback from WM -> AM in case these Keyguard flags have
changed.
Furthermore, we decide whether to occlude Keyguard in KeyguardController,
which just checks whether the top activity has SHOW_WHEN_LOCKED set. When
this state changes, we prepare an occlude/unocclude app transition, and
in PWM we just inform the Keyguard about the animation so SysUI can play
along this animations in a mostly synchronized manner.
Since we now use an app transition when unlocking the phone, we get
lockscreen launch animations for free - window manager automatically
waits until the activity is drawn, or directly executes the transition
if there is nothing to animate. Thus, we can remove all the infrastructure
around "waitingForActivityDrawn".
The logic to show/hide non-app windows is moved to policy, and we add the
ability to run animations on non-app windows when executing an app
transition.
Test:
1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests
2) Manually test unlocking Keyguard:
2a) Without security
2b) With security
2c) With security but trusted
2d) Portrait while activity behind is in landscape
3) Test launching things from Keyguard
3a) Without security
3b) With security
3c) Launch camera without security
3d) Launch camera with security
3e) Launch camera with securtiy and trusted
3f) Launch voice affordance
4) Set no notifications on lockscreen, drag down, make sure you get
the correct animation
5) Test clicking "emergency" on bouncer
5b) Test "Emergency info" on emergency dialer
5c) Test clicking edit button on emergency info, should show pattern on
Keyguard
Bug: 32057734
Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
- Apps cannot update their channel settings after creation.
- Importance is required when creating a channel.
- Some method name changes.
- Ranker can't modify fields a user has changed.
- High and Max importance mean the same thing.
- The default channel adopts app wide settings on creation.
- The default channel is limited to importance low once target api is post n mr1
unless the user changed it.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/notification
Change-Id: I73c449a6abe6d709046de79c5c54339cb2edf0b8
parseClusterPackage/parseMonolithicPackageLite now share a single instance
of AssetManager, avoiding loading resources twice.
Test: manual
Bug: 29273545
Bug: 30792387
Change-Id: I2209cf6f09886d444dc62993aace00c356718cdb
When a FastScroller is enabled, we were invalidating the
list data during layout, which left the UI in a bad state.
Long-presses didn't work properly, and TalkBack touches
were impossible to perform.
Bug: 31160338
Test: Manually tested long pressing, and verified
that TalkBack now works with the TestActivity in ag/1567328.
Change-Id: Iecd2d597259748a3ecbf5573950e565a0e9faa42
