A recent change to LayoutTransition caused new layout transitions to
cancel any previously-running animations. This was to handle situations
where a transition adding an item needed transitions removing items to
finish their job first (and vice versa). But canceling *all* running
animations from transitions caused some artifacts, like making the status
bar icons blink or fade in, depending on which one was started last.
The new approach is to cancel just the ones we care about: adding animations
cancel removing animations, and vice versa. Either one cancels 'changing'
animations, which prevents objects from being animated to the old end
locations, since the new transition will animate them to the correct new
end locations.
Change-Id: I68ac351b05365cace6639b6618422395c35c83fd
bug:3505060
Since we want to have some settings that are used very frequently
by many applications (long-press timeout is one example) these should
be managed efficiently to reduce lookups from different processes
because in the case of a cache miss a disk I/O is performed. Now
the system manages such core settings and propagates them to the
application processes.
Change-Id: Ie793211baf8770f2181ac8ba9d7c2609dfaa32a7
These were added in 99657 by using a misconfigured eclipse
save action that adds @Overirde to interfaces (Java 1.6 only).
Change-Id: I766bbde917b0bb063cb6d588ee276787e2f7db66
There is now an API, which is used for task switching.
Also improved how we handle rotation animation when we can't take a
screen shot, to cleanly revert to the old freeze behavior. This removes
the need to special case the emulator.
Change-Id: I7227432a2309370437ec6ac78db02c6f1e7eedd5
Bug: 3413715
Fragment was going through STARTED/RESUMED/STARTED/CREATED very quickly and
bindPreferences() was a delayed call that happened after mView was nullified.
Removing the MSG_BIND_PREFERENCES when view is destroyed.
Change-Id: Iec43102c004a266c412b993f17e1a8c1699fb0b1
Fades out the mouse pointer:
- after 15 seconds of inactivity normally
- after 3 seconds of inactivity in lights out mode
- after a non-modifier key down
- after a touch down
Extended the native Looper to support enqueuing time delayed
messages. This is used by the PointerController to control
pointer fade timing.
Change-Id: I87792fea7dbe2d9376c78cf354fe3189a484d9da
bug:3504589
WebView#removeJavascriptInterface was not performing check if
a mWebViewCore instance is present. Added such a check.
Change-Id: I7f6dfe51a08f23dddf2fc94df635fdfa68e9a7cf
Also some fine tuning of zoom scales.
1. Since overview scale will be used to determine min zoom scale, its own
computation shall be free of min zoom scale.
2. make sure mMaxZoomScale is at lease mMinZoomScale.
3. Use default scale in case of non-overview mode, since it reflects the
current zoom density.
issue: 3494868
Change-Id: I4297878b820e437b706bb7e0f143336ff1b39f82
Generates InetAddresses without risking an accidental dns lookup. For use with supposedly
numeric-only ip address strings.
Change-Id: I694f3976ce1c6382854706f6557ea88a289add3a
Bug #3458256
If an error occurs and simultaneously user cancels the recognition, here is what happens:
1. dispatchCancel() is called since the user requested cancel. It passes the first "if" successfully.
private void dispatchCancel(IRecognitionListener listener) {
if (mCurrentCallback == null) {
if (DBG) Log.d(TAG, "cancel called with no preceding startListening - ignoring");
} else if (mCurrentCallback.mListener.asBinder() != listener.asBinder()) {
Log.w(TAG, "cancel called by client who did not call startListening - ignoring");
} else { // the correct state
RecognitionService.this.onCancel(mCurrentCallback);
mCurrentCallback = null;
if (DBG) Log.d(TAG, "canceling - setting mCurrentCallback to null");
}
}
2. Error occurs in the app, which sets the mCurrentCallback to null:
public void error(int error) throws RemoteException {
mCurrentCallback = null;
mListener.onError(error);
}
3. the second "if" is reached in dispatchCancel()
4. boom
Change-Id: I54cdcc98b495d820a2caead1709d8dee968c461e
There was an issue with stale recipient tracking when BinderProxy weak
references had been purged and a new proxy object allocated for a
still-live underlying IBinder. The death recipient bookkeeping has
now been reworked so that it's fundmentally tied to the BinderProxy
instances, not maintained as global state, to prevent this sort of
confusion entirely.
Bug 3499939
Change-Id: I75c5216b6d53b90868ac969e32c9725201e51be3
Bug 3422121
Cherry-picked from master's 95472.
With ellipsize, lines starting with a very long word that does not
fit inside the width were simply ignored. Cut the long word instead.
start - widthStart index offset shift in BiDi.
The original ellipsize-end patch that added '...' after the last
word on end-ellipsized lines has been punted in favor of a true
ellipsize support in I.
I believe the StaticLayout calculateEllipsise is a no-op since textwidth <= avail
by construction: fitWidth and okwidth are < outerWidth. The only exception is the
paraEnd != here case in generate (when not a single character fits in width).
This case is exercised by StaticLayoutTest in cts (width of 8 pixels) and revealed
an offset error in widstart.
All in all, it looks like this code was probably never really tested. I tried some
typical text configuration to make sure these changes improved the situation.
Change-Id: I6c2cb26436a21f0f89078c275a89e891f0f23b92
...at android.app.DialogFragment.dismissInternal(DialogFragment.java:264)
Don't allow a DialogFragment to be dismissed twice.
Change-Id: Id2e9e3be1046b0d7862492c57c36001d8fd44a69
AIOOB exception fix in TabWidget
Bug http://code.google.com/p/android/issues/detail?id=15005
The problem was not specific to the legacy theme. The code that first
measure the tab's width with no contraint was incorrectly using the
mImposedTabsWidth array which could not have the right size if a
child was added.
The first measure after a child is added should indeed crash. Could
be investigated. This fix is sure anyway.
Change-Id: If5015aaa2d5574939fd5d6c6362ed6db94d35d4a
