Fixes a regression from Froyo. Previously, when a scroll view
had no children, its onTouchEvent would return because the scroll
view would only start dragging if the user touched one of its children.
In Gingerbread, the user can drag from anywhere within the scroll
view, not just by touching a child. However, it makes no sense
to drag a scroll view that has no children so an empty scroll view
should just ignore touches like any other empty view group would.
This change fixes applications that for some reason or other happen
to have empty scroll views in strange places.
Bug: 3246230
Change-Id: Iada6e886e8363e6778f42fc4861de228512d8bed
* commit 'e6a97e27bcc1b8320fbe09d7827aec8050ebef01':
Fix race condition between GC thread and the teardown of RS. The RS context was going away while the objects were being deleted within the finializer.
the teardown of RS. The RS context was going away while
the objects were being deleted within the finializer.
Add more debugging for playCoreCommands.
Change-Id: I391f0b4db948f43f54017b47b062ab47d6a1ef64
Don't dismiss by default when tapping outside, even for AlertDialog.
If AlertDialog doesn't have any buttons, tapping outside will dismiss it.
Applications can make their own dialogs (or activities looking like
dialogs) can use the existing and new APIs to control this behavior
themselves so that it does the right thing.
Change-Id: I02bfb9161e169de0033200211b3a7ec80080bd83
We no longer enforce permissions for applications that are accessing
their own components. This allows an application to require a permission
on one of its components that it does not itself have. This is useful
for example with the new advanced widgets, which require a system-only
permission on the implementing service to ensure the app's data stays
private but it is nice to allow the application to still touch its own
widget service.
Change-Id: I5d61930a083816919545870039ad191314ed48c6
This adds hint text to visit google.com/account/recovery if
the user forgets their google password.
Change-Id: I4c4c250b9e4116d2769b7760fdc291fa756c3db0
Generally we never want to lock a buffer for write access if it is at
the "head" on the surfaceflinger side. The only exception (1) is when
the buffer is not currently in use AND there is at least one queued
buffer -- in which case, SurfaceFlinger will never use said buffer
anymore, because on the next composition around, it will be able to
retire the first queued buffer.
The logic above relies on SurfaceFlinger always retiring
and locking a buffer before composition -- unfortunately this
didn't happen during a screenshot.
This could leave us in a situation where a buffer is locked by the
application for write, and used by SurfaceFlinger for texturing,
causing a hang.
Here, we fix this issue by never assuming the exception (1), it was
intended as an optimization allowing ANativeWindow::lockBuffer() to
return sooner and was justified when most of SF composition was
done in software. The actual buffer locking is now ensured by
gralloc. We could have handled screenshots in a similar way to
a regular composition, but it could have caused glitches on screen,
essentially, taking a screenshot could cause to skip a frame.
Change-Id: I1f226b1ebdf6918439b687c2723955d55b842c55
