Merge commit '7c8aa44f320f45e8417f0aba9ca67af6a67a5cf7' into gingerbread-plus-aosp
* commit '7c8aa44f320f45e8417f0aba9ca67af6a67a5cf7':
Native input dispatch rewrite work in progress.
Merge commit '46b9ac0ae2162309774a7478cd9d4e578747bfc2' into gingerbread
* commit '46b9ac0ae2162309774a7478cd9d4e578747bfc2':
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
It behaves the same as ArrayList.addAll, since
the Object containing the Objects in the Adapter
is a List. Now you can add multiple Objects
at once, instead of looping over a Collection
and add all items one by one.
Unittests will be submitted to the cts project
Change-Id: I16f3286a8ca4cda7eb9f1a99c2aab1cc45b2550f
Merge commit '94f14aeca9e6c6d07b39a7f708eacadcfeb6fbd2' into gingerbread-plus-aosp
* commit '94f14aeca9e6c6d07b39a7f708eacadcfeb6fbd2':
More StrictMode work, handling violations in ActivityManagerService.
Modify OOM adj classes a bit, to take into account the new
heavy weight app type, and give "foreground services" their
own category to have a bettery chance to manager them when
things go wrong.
Also add some new code to battery stats to keep a history
of changes to the battery level.
Change-Id: I29f5ab6938777e1a7eafd7d8c38b5e564cc9f96a
Merge commit 'b8bb78f54b48868465a9d69d65fda08524ab5ae1' into gingerbread-plus-aosp
* commit 'b8bb78f54b48868465a9d69d65fda08524ab5ae1':
Change camera interface to support multiple cameras.
This is a new public API for developers to opt-in to strict rules
about what they're allowed to do on certain threads. (this is the
public face of the @hide dalvik.system.BlockGuard, added recently...)
In practice this will be used for developers to opt-in to declaring
that they don't want to be allowed to do various operations (such as
disk I/O or network operations) on their main UI threads. (these
operations are often accidental, or even when they are fast come with
a good chance of being slow or very slow in some cases....)
Implementation wise, this is just a thread-local integer that has a
bitmask of the things that aren't allowed, and more bits for saying
what the violation penalty is. The penalties, of which multiple can
be chosen, include:
* logging
* dropbox uploading for analysis/reporting
* annoying dialog
* full-on crashing
These are all only very roughly implemented at this point, but all
parts now minimally work end-to-end now, so this is a good checkpoint
commit before this gets too large.
Future CLs will polish all the above 4 penalties, including
checksumming of stacktraces and minimizing penalties for duplicate
violations.
Change-Id: Icbe61a2e950119519e7364030b10c3c28d243abe
On an inflation error, the StatusBarService cleans up, removes / doesn't add
the views, and calls into the StatusBarManagerService, which tells the
NotificationManagerService to remove the notification.
That then calls all the way back into the StatusBarService, but I think being
extra careful is okay. Throughout the status bar, it's all keyed off of the
IBinder key, so if the app comes in with a good notification while we're
cleaning up, we won't lose the new notification or anything like that.
Change-Id: Iea78a637495a8b67810c214b951d5ddb93becacb
- The problem is taht the calculation of indices does not take the
difference in original and modified text lengths into account.
- If reportExtractedText() is called from the onDraw() function,
mInputMethodState is not reset.
The error can occur when the user is editing formatted text using a full screen editor.
One example of formatted text is phone numbers (e.g. dashes are added to North American
numbers by the PhoneNumberFormattingTextWatcher class).
If the two first digits are removed from the number 555-666-777, the new number becomes 566--777.
This is due incorrect calculation of start and end indices of the changed text. The error is in
the TextView class and the problem is that the calculation does not take the difference in original
and modified text lengths into account.
Change-Id: If12d0f571873a6f1874102377432affb64ee21e8
Unfortunately, PduParser does not allow application/vnd.wap.multipart.alternative as M-RETRIEVE.CONF but some Mobile carrier send message with this type.
This patch allows that and take the first part of multipart as message body.
It fixes http://code.google.com/p/android/issues/detail?id=8957
Change-Id: Ic93259c91331d1e67100439114b7c4f43a834368
Merge commit '75b6a6b972e6b18143fd629d3d9c824c442c5f4c' into kraken
* commit '75b6a6b972e6b18143fd629d3d9c824c442c5f4c':
Fix 2737842: Disable KeguardManager API if device policy is enabled
Merge commit '75b6a6b972e6b18143fd629d3d9c824c442c5f4c' into froyo-plus-aosp
* commit '75b6a6b972e6b18143fd629d3d9c824c442c5f4c':
Fix 2737842: Disable KeguardManager API if device policy is enabled
This change adds notification to find out when the device policy
has changed. When an admin adds or changes a policy, we get notified
and reset the state of keyguard to be enabled.
It also moves disabling keyguard into the TokenWatcher.acquired()
method to avoid disabling keyguard when a policy doesn't permit it.
This avoids reference counting issues in TokenWatcher and hence relieves
the ordering issue.
There is one remaining caveat. An application that uses KeyguardManager
to disable keyguard will need to disable keyguard again after any
policy change.
Tested:
Install and run app that disables keyguard with no admin. Result: keyguard is enabled/disabled as expected.
Enable admin and set quality = "something" after installing & running app. Result: keyguard is enabled.
Change admin password quality to "unspecified" and re-run app (per caveat). Result: keyguard is disabled.
Change admin password quality to "something" again. Result: keyguard is enabled.
Disable admin : Result: keyguard is enabled until app runs again (per caveat).
Added minor cosmetic changes after review.
Change-Id: I302f2b01446bf031f746b0f3e8b5fd7a6cc0e648
Merge commit '71d73a0dfc110d0bdfc1b7ba385db3e2cfe007e5' into froyo-plus-aosp
* commit '71d73a0dfc110d0bdfc1b7ba385db3e2cfe007e5':
Add a method to hide/show a SurfaceView's surface.
Merge commit '71d73a0dfc110d0bdfc1b7ba385db3e2cfe007e5' into kraken
* commit '71d73a0dfc110d0bdfc1b7ba385db3e2cfe007e5':
Add a method to hide/show a SurfaceView's surface.
