Because the standard Looper.loop code calls Message#recycle it is
imperative that Handler#handleMessage code not attempt to resue
a message it receives. If allowed to do so it will cause bugs that
could be difficult to diagnois.
This change adds Message#flags and uses one bit to reliably detect
a message is in use and throws an error in MessageQueue#enqueueMessage.
This allows early detection of this bug.
Note: This is not new functionality, but the current implementation does
not detect messages that are in use because it uses Message#when != 0
as the detection mechanism. The problem is that a Message#when value of 0
is valid value used to place a message at the front of the queue and is
thus unreliable.
Another option is to change the setting of Message#when in Message#enqueueMessage
so that it is never 0, although that does change subtly a publicly accessible
field.
Yet another option would be to use other fields but all candidates have
similar problems as when in that they are publicly accessible or even
settable such as Message#target.
Change-Id: I040d6e546376f7b1ed1e4daa0d5644cce8bf333a
This reverts commit 6083d81ce4.
Reverting this because it causes runtime to reboot in a loop
if connected to a Bluetooth Headset.
copyFrom() needs to check for the introduced bit too.
Because the standard Looper.loop code calls Message#recycle it is
imperative that Handler#handleMessage code not attempt to resue
a message it receives. If allowed to do so it will cause bugs that
could be difficult to diagnois.
This change adds Message#flags and uses one bit to reliably detect
a message is in use and throws an error in MessageQueue#enqueueMessage.
This allows early detection of this bug.
Note: This is not new functionality, but the current implementation does
not detect messages that are in use because it uses Message#when != 0
as the detection mechanism. The problem is that a Message#when value of 0
is valid value used to place a message at the front of the queue and is
thus unreliable.
Another option is to change the setting of Message#when in Message#enqueueMessage
so that it is never 0, although that does change subtly a publicly accessible
field.
Yet another option would be to use other fields but all candidates have
similar problems as when in that they are publicly accessible or even
settable such as Message#target.
Change-Id: I2df600537700a3fe206678f38bcae7329751c4e5
Merge commit '4d42ccd1579da53aaaf132a6ad26a06e2baa5b98' into gingerbread-plus-aosp
* commit '4d42ccd1579da53aaaf132a6ad26a06e2baa5b98':
Tracking merge of dalvik-dev to gingerbread
Merge commit 'f996ed9f2e4a992e5d884077a15dcc23a8d90c44' into gingerbread-plus-aosp
* commit 'f996ed9f2e4a992e5d884077a15dcc23a8d90c44':
Make vCard importer/exporter aware of multi-byte parameters.
This depends on a kernel patch that implements read(2)
in the ashmem driver.
Bug http://b/issue?id=2595601
Change-Id: Ie3b10aa471aada21812b35e63954c1b2f0a7b042
Bluetooth stress tests include stress tests for enabling/disabling bluetooth,
making the device discoverable/undiscoverable, and starting and stopping scans.
Change-Id: Ic8ba09475ffe5551717438673e0ed3f4bd17cf2f
Merge commit '4ae1e382f4b6c5bb9e757f35f82ad48dc02c32af' into gingerbread-plus-aosp
* commit '4ae1e382f4b6c5bb9e757f35f82ad48dc02c32af':
Tracking merge of dalvik-dev to gingerbread
PackageManagerTests was trying to mount and unmount the media without
waiting for the correct state to arrive. It was proceeding with any
state transition.
Some tests had their own volume mounting and unmounting code that was
flawed, so switch it to the more robust mountMedia() and unmountMedia()
implementations.
Change-Id: If464927bb09dd15cb040c6cce195a6ad8452de95
android.database.CursorWindowTest#testWriteCursorToWindow (and possibly other
tests) were was failing because it couldn't locate a android-common class.
Fix is to include android-common as a static library, as opposed to a runtime
library.
Change-Id: Iae50cf409e76a85ee79e4af71e9b903d18630078
Adjust test sizes to better align with the test's runtime.
Also do some import cleanup and migrate to non-deprecated classes.
Change-Id: Ib2b190ddbe84f9ea8f5d6d3604bd4855d00df7a9
1. SQLIteStatement.executeUpdateDelete() replaces execute() - and returns the
number of rows changed.
2. let SQLiteDatabase.execSQL() call the above new API - which
means all CRUD statements by execSQL() are stored in prepared statement cache.
3. remove the following from SQLiteDatabase
lastrowId
lastchangecount()
native_execSQL()
Change-Id: I4e93a09dc381f425c3ae6ccc331a7bf227491e22
SQLiteCursor has two members: mQuery, mDatabase
but mQuery already has mDatabase.
there is no need for SQLiteCursor.mDatabase.
and everytime SQLiteQuery.mDatabase is to be used, try to use a pooled database
connection handle, if possible.
Change-Id: I42b2376d714a1a4091c843e245a45b882bb7fee6
Currently when ListPreferences are used in a PreferenceActivity, the summary
values are set to the same as the current index in mEntryValue. This patch
adds the ability for a string substitution to be used in the summary
which points to the corresponding entry in mEntries to aid in
localization.
For example a preference may be named "color" with the following attributes
in the locale "de" (German):
mEntryValues = { "red", "green", "blue" }
mEntries = { "rot", "grün", "blau" }
mSummary = "Die Farbe ist %1$s."
getSummary() returns "Die Farbe ist grün."
Change-Id: Iea169ac3d1c9d6290d853fc7c67a7c4c8a11bb90
Do compiling of sql, binding of args and execution of the SQL
statement within one single database lock period.
This reduces the number of times the database lock
needs to be acquired during the course of compilation, binding
and execution of a SQLiteStatement.
Change-Id: I22b090ec9e10fc0aa2532a93bafe610af2546b58
Some (including the Contacts app) do the following:
1. Open database
2. As part of database_connection.onCreate(),
Create some SQLiteStatement objects to cache them in the process
3. attach databases
WAL doesn't work with attached databases. so, apps doing the above
should enable WAL only if there are no attached databases.
But we would like to enable WAL automatically for all apps after step #1 above
and disable WAL if the app subsequently does 'attach database' SQL.
this works only if there are no SQLiteStatement objects created in step # 2,
because SQLiteStatements cwmaintain a hard-reference to the database connection
for life and also to the prepared SQL statement id.
It is quite difficult to disable WAL in step # 3
if it is enabled in step # 1
and then a connection pool gets used by step # 2
would make WAL disabling easier if SQLiteStatement refers to prepared SQL
statement id only when it is needed (during binding and execute calls)
and thus NOT tied to a spacific database conenction.
also, from the standpoint of not blocking readers, it helps NOT to have
SQLiteStatement be married to a database connection and prepared SQL statement
id for life.
Change-Id: I464d57042965a28d2bde88e0f44b66ec119b40dc
this method causes sql statement in a SQLiteProgram object to be never
re-compiled. thats not desirable, is it?
there should be no need for this method.
Change-Id: I207fad6415c1e2ef4097ee65a3ff347b5435b994
