Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
Since older versions of the platform will crash if the mode is
set to 3, this CL adds an extra bit and uses 4 as the mode. This
will also cleanly default the mode to AUTO on unsupported
platforms.
BUG: 11031947
Change-Id: I48035abbf35523d65cead6f27be10f8087973ceb
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
Instead of keeping a single global system decor rect around
in WindowManagerService, calculate and store policy-defined
system-decor frame for each window.
The per-window decor rect is useful for smooth transitions, since it
determines window cropping during transition animations.
Bug:10938001
Change-Id: Ice6652aa5946027c45c0b7ab4e46473a0f8e3f90
When an inset computer is registered with the view tree observer,
we report content insets to the window manager. When an inset computer
is subsequently unregistered, we must take care to clear these insets.
This patch remembers whether the previously computed insets were
non-empty so that it can force insets to be reset when needed.
Bug: 10840662
Change-Id: I4cce5ba64cc5234b98363b025ac4bb42e64349f1
Since binder call permissions are not transitive by design,
the proper way to fix this is to have the call talk directly
to keyguard from the navigation bar.
Fixes bug 9409008
Change-Id: Ibd90a79bb638c969b514455a2ad93c6ff668222d
When in the SyntheticKeyHandler, a missing constructor paramater caused the
wrong contstructor to be called. This would cause the device id, scan code and
flags to be incorrect.
Bug: 10966229
Change-Id: Ib84ef88d28c0da517b376c5493a851cf8fe0a9f7
Bug #10911502
Views creating hardware resources need a way to safely interact
with the hardware. This new method invokes HardwareRenderer.safelyRun()
which executes a Runnable after making sure the hardawre rendering
context is in a valid state.
With the OpenGL backend, executeHardwareAction() tries to call
eglMakeCurrent() if needed. This method is not guaranteed to
work.
Change-Id: I38ec65132eeba85605cffb1a6de12b7a0184e213
The original bug is fixed already, but showed up some problems in
the underlying fade-transition implementation. This fix addresses
those and other issues. The biggest part of the change should help
transition robustness in general, as it removes the dependency on the
public 'alpha' property of views and uses, instead, a new hidden property
on views called 'transitionAlpha'. This is a value which is normally
opaque (1), but which can be used by transitions (only) to animate the
translucency of views without disturbing the actual 'alpha' value which
might be manipulated outside of transitions. This should make transitions
much more robust in general.
In implementing and testing this overall fix, I noticed a couple of things
about transitions that were simply wrong (such as starting fades from the
wrong start value, and incorrectly avoiding transitions on some views
that didn't happen to have ids), and those are fixed in this CL as well.
Issue #10726905 ActionBar weirdness in People app
Issue #10727937 Menu items in gallery appear in faded color after selecting an image/album by long press
Change-Id: If1618446db10c1bfcff4761449241de4f559afc1
The leak fix of the CopyOnWriteArray in ViewTreeObserver was
too aggressive, always clearing the shadow copy when it should only
have cleared it when needed. The way it works now, we will always
clear the listeners for ViewTreeObserver after the listeners
are processed.
Issue #10815924 ViewTreeObserver leak fix too aggressive
Change-Id: Iff0095d73beb38e52b0a5ae6b6378afec4458fd3
Transitions were leaking views due to TransitionsValues holding references
to views/parents. The references were fine, but the retention of the transition
objects themselves were not. There were a few different places that needed to
be plugged:
- clones were not making new copies of some fields, leading to caching references
in the original object (which was then cloned later to other clones)
- Visibility was using a persistent field to cache temporary values. This transition,
when cloned, would retain these instances, keeping references to views
- ViewTreeObserver had a bug that would leak listeners
Issue #10749071 Activity instance leak between TransitionManager and InputMethodManager
Change-Id: I1d5d457dc5e020c7b9e8392a95e3b2c488461119
A recent change to ViewPropertyAnimator.withLayer() builds the layer
immediately after creating it. This works in general, but if the view
is not attached, buildLayer() throws an exception.
The fix is to ensure that the view is attached before calling buildLayer().
Issue #10750925 Dialer crashed and phone dropped while on call
Change-Id: I801c835a0f5cb81e159fe90c157c122cf2d0da01
Alters the content change API to contain a bit mask of types of
changes represented by the event. Live regions send CONTENT_CHANGED
events immediately. Removes unused APIs for EXPANDABLE/EXPANDED.
BUG: 10527284
Change-Id: I21523e85e47df23706976dc0a8bf615f83072c04
1. Removed unneeded code in Resolution that was storing its
label as resource and package name. We do not have predefined
resolutions, therefore we always persist the label.
2. Renamed the print attribute margins to minMargins to reflect
that these are the minimal margins the printer support. Updated
the docs as well.
3. Renamed the create method of all builder to build.
bug:10727487
Change-Id: Ie72ab8aaa5215b8bd2853885011b3b4efa4deb2e
If the IME is repeatedly changing the text in its
onUpdateSelection handler, this will crash it with a
stack overflow exception. It's better than the old behavior,
which would result in a busyloop likely to make the
device completely unresponsive.
Bug: 10301239
Change-Id: I170cfb8ef20fc056d4725931890a987aefcaea8b
Previously, withLayer() would simply set the layer type in the runnable
called in onAnimationStart(). Now we also call buildLayer(), to get it
out of the way prior to the view drawing for the first time after the
animation begins.
Issue #9422420 ViewPropertyAnimator.withLayer() should build layer immediately
Change-Id: I99923a234f7ca1ec0b6f1b0bf28b62a71ab7eb4d
Make it a little easier to diagnose input dispatch timeouts by
providing the detailed reason as the ANR annotation in the log.
Bug: 10689184
Change-Id: Ie18fd9ad066b0673d1f57c030e027ad0085f4650
- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException
Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
The code that creates a clone of an AccessibilityNodeInfo was not cloning
the extension objects (CollectionInfo, CollectionItemInfo, and RangeInfo)
and as a result if the original accessibility node info is recycled the
extension objects of the clone are also recycled and now if one tries to
recycle the clone gets an exception that the extension objects are already
recycled. Fun!
bug:10642952
Change-Id: I84192466bff0e865de04b79079e6ceecdffb37a6
New method setUpdateListener() on ViewPropertyAnimator that will
send out update events to the provided listener.
Issue #10118113 Offer update listener on ViewPropertyAnimator
Change-Id: Ib9f8fc6dbbc3c1c58113246d9a3b01e7ac27b14c
Logic in pivotXY setters noops when the new value equals
the previous value. However, the initial value is "0" even
though we actually use a value of the view's midpoint by
default. If an app sets a new value of 0, we don't send it
down to the native layer because it's the same as the initial
value, even though we're actually using a midpoint value instead.
This causes a conflict between the matrix used for invalidations
(which use the actual values the app set) and the matrix used
for rendering (which uses the default midpoint values).
The fix is to make sure we send down the initial value, even when it
equals the default value, by checking to see whether this is the
first time we're setting the pivot.
Issue #9337635 Clipping and bad rendering of view corners when y pivot is set
Change-Id: I4aa20c4a3c9a866ca17df3e067232b832d0ef504
