Optional titles will only be displayed in the CAB if they entirely fit
instead of ellipsizing.
Fixes bug 5821883
Change-Id: I0cfd6d4fd34a4fa9f520499d577706da30606811
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
This change introduces a few new bits of data on
Notification that will help the Notification Manager and
System UI route and display them more intelligently:
-> priority: an integer in a predefined range that
indicates the app's best guess as to the relative
importance (to the user, right now) of that information
-> kind: a tag (really, set of tags) indicating the general
type of notification (realtime, asynchronous, etc)
-> extras: a Bundle of additional key/value pairs
associated with this notification (currently @hidden)
The notification manager takes these data into account when
assigning to each notification a score which is passed with
the notification on to the system UI, where it can be used to
affect presentation. For example:
- Spammy apps (identified explicitly by the user or by
some other means) will have their notifications scored
very negatively by the notification manager, allowing
the UI to suppress them
- Notifications of higher score might be shown larger
or in a different way
- Very important notifications (indicated by a very high
score) might interrupt the user during an otherwise
important task (videochat, game, etc)
Implementation note: This replaces/extends the old internal
notion of "priority", which was mostly used to organize
ongoings and system notifications at the top of the panel.
Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
Remove the right-to-left cascade effect from action mode menu
items. Animation time is now fixed at 300ms for scaling in menu items.
Change-Id: I8eef2ed9f93c2af804663dd5e6b3f4915ed45cb1
Changed the size of the temporary buffer used when storing a PDU part
to 8192 bytes instead of the previous 256 bytes. This greatly
decreases the time needed to store relatively large PDU parts. The
times to store PDU parts were so long that we frequently ended up with
an ANR. This change resulted in a total time usage of ~1000 ms instead
of ~10000 ms for ~500 kB worth of data.
Change-Id: Ia02cb28e4fd9dfe3aaa1fa30ff37659951cbed93
This change makes it much easier to make sense of the messages that
get posted to the ViewRootImpl's handler by encapsulating their point
of dispatch within the ViewRootImpl itself.
As part of this change, the View.AttachInfo now carries a reference
to the ViewRootImpl itself, which simplifies some code that used
to try to find the ViewRootImpl by getting the root view's parent.
In principle, it might have been nice to hide the ViewRootImpl from
the View hierarchy but in practice the two were coupled in many ways.
Change-Id: I51ebccdf5f8c8c505cd6f17cdf594174d041dc54
Bug 5032682
Part A of several parts to speed up sending MMS's. In this change, don't
allow multiple threads to write out the same pdu at the same time. This
was causing problems between the thread sending the mms message and the
UI trying to refresh and display the in-progress-sending message.
Change-Id: I862081619e6b6808caaba86a3b48820e0ef75aba
This fixes a regression caused by making the lock screen window slippery where
dragging the target over the system bar would incorrectly cause it to
snap to an invisible target. It now interprets MotionEvent.ACTION_CANCEL
the same as an "up" event and resets to the initial state.
Change-Id: I9a3c195371d64e1a4613f6f1fb0a043e9a47a601
This attempts to fix an issue where sometimes the time shown on lock
screen was really old. The code now sets the time immediately when the
screen turns on.
Change-Id: Ic4649ea342499aea82f997ba488bc2cb45987739
This fixes a bug where the device would show pattern unlock after the user
entered the SIM PUK unlock code. The code now correctly determines that
the device isn't secure and thus shouldn't show the unlock screen.
Change-Id: I49fd749592154a4c5840038b92d54ca7ca086074
Split existing network stats into two separate classes: a recorder
which generates historical data based on periodic counter snapshots,
and a collection of historical data with persistance logic.
Recorder keeps a pending history in memory until outstanding data
crosses a specific threshold. Persisting is handled through a given
FileRotator. This pattern significantly reduces disk churn and
memory overhead. Separate UID data from UID tag data, enabling a
shorter rotation cycle. Migrate existing stats into new structure.
Remove "xt" stats until iptables hooks are ready. Avoid consuming
Entry values when recording into NetworkStatsHistory. Assign
operation counts to default route interface.
Introduce "Rewriter" interface in FileRotator with methods to enable
rewriteAll(). Introduce IndentingPrintWriter to handle indenting in
dump() methods.
Bug: 5386531
Change-Id: Ibe086230a17999a197206ca62d45f266225fdff1
The VM is allowed to use null to represent the bootstrap class
loader, so attempting to call methods on it is a bad idea. Use
the system class loader instead.
Change-Id: I9190848945f679d546d5fb30aba10fd27c7e5404
Plug a couple of apparent code paths (one not obviously reachable, but
fixed here on general principles) that could lead to a backup pass
getting confused partway through and simply never properly completing.
In this state it would leave its wakelock held forever until next
reboot. Bug 5828859.
Those fixes are a total of two lines of code. The rest of the patch
adds a textual journal of the most recently completed (or ongoing!)
backup pass's progress, with an eye to being able to isolate any such
issues that may crop up in the future.
Change-Id: If8a5e8aba11db5a1e618d8b9c9ba3038dd5377a1
This is a fix for http://code.google.com/p/android/issues/detail?id=17508
Adding some logs and a forced GC, I'm now reliably able to reproduce it. Here is the scenario.
1. The IME handles an event. It retrieves the current InputConnection (IC) using
ic = getCurrentInputConnection() and calls ic.beginBatchEdit();
2. The call is propagated to the UI thread and TextView's mBatchEditNesting
is correctly increased through beginBatchEdit()
3. A listener calls setText(), which imm.restartInput(this);
4. As a result, the InputMethodManager creates a new ControlledInputConnectionWrapper
with a new InputConnection from the TextView
5. A GC happens at that point. The previous InputConnection is no longeri
referenced by the InputMethodManager's mServedInputConnection.
The weak reference in the previous ControlledInputConnectionWrapper is nulled.
6. The IME thread finishes its process and calls ic.endBatchEdit(); on its version
of the original InputConnection.
7. The message is passed through the InputConnect, but when the weak reference in the
original IInputConnectionWrapper is dereferenced, we get a null InputConnection in
executeMessage().
8. As a result, the TextView's endBatchEdit() method is not called, leaving this TextView
with a non zero mBatchEditNesting.
9. From now on, all edit actions on this TextView will be considered part of a nested edition
and no invalidation is performed, which is the visible manifestation of this bug.
The core problem is that the begin/end batch edit contract is broken when:
1. These are initiated by the IME thread (as opposed to the UI thread)
2. The input connection is reset between these calls
3. A GC happens in the mean time and the WeakReference is lost (otherwise
calling endBatchEdit on a no longer active InputConnection is fine
Solution to keep TextView's mBatchEditNesting balanced:
- The IMM should notify the IC when it is no longer used. We're using the
existing FINISH_INPUT_CONNECTION to do that.
- The InputConnection should keep track of its nesting contribution to the TextView.
When finished the IC makes sure its contribution is reset to 0.
Moreover, further asynchonous calls to begin/endBatchEdit that may arrive from the IME
should be ignored. This is achieved using a negative value as a flag.
Notes:
- finishComposingText may be too broad of a method to perform such a cleaning step
but is seems to only be called in cases where the IC will not be used anymore.
If that's too broad, we have to introduce a new method in the IC interface.
- This is has been implemented in EditableInputConnection and not in a more general
BaseInputConnection because this is where we have a notion of TextEdit, and the
nesting problem is here specific to TextView.
However, the same unbalanced begin/end problem will happen in these classes. They
should override finishComposingText as has been done here if that matters.
- We cannot re-use the TextView's mBatchEditNesting since it may take into account
batch edit from various sources and resetting it on InputConnection close could
then lead to an inconsistent negative count value.
Patch Set 2: added synchronized blocks around mBatchEditNesting
Change-Id: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
Utility that rotates files over time, similar to logrotate. There is
a single "active" file, which is periodically rotated into historical
files, and eventually deleted entirely. Files are stored under a
specific directory with a well-known prefix.
Bug: 5386531
Change-Id: I29f821a881247e50ce0f6f73b20bbd020db39e43
Fix 5783857: Device Policy Manager doesn't allow Face Unlock
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
