71f3099c536867751fab696ad5def326ed23fa0a |
|
19-Jun-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added back removed ctor from DisplayEventReceiver ...because some app can't help but access hidden APIs... Test: builds Change-Id: Ia1d4a71b46a53b44e3ebe5844e446009785a90ac Fixes: 62719884
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
34a0cdb98eb5561774ea4e7b3b602aad80c4a3cc |
|
09-Jun-2017 |
Jorim Jaggi <jjaggi@google.com> |
Properly run window animations at vsync-sf (1/2) - Add new Choreographer instance that runs on vsync-sf - Use this new Choreographer for WindowAnimator, and remove all the hacks around it Test: Open apps and close apps, notice no stutter Test: Screen zoom animations Test: go/wm-smoke Bug: 36631902 Change-Id: I988ae25645effc3ac20efa7cb9b68f23444da0d0
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
67e2ae86396c6d0f989285275cbf908dee5e71f7 |
|
12-Oct-2016 |
Aurimas Liutikas <aurimas@google.com> |
Fix import statement in view|transition|animation packages. This change also remove trailing whitespace. Test: code still compiles Change-Id: I7eff4546320d67d2bae58d31bad0625ea0791b8f
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
e46af37e3e41ea8bdd3eacffb8c32b3bc6f9d254 |
|
04-Oct-2016 |
John Reck <jreck@google.com> |
DisplayEventReceiver -> @FastNative Test: make && boot Change-Id: Id75648a2398a13c5af24eabc217bdef778618872
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
3b4049e79b1ea2872891cc0e87146e146111d502 |
|
18-Apr-2015 |
Jeff Brown <jeffbrown@google.com> |
Fix leaks due to GC circular references. The DisplayEventReceiver and SensorManager event queue both get leaked when the Looper thread they are attached to dies because the Java object holds a strong reference to its native peer and meanwhile the native peer holds a strong reference to the Java object through JNI. Fixed the issue by indirecting through a weak reference as was done for InputEventReceiver some time ago. Bug: 12455729 Change-Id: I3d80a2a190192d1a2981bf5ae0cad30f0f7688a5
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
27285821b74ca9bc381d33f40028f06ff0f85e0c |
|
18-Dec-2013 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Use long for pointers in DisplayEventReceiver For storing pointers, long is used as native pointers can be 64-bit. In addition, some minor changes have been done to conform with standard JNI practice (e.g. use of jint instead of int in JNI function prototypes) Change-Id: I3c0855373c0e4bedc172adb82b103586de9219dc Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
3866f0d581ceaa165710feeee9f37fe1b0d7067d |
|
12-Feb-2013 |
Mathias Agopian <mathias@google.com> |
split Surface in two classes: SurfaceControl and Surface SurfaceControl is the window manager side; it can control the attributes of a surface but cannot push buffers to it. Surface on the other hand is the application (producer) side and is used to push buffers to the surface. Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
e87bf030766198bf5e1fe846167dba766e27fb3f |
|
21-Sep-2012 |
Jeff Brown <jeffbrown@google.com> |
Support HDMI hotplug. Bug: 7206678 Change-Id: Ia5212b16658a5f5a2ccf8528eca7bebd45ca857a
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
3e7e7f025e8d7dc6ab8c361118c8e949bdf3e451 |
|
27-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix improper use of CloseGuard. Change-Id: I37131a86e27a4be55956384a3566de9dcfd90fe5
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
58aedbc9bea13415e2d42cf7c9fe8a7efd243e66 |
|
14-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix possible races in vsync infrastructure. Applications sometimes crashed on exit due to the display event receiver pipe apparently being closed while still a member of the Looper's epoll fd set. This patch fixes a few different possible races related to the display event receiver lifecycle. 1. The receiver used to play a little dance with the Looper, registering and unregistering its callback after each vsync request. This code was a holdover from a time before the surface flinger supported one-shot vsync requests, so we can get rid of it and make things a lot simpler. 2. When the Choreographer is being accessed from outside the UI thread, it needs to take great care that it does not touch the display event receiver. Bad things could happen if the receiver is handling a vsync event on the Looper and the receiver is disposed concurrently. 3. It was possible for the Choreographer to attempt to dispose the receiver while handling a vsync message. Now we defer disposing the receiver for a little while, which is also nice because we may be able to avoid disposing the receiver altogether if we find that we need it again a little while later. Bug: 5974105 Change-Id: I77a158f51b0b689af34d07aee4245b969e6260d6
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|
0a0a1248cfc03940174cbd9af677bafd7280a3bc |
|
02-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Add a new class to receive vsync events. Change-Id: I4e384336d2813752a6d65fda6a77e86113a4510c
/frameworks/base/core/java/android/view/DisplayEventReceiver.java
|