Added a new method ContentObserver.onChange(boolean, Uri) that
receives the changed content Uri. This can help applications make
better decisions about how to interpret a change notification.
Change-Id: I8e35378b6485fe22c5bc240ba07557d269af0836
Improved the documentation a little bit.
Fixed a bug in ContentService wherein if a ContentObserver was
passed as an argument and its deliverSelfNotifications() method
returned true, then notifyChange would tell all observers that
the change was a self-change even though it was only a self-change
from the perspective of the provided observer.
Deprecated ContentObservable.notifyChange since it is never
used and in general it shouldn't be because we want the notification
to be posted to the handler.
Change-Id: Idde49eb40777e011a068f2adae8a32f779dfb923
Adds the new interface to the user dictionary, which includes
a clean way of inserting words in any locale and support for
shortcuts.
Change Ib318c047 implements the provider part of this.
Bug: 4646172
Change-Id: Id3ca792f2555fac46728f9d404ab0199971f6503
The main theme of this change is encapsulation. This change
preserves all existing functionality but the implementation
is now much cleaner.
Instead of a "database lock", access to the database is treated
as a resource acquisition problem. If a thread's owns a database
connection, then it can access the database; otherwise, it must
acquire a database connection first, and potentially wait for other
threads to give up theirs. The SQLiteConnectionPool encapsulates
the details of how connections are created, configured, acquired,
released and disposed.
One new feature is that SQLiteConnectionPool can make scheduling
decisions about which thread should next acquire a database
connection when there is contention among threads. The factors
considered include wait queue ordering (fairness among peers),
whether the connection is needed for an interactive operation
(unfairness on behalf of the UI), and whether the primary connection
is needed or if any old connection will do. Thus one goal of the
new SQLiteConnectionPool is to improve the utilization of
database connections.
To emulate some quirks of the old "database lock," we introduce
the concept of the primary database connection. The primary
database connection is the one that is typically used to perform
write operations to the database. When a thread holds the primary
database connection, it effectively prevents other threads from
modifying the database (although they can still read). What's
more, those threads will block when they try to acquire the primary
connection, which provides the same kind of mutual exclusion
features that the old "database lock" had. (In truth, we
probably don't need to be requiring use of the primary database
connection in as many places as we do now, but we can seek to refine
that behavior in future patches.)
Another significant change is that native sqlite3_stmt objects
(prepared statements) are fully encapsulated by the SQLiteConnection
object that owns them. This ensures that the connection can
finalize (destroy) all extant statements that belong to a database
connection when the connection is closed. (In the original code,
this was very complicated because the sqlite3_stmt objects were
managed by SQLiteCompiledSql objects which had different lifetime
from the original SQLiteDatabase that created them. Worse, the
SQLiteCompiledSql finalizer method couldn't actually destroy the
sqlite3_stmt objects because it ran on the finalizer thread and
therefore could not guarantee that it could acquire the database
lock in order to do the work. This resulted in some rather
tortured logic involving a list of pending finalizable statements
and a high change of deadlocks or leaks.)
Because sqlite3_stmt objects never escape the confines of the
SQLiteConnection that owns them, we can also greatly simplify
the design of the SQLiteProgram, SQLiteQuery and SQLiteStatement
objects. They no longer have to wrangle a native sqlite3_stmt
object pointer and manage its lifecycle. So now all they do
is hold bind arguments and provide a fancy API.
All of the JNI glue related to managing database connections
and performing transactions is now bound to SQLiteConnection
(rather than being scattered everywhere). This makes sense because
SQLiteConnection owns the native sqlite3 object, so it is the
only class in the system that can interact with the native
SQLite database directly. Encapsulation for the win.
One particularly tricky part of this change is managing the
ownership of SQLiteConnection objects. At any given time,
a SQLiteConnection is either owned by a SQLiteConnectionPool
or by a SQLiteSession. SQLiteConnections should never be leaked,
but we handle that case too (and yell about it with CloseGuard).
A SQLiteSession object is responsible for acquiring and releasing
a SQLiteConnection object on behalf of a single thread as needed.
For example, the session acquires a connection when a transaction
begins and releases it when finished. If the session cannot
acquire a connection immediately, then the requested operation
blocks until a connection becomes available.
SQLiteSessions are thread-local. A SQLiteDatabase assigns a
distinct session to each thread that performs database operations.
This is very very important. First, it prevents two threads
from trying to use the same SQLiteConnection at the same time
(because two threads can't share the same session).
Second, it prevents a single thread from trying to acquire two
SQLiteConnections simultaneously from the same database (because
a single thread can't have two sessions for the same database which,
in addition to being greedy, could result in a deadlock).
There is strict layering between the various database objects,
objects at lower layers are not aware of objects at higher layers.
Moreover, objects at higher layers generally own objects at lower
layers and are responsible for ensuring they are properly disposed
when no longer needed (good for the environment).
API layer: SQLiteDatabase, SQLiteProgram, SQLiteQuery, SQLiteStatement.
Session layer: SQLiteSession.
Connection layer: SQLiteConnectionPool, SQLiteConnection.
Native layer: JNI glue.
By avoiding cyclic dependencies between layers, we make the
architecture much more intelligible, maintainable and robust.
Finally, this change adds a great deal of new debugging information.
It is now possible to view a list of the most recent database
operations including how long they took to run using
"adb shell dumpsys dbinfo". (Because most of the interesting
work happens in SQLiteConnection, it is easy to add debugging
instrumentation to track all database operations in one place.)
Change-Id: Iffb4ce72d8bcf20b4e087d911da6aa84d2f15297
This adds Resources.getDrawableForDensity() and
Resources.getValueForDensity(). These are needed for applications
to correctly retrieve larger icons such as in launcher when
running on a tablet. We had already exposed the APIs to tell the
application which density to use for app icons on the current
device, but didn't unhide these APIs that allowed you to
actually retrieve them.
This is safe to do without introducing a new API level (as long
as we do it soon) because we know these APIs already exist in
Android 4.0, and there is no reason for anyone to be removing
them when building a device.
Change-Id: I5138e5dc908197b66a98d20af73c5374cb5d41d3
1. AccessibilityServiceInfo loading the description string on
creation and using this value. Hence, changing the locale
results in reporting incorrectly localized string. Added a
new loadDescription method to return the localized version.
2. Deprecated the old method.
bug:5807616
Change-Id: Id82bda3c6a90fa6681b035d20da0b8688ed68da3
- we can do this, because HitTestResult never had a published constructor
so the only code that can create it has always lived in this package.
- doing this makes the class design cleaner, and smooths the way for allowing
the new WebView implementation to deal in these results in contexts where
the appropriate WebView instance is not readily available.
Change-Id: I9e1f1c0faeb16436b1861aab3c2871a5851dfb54
o Lots of documentation fixes.
o Add NdefMessage(NdefRecord ... records) ctor
o Add NdefRecord.createMime()
o Add NdefRecord.createExternal()
o Add toString(), equals() and hashCode() implementations
o Deprecate NdefRecord(byte[]) and NdefRecord.toByteArray()
o Remove framework dependency on libnfc_ndef.so
o Remove NfcAdapter.getDefaultAdapter(), its been deprecated a while
next step:
o Attempt to move NdefMessage -> Intent conversion into NDEF, and
make it CTS tested. This will ensure consistent NDEF -> Intent
mapping across all Android devices.
Change-Id: Ifed4910caa9a1d6bad32dbf0a507ab22bca35e22
The various Properties added to View in 4.0 (ALPHA, TRANSLATION_X, etc.)
were not final, making it possible to assign on property to another.
Not something that someone would want to do, but we should try to prevent
that kind of mess. This API change makes those properties final.
Change-Id: I7d0c7f738eb2074d0781b1ba6a7c19339bac4477
We can do this because the classes already cannot be subclassed
by applications due to the fact they only have package private
constructors.
One very nice consequence of this observation is that we can hide or
delete several @deprecated protected members which are effectively
inaccessible because applications cannot create subclasses!
Change-Id: I2d3a0d2ad72b9289ebcdf907e4e4e6caf27f9076
The idea is that this is a device which is more-or-less headless. It
might have some limited interaction capabilities, but it's not something
that you want to rely on having.
Change-Id: Ib92f53a120bf83de781728011721a4859def7d9f
New API to let you build an Intent whose base configuration is correct,
but has an additional "selector" to pick out the specific app that you
would like launched.
Change-Id: Ide9db6dc60e2844b7696cfe09b28337fe7dd63db
By default we do not speak passwords if the user has no headset. However,
many users find this too restrictive and would like a way to enable
password announcement. While we cannot speak the passwords all the time
,to avoid leaking them, we expose a preference so each user can choose
the option that best works for him/her.
bug:5712607
Change-Id: I6eb0c40834abe5297f7dc74be02d180a5bef0174
Improved quick launch bookmarks to support category-based shortcuts
instead of hardcoding package and class names for all apps.
Added a set of Intent categories for typical applications on the
platform.
Added support for some of the HID application launch usages to
reduce reliance on quick launch for special purpose keys. Some
keyboard vendors have hardcoded launch keys that synthesize
"Search + X" type key combos. The goal is to encourage them
to stop doing this by implementing more of HID.
Bug: 5674723
Change-Id: I79f1147c65a208efc3f67228c9f0fa5cd050c593
