The second argument of the JavaPixelAllocator constructor was
eliminated by an earlier change but the class definition was not
updated to match that edit.
Change-Id: I27af0cc52c748cfdec02eb4edcf512dd13f72567
Do not rely on standard word detection for these (which does not work because
of / or . in URL or - in phone numbers).
Various other bug fixes for text selection with autolinks.
Change-Id: I482e99efa980281086ce761b27b3a36579e7cf76
Refactor for canSelectText.
Moved test from onCreate to startTextSelection.
Restored setFocusableInTouchMode needed to start a selection in touch mode.
Bug 3296490
Change-Id: I5c0c31dbebed79fd1f9d80f930cba1019d74f710
- It's useful to have accessors at block level, so apps don't really have to know
about the sector structure (and how many blocks there are in a sector).
- There's no way to tell whether a read/write/ didn't work because of auth
failure. The documentation should be changed to make this point clear.
- Added increment/decrement commands, for atomic increment/decrement of value blocks.
Change-Id: I590feacbcd1443f1be7a86ab046a5b1f33e2e04c
This way the margins can disappear along with the header pane, leaving
the preference fragment pane properly aligned.
Bug: 3290342
Change-Id: I71fa132907c50e89c0b88de33ae2d695b5aa88cd
This class gives fairly low-level access to the HTTP cache, which
as far as we can tell was only exposed for the benefit of Gears.
BUG=3270236
Change-Id: Ibce10ecf8b524d3f472affa2a37fe4de15efd2ed
The problem was that NumberPicker override View.draw(), but did not
call the superclass version of the method in some situations. This
resulted in the DIRTY flag for the view not getting cleared properly,
and future invalidations not propagating correctly.
The fix was to call super.draw() from NumberPicker.draw().
Change-Id: Ic17215dea86d54b77375494ada124dd6970e3ad6
This is needed to construct a cachable CacheResult object.
Currently only WebViewWorker is able to do this, by updating
the fields directly.
Bug: 3270236
Change-Id: I50148697dcee4d329e1436a2ce4c15224cb5ae30
list UI is not ready yet
This involves some reworking of Loaders.
Loaders, in particular CursorLoader, are now expected to retain
their current data after being stopped. This allows applications
to keep that data across onStop() -> onStart(), so when the user
returns to the app it doesn't have to wait for the data to reload
and thus cause flicker.
This includes various API changes to better reflect the new
semantics, plus a new LoaderCallbacks method to tell the application
when it is actually time to stop their use of a loader's data.
Note this is somewhat half-done, to help checking in the extensive
application changes that are required without causing build breakage.
Change-Id: Ib4b3bf8185a6da46e7f06ca125521d65e2e380a1
