Since ContentProvider file operations can end up doing substantial
network I/O before returning the file, allow clients to cancel their
file requests with CancellationSignal.
Ideally this would only be needed for openFile(), but ContentResolver
heavily relies on openAssetFile() and openTypedAssetFile() for common
cases.
Also improve documentation to mention reliable ParcelFileDescriptors
and encourage developers to move away from "rw" combination modes,
since they restrict provider flexibility. Mention more about places
where pipes or socket pairs could be returned.
Improve DocumentsContract documentation.
Bug: 10329944
Change-Id: I49b2825ea433eb051624c4da3b77612fe3ffc99c
Bug: 9814370
To allow WebView.capturePicture() to return a subclass, we need to
ensure the subclass is always consulted when being drawn into a canvas.
Change-Id: Ia0357f95b6fafb3ac81e6bcfaef05739e619897a
- Make sure Home activity goes in the correct task and on the correct
stack.
- Do not allow different users to be in the same task.
- Do not set stacks aside for each user.
Fixes bug 9775492.
Change-Id: I0e7954e917aac8482a1015a36923e02914e2b692
Remove some abstraction-breaking magic in ActionBarView and replace it
with proper resolution of the icon/logo when creating a window. The
old implementation relied on the ActionBarView's context being an
Activity.
Bug 9171554
Change-Id: Idbbb1942622195dcb55e8119f2d64287b07bb509
Redesigned how ViewRootImpl delivers input events to views,
the IME and to native activities to fix several issues.
The prior change to make IME input event delegation use
InputChannels failed to take into account that InputMethodManager
is a singleton attached to the main looper whereas UI may be
attached to any looper. Consequently interactions with the
InputChannel might occur on the wrong thread. Fixed this
problem by checking the current thread and posting input
events or callbacks to the correct looper when necessary.
NativeActivity has also been broken for a while because the
default event handling logic for joysticks and touch navigation
was unable to dispatch events back into the native activity.
In particular, this meant that DPad synthesis from touch navigation
would not work in any native activity. The plan is to fix
this problem by passing all events through ViewRootImpl as usual
then forwarding them to native activity as needed. This should
greatly simplify IME pre-dispatch and system key handling
and make everything more robust overall.
Fixed issues related to when input events are synthesized.
In particular, added a more robust mechanism to ensure that
synthetic events are canceled appropriately when we discover
that events are no longer being resynthesized (because the
application or IME is handling or dropping them).
The new design is structured as a pipeline with a chain of
responsibility consisting of InputStage objects. Each InputStage
is responsible for some part of handling each input event
such as dispatching to the view hierarchy or to the IME.
As a stage processes an input event, it has the option of
finishing the event, forwarding the event to the next stage
or handling the event asynchronously. Some queueing logic
takes care to ensure that events are forwarded downstream in
the correct order even if they are handled out of order
by a given stage.
Cleaned up the InputMethodManager singleton initialization logic
to make it clearer that it must be attached to the main looper.
We don't actually need to pass this looper around.
Deleted the LatencyTimer class since no one uses it and we have
better ways of measuring latency these days using systrace.
Added a hidden helper to Looper to determine whether the current
thread is the indicated Looper thread.
Note: NativeActivity's IME dispatch is broken by this patch.
This will be fixed later in another patch.
Bug: 8473020
Change-Id: Iac2a1277545195a7a0137bbbdf04514c29165c60
When a tablet rotates, FUL must be stopped and restarted in a new
position. 90 degree rotations cause a configuration change, causing
FUL to be automatically reconstructed in the new location. However,
a 180 degree rotation is not a configuration change, so FUL was not
restarting. A 180 degree rotation happens more often than one might
think. If you set the tablet down and later picked it up in the
opposite orientation, FUL would not work prior to this fix.
This change adds a rotation watcher to KeyguardFaceUnlockView. It
watches for 180 degree rotations and stops and restarts FUL
accordingly.
The rotation watcher callback must be unregistered when
KeyguardFaceUnlockView is recreated (as during 90 degree rotation
changes), otherwise the number of rotation watcher callbacks will keep
growing and they will never go away. This is a problem not just
because there are many callbacks hanging around, but also because the
old callbacks end up trying to access biometric unlock views that no
longer exist, resulting in crashes. So, a simple function was added
to the window manager to unregister a rotation watcher.
Change-Id: Ie1ef20a9a22b8f4e39918987dff2b8ad444fcfd1
Keeping all activity=>task changes in master and removing them
from jb-mr2.
Revert "Update histories simultaneously."
Revert "Add null check to setAppGroupId."
Revert "Fix crashing bug in validator."
Revert "Switch topRunning* and moveTaskTo*"
Revert "Begin switch over to task based history."
Revert "Reset and reuse Iterators and don't new() one."
Revert "Remove AppWindowToken lists."
Revert "Fix build."
Revert "Remove unused App methods."
Revert "Stop using AppToken movement and start using Task."
Revert "Replace access to mAppTokens with AppTokenIterator"
Revert "Refactor setAppOpVisibility implementation."
Revert "Add AppWindowTokens to TaskList."
Revert "Make ActivityStack.mHistory private."
Revert "Migrate AppWindowToken lists into DisplayContent."
Change-Id: I5722c9a4956dccb52864207e2967690bc58e4ebb
The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
This reverts commit 6c0307dd0aefe9a08794b155fc03ee60ebd14f25, reversing
changes made to a2cd828b749c444d55c2c41c7dbb85088ff94b9f.
Conflicts:
packages/SystemUI/res/values-sv/strings.xml
Change-Id: Ia178efe8b14751583d47b2826bfe3d3d5463dd2e
Also fix a build.
And fix a bug that I think was introduced in the multi-user work
that removed the permission check for writing to settings...!
Change-Id: I5945682faa789ffc78fd3546c0df7d03693f106d
Take advantage of this to return better information about
packages filtered by permissions -- include the permissions
they have in the requested array.
Also fix issue #8026793 (Contact picture shows default pic
while searching for a contact in qsb) by using the base
package name of the Context when reporting the app name
of an operation. Otherwise you could make a resource-only
context for another application and do calls through that
and get reported as the wrong app.
Change-Id: I5e0488bf773acea5a3d22f245641828e1a106fb8
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
