Splits interface and implementation; all client calls are forwarded
to an abstract WebViewProvider interface, and the existing implementation
moved into the WebViewClassic implementor of this interface.
Originally taken from a snapshot from the development branch, by:
git diff HEAD 9a4c328a54cc05e5 | git apply
- but then rebased to keep up to date with master
Interdepends on webkit and Browser changes:
https://android-git.corp.google.com/g/158979https://android-git.corp.google.com/g/167911
Change-Id: I91403f32654ff308934e95c832d17b292a7d9b2e
Fix the current asynchronous API to use callback like the way
was done with p2p API.
In the process, fix the use of WPS
Change-Id: Ib6f8714cf51b3525b655948268804e7eaaf17587
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
1. UiTestAutomationBridge was accessing the root node in the
active window by tracking the accessibility event stream
and keeping the last active window changing event. Now
the bridge is stateless and the root node is fetched by
passing special window and view id with the request to
the system.
2. AccessibilityNodeInfos that are cached were not finished,
i.e. not sealed, causing exception when trying to access
their children or rpedecessors.
3. AccessibilityManagerService was not properly restoring its
state after the UI automation bridge disconnects from it.
I particular the devices was still in explore by touch mode
event if no services are enabled and the sutomation bridge
is disconnected.
4. ViewRootImpl for the focused window now fires accessibility
events when accessibility is enabled to allow accessibility
services to determine the current user location.
5. Several missing null checks in ViewRootImpl are fixed since
there were scenraios in which a NPE can occur.
6. Update the internal window content querying tests.
7. ViewRootImpl was firing one extra focus event.
bug:6009813
bug:6026952
Change-Id: Ib2e058d64538ecc268f9ef7a8f36ead047868a05
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
Because the NetworkInfo included in CONNECTIVITY_ACTION broadcast
extra does not reflect the state applicable to the calling UID, and
the last sticky broadcast may have stale state, transition to calling
ConnectivityManager.getActiveNetworkInfo() directly.
Change-Id: I86b316fbedd0273585ad5f1248b091bc3a3a5520
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused. Also note that at the end the View did not
clear its focus, hence no focus change callbacks
should be invoked.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
1. Now when an interrogating client requires an AccessibilibtyNodeInfo
we aggressively prefetch all the predecessors of that node and its
descendants. The number of fetched nodes in one call is limited to
keep the APIs responsive. The prefetched nodes infos are cached in
the client process. The node info cache is invalidated partially or
completely based on the fired accessibility events. For example,
TYPE_WINDOW_STATE_CHANGED event clears the cache while
TYPE_VIEW_FOCUSED removed the focused node from the cache, etc.
Note that the cache is only for the currently active window.
The ViewRootImple also keeps track of only the ids of the node
infos it has sent to each querying process to avoid duplicating
work. Usually only one process will query the screen content
but we support the general case. Also all the caches are
automatically invalidated so not additional bookkeeping is
required. This simple strategy leads to 10X improving the
speed of the querying APIs.
2. The Monkey and UI test automation framework were registering a
raw event listener for accessibility events and hence perform
connection and cache management in similar way to an AccessibilityService.
This is fragile and requires the implementer to know internal framework
stuff. Now the functionality required by the Monkey and the UI automation
is encapsulated in a new UiTestAutomationBridge class. To enable this
was requited some refactoring of AccessibilityService.
3. Removed the *doSomethiong*InActiveWindow methods from the
AccessibilityInteractionClient and the AccessibilityInteractionConnection.
The function of these methods is implemented by the not *InActiveWindow
version while passing appropriate constants.
4. Updated the internal window Querying tests to use the new
UiTestAutomationBridge.
5. If the ViewRootImple was not initialized the querying APIs of
the IAccessibilityInteractionConnection implementation were
returning immediately without calling the callback with null.
This was causing the client side to wait until it times out. Now
the client is notified as soon as the call fails.
6. Added a check to guarantee that Views with AccessibilityNodeProvider
do not have children.
bug:5879530
Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
Utility that rotates files over time, similar to logrotate. There is
a single "active" file, which is periodically rotated into historical
files, and eventually deleted entirely. Files are stored under a
specific directory with a well-known prefix.
Bug: 5386531
Change-Id: I29f821a881247e50ce0f6f73b20bbd020db39e43
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
For a connected network, keep status as CURRENT. For a network,
that is disconnected it should be ENABLED. A disabled network
will have the status as DISABLED
Also, add a unit test to ensure there is only one CURRENT network
that is connected
Change-Id: Iaa4a7124a0c372a8f6df3d846ae8c15d9b29cf13
1. AccessibilityInteractionConnections were removed from the
AccessiiblityManagerService but their DeathRecipents were
not unregistered, thus every removed interaction connection
was essentially leaking. Such connection is registered in
the system for every ViewRootImpl when accessiiblity is
enabled and inregistered when disabled.
2. Every AccessibilityEvent and AccessiilbityEventInfo obtained
from a widnow content querying accessibility service had a
handle to a binder proxy over which to make queries. Hoewever,
holding a proxy to a remote binder prevents the latter from
being garbage collected. Therefore, now the events and infos
have a connection id insteand and the hindden singleton
AccessiiblityInteaction client via which queries are made
has a registry with the connections. This class looks up
the connection given its id before making an IPC. Now the
connection is stored in one place and when an accessibility
service is disconnected the system sets the connection to
null so the binder object in the system process can be GCed.
Note that before this change a bad implemented accessibility
service could cache events or infos causing a leak in the
system process. This should never happen.
3. SparseArray was not clearing the reference to the last moved
element while garbage collecting thus causing a leak.
bug:5664337
Change-Id: Id397f614b026d43bd7b57bb7f8186bca5cdfcff9
