Default is 2MB persist threshold, but even that can be substantial
for devices on 100MB/month plans. This change gradually reduces the
persist threshold up to 8x lower (256kb outstanding) based on lowest
active policy.
Bug: 5382676
Change-Id: Ief4e8cdb169bfb151a3d1b45722a8eaa01926508
This is not perfect and only works if the CC is known via
the GSM radio and is only accurate if there is one time zone
per country. This does nothing to resolve time zone problems
for wifi only devices.
So this is a partial fix for bug 2896745
Bug: 2896745
Change-Id: I78f013836c4e4870b8b1016a8312f5adbe0d31c9
Create a LocalLog class for logging within a service for dumping in dumps.
Use it in the NativeDaemonConnector so we can get some insight into what
is happening in these lockups.
bug:5864209
Change-Id: I68ddc58847f3c8de613be9528570f8c3157d8274
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
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
Added an interface that is the contract for a client to expose a virtual
view hierarchy to accessibility services. Clients impement this interface
and set it in the View that is the root of the virtual sub-tree. Adding
this finctionality via compostion as opposed to inheritance enables apps
to maintain backwards compatibility by setting the accessibility virtual
hierarchy provider on the View only if the API version is high enough.
bug:5382859
Change-Id: I7e3927b71a5517943c6cb071be2e87fba23132bf
- force TextView to LOCALE text heuristic when in "password" mode
- remove TEXT_LAYOUT_DIRECTION_UNKNOWN_DO_NOT_USE
- LocaleUtils.getLayoutDirectionFromLocale() returns "LTR" is locale is NULL or ROOT
Change-Id: I182c46aaf2d73c8b18967fffa230bfabec91ed06
unable to resolve static field 106 (DEBUG) in Landroid/util/Config
Config was removed, but apparently some apps are actually using it.
Put it back.
Change-Id: Iebcb94b1158abc5e8c3dd9855068d2e9223d8999
1. Seperated touch exploration to be a seperate setting rather being
magically enabled by the system of accessiiblity is on the there
is at leas one accessibility service that speaks enabled. Now
there is a setting for requesting touch exploration but still the
system will enabled it only if that makes sense i.e. accessibility
is on and one accessibility service that speaks is enabled.
2. Added public API for checking of touch exploration is enabled.
3. Added description attribute in accessibility service declaration
which will be shown to the user before enabling the service.
4. Added API for quick cloning of AccessibilityNodeInfo.
5. Added clone functionality to SparseArray, SparseIntArray, and
SparseBooleanArray.
bug:5034010
bug:5033928
Change-Id: Ia442edbe55c20309244061cd9d24e0545c01b54f
Uses NTP server and timeout from secure settings, or fallback to
defaults in resources. Update various system services to use cached
NTP time when fresh enough, or force updates as needed.
Bug: 4517273
Change-Id: Ie1c4c4883836013d02ca0bbd850cf8949f93b34b
We were applying the density compat mode scaling multiple times to
display metrics, causing bad values.
Change-Id: Iafafd9a5e94b9d774cd2715bf968e91602a1bd82
- now relying on ICU.getScript() and ICU.addLikelySubtags() for getting the locale script
- clean unit tests imports
Change-Id: Icdc45fa78490d1e2dde0e83bca0feea8aa205cdf
The layoutlib is used in the SDK which might not have a default Locale,
so the language string will be some kind of junk. This causes a crash in
the new LocaleUtils
Change-Id: I24e5115c56e39d394dcf89ec6cff609525b3c73e
This change adds a generic Property facility to the SDK, which allows an
easy way to reference fields (private or otherwise) in a general way.
For example, animations can use this facility to animate 'properties'
on target objects in a way that is more code- and compiler-friendly than
the existing String-based approach (for objects which have implemented
Properties, of course). The animator classes have been updated to use
this new approach (in addition to Strings, which are still more generally
useful for objects which have get/set functions but not Property objects).
The change also includes new Property objects on View (which can now be
used in creating animations on Views).
There is an unrelated change on GLES20RecordingCanvas to change the way we
cache bitmaps, which avoids spurious garbage by using an ArrayList instead of
a HashSet.
Change-Id: I167b43a3fca20e7695b1a23ca81274367539acda
1. Views are represented as AccessibilityNodeInfos to AccessibilityServices.
2. An accessibility service receives AccessibilityEvents and can ask
for its source and gets an AccessibilityNodeInfo which can be used
to get its parent and children infos and so on.
3. AccessibilityNodeInfo contains some attributes and actions that
can be performed on the source.
4. AccessibilityService can request the system to preform an action
on the source of an AccessibilityNodeInfo.
5. ViewAncestor provides an interaction connection to the
AccessibiltyManagerService and an accessibility service uses
its connection to the latter to interact with screen content.
6. AccessibilityService can interact ONLY with the focused window
and all calls are routed through the AccessibilityManagerService
which imposes security.
7. Hidden APIs on AccessibilityService can find AccessibilityNodeInfos
based on some criteria. These API go through the AccessibilityManagerServcie
for security check.
8. Some actions are hidden and are exposes only to eng builds for UI testing.
Change-Id: Ie34fa4219f350eb3f4f6f9f45b24f709bd98783c
