Combine the code for opening readable and writable databases.
This improves the handling of the case where a database cannot
be opened because it cannot be upgraded. Previously we would
open the database twice: first read-write, then read-only, each
time failing due to the version check. Now only open it once.
Removed the goofy locking logic related to upgrading a read-only
database to read-write. We now do it in place by reopening the
necessary connections in the connection pool.
Change-Id: I6deca3fb90e43f4ccb944d4715307fd6fc3e1383
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: I3709c831fc1883d7cb753cd2d3ee8e10a61e7e48
Refactor SMS Cell Broadcast support to enable receiving CMAS warning
notifications over CDMA. The CellBroadcastReceiver app must also be
updated with the corresponding change. All cell broadcasts are now
delivered as a Parcelable SmsCbMessage object in the "message" extra
of the SMS_CB_RECEIVED_ACTION or SMS_EMERGENCY_CB_RECEIVED_ACTION,
instead of as a GSM/UMTS "pdu" byte array.
Existing functionality for ETWS and CMAS alerts over GSM/UMTS continues
to be supported using the new radio-technology independent SmsCbMessage
and related objects. Test cases are added to verify that valid and
invalid broadcast data is handled appropriately.
Unit testing discovered a bug in the BitwiseOutputStream utility class
used by the added test cases. When the BitwiseOutputStream object must be
expanded (in the private possExpand() method), the mEnd field is not
updated to the new array size. This causes a new array to be allocated
on every new write, and for all data beyond the original array allocation
to be replaced with zeroes. Fixed by adding a line to possExpand() to
update mEnd. Added a test case to BitwiseStreamsTest to verify the fix.
Besides the test cases, BitwiseOutputStream is only used by BearerData in
two places, both of which allocate a sufficient initial buffer. So the
bug in BitwiseOutputStream is not critical to fix for normal operation,
but should be fixed so that the test cases using it function correctly.
Bug: 5856308
Change-Id: Ie3e6af747976ce9b8a3e71e76fec71709cf86545
Bug 6083776
While WebKit limits the length of a field with maxlength, the
InputConnection can get out of sync with it when it doesn't
recognize that the characters haven't been changed. Adds
maximum field length to WebViewInputConnection to limit the
characters typed.
WebKit Change: Ie02f82a3f5b3527c378938d93bac2dece802af26
Change-Id: I135871db7809e8dc28a3ad8d3aa852976a274555
Allow disk access during application and provider setup. This could
block processing ordered broadcasts, but later processing would
probably end up doing the same disk access.
Bug: 6083825
Change-Id: I80f383063cedba2b099c78465134faa811e898d8
1. The NumberPicker was showing the IME if the input field
gets focus and hiding it when the the arrows are pressed.
The leads to a nasty behavior when the input is the first
focusable and the uses presser an arrow button. In such
a case the IME shows and hides on every arrow press pushing
the window content up and down - this looks pretty ugly.
Now the IME is show on double tap of the input field.
2. The NumberPicker input now by default has an IME action
done, hence after editing it the IME goes away.
3. The NumberPicker input now clears focus when it gets
IME action done, so the last picker in a sequence
does not show selection which is focus driven.
4. NumberPicker was incorrectly detecting double tap to
begin edit and it was possble to start edit on singe tap
if the user has double tapped before to start an edit.
Now double tap detection is using the double tap timeout
correctly.
bug:6071977
Change-Id: I0ff5a491064e51663b3abec675d839d0a65b986a
Bugs 6075823, 6050563
Revise pressed state dispatch logic:
Only propagate pressed state to non-clickable views. This should
eliminate the "double glow" problem in some list items where a
clickable child button has a secondary glow along with a clickable
parent. This only applies to setPressed(true) calls; setPressed(false)
must propagate. Don't early-out in setPressed to support this use
case.
Change-Id: Ibbe2309f5030282fad8d23e4a9bc4616b3f5dc7c
