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
This adds a feature to delay locking the device when the power button
is pressed. This fixes a use case where the user wants to turn off
the display (e.g. to save power) but doesn't want to lock the device.
For the case of a secure device (user has a pin/password/pattern),
this will lock the device immediately or not based on the setting.
For the non-secure case, this always "locks" the device to provide easy
access to the camera while preventing unwanted input.
Change-Id: Ie328485c3f7559e26896d761cbf0e69d3f4df4e2
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
Bug 5729514
Hand merge a patch from Samsung to fix:
"From Avea server the subject and length in MMS coming like as "...96 00...".
It means subject header present but subject length is zero.
As per accepted principles of MMS headers, if the header length is zero it should not be sent.
Android framework code does not handle this siutation and parsing fails always."
Change-Id: I930aa1e97f5e2e6eb69a94b7380c114272330232
Reduce likelihood of crash when state machine has quit and someone
sends a message using one of the public functions.
Bug: 5724844
Change-Id: I6582a1d19113e6ed545c8ab20adb0a414d8784a7
