Copy and paste error where wrong compare meant the code thought a target
utilization option was specified even if there wasn't one.
b/7062303
Change-Id: Ibf1c6cf72743c5fbec7618a719d12d0373184754
Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.
Added JNI for all of the new surface flinger display API calls.
Enforced the requirement that all Surfaces created by
the window manager be named.
Updated the display manager service to use the new methods.
Change-Id: I2a658f1bfd0437e1c6f9d22df8d4ffcce7284ca2
The purpose of this change is to remove direct reliance on
SurfaceFlinger for describing the size and characteristics of
displays.
This patch also starts to make a distinction between logical displays
and physical display devices. Currently, the window manager owns
the concept of a logical display whereas the new display
manager owns the concept of a physical display device.
Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
This refactoring sets the stage for a follow-on change that
will make use additional functions of the power HAL.
Moved functionality from android.os.Power into PowerManagerService.
None of these functions make sense being called outside of the
system server. Moving them to the PowerManagerService makes it
easier to ensure that the power HAL is initialized exactly once.
Similarly, moved ShutdownThread out of the policy package and into
the services package where it can tie into the PowerManagerService
as needed.
Bug: 6435382
Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
Instead of each application loading the KeyCharacterMap from
the file system, get them from the input manager service as
part of the InputDevice object.
Refactored InputManager to be a proper singleton instead of
having a bunch of static methods.
InputManager now maintains a cache of all InputDevice objects
that it has loaded. Currently we never invalidate the cache
which can cause InputDevice to return stale motion ranges if
the device is reconfigured. This will be fixed in a future change.
Added a fake InputDevice with ID -1 to represent the virtual keyboard.
Change-Id: If7a695839ad0972317a5aab89e9d1e42ace28eb7
There is no graceful way to kill Android application processes.
They typically have many threads running doing various things
When System.exit() is called, those threads just keep going
while the cleanup actions run until the process finally.
Performing shutdown actions can easily cause more harm than good.
For example, closing the Binder driver's file descriptor may
cause other threads waiting on Binder to wake up and then crash
in nasty ways after receiving EBADF.
So when an Android application exits, skip the cleanup and just
call _exit() to end it all.
Bug: 6168809
Change-Id: I29790c064426a0bf7dae7cdf444eea3eef1d5275
Basic functionality of handling View properties (transforms,
left/right/top/bottom, and alpha) at the native DisplayList level.
This logic is disabled for now (via compile-time flags in View.java and
DisplayListRenderer.h) as we continue work on it (there is no advantage
to the new approach until we optimize invalidation and rendering paths
to use the new code path).
Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
SerialManager: provides access to serial ports
SerialPort: for reading and writing data to and from serial ports
IO with both array based and direct ByteBuffers is supported.
Accessing serial ports requires android.permission.SERIAL_PORT permission
Each platform must configure list of supported serial ports in the
config_serialPorts resource overlay
(this is needed to prevent apps from accidentally accessing the bluetooth
or other system UARTs).
In addition, the platform uevent.rc file must set the owner to the
/dev/tty* files to "system" so the framework can access the port.
Signed-off-by: Mike Lockwood <lockwood@android.com>
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
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
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
* Instead of javaland trying to write commands to
/proc/net/xt_qtaguid/ctrl
use the libcutils/qtaguid.c support via JNI.
* Get rid of tagToKernel() handled by qtaguid library.
Requires libcutils changes from c/132538/
Change-Id: I9de5b3fa4a596c56835024c6d376769a0eea7db1
This removes the ParcelSurfaceTexture class since that functionality has been
folded into Surface.java. The change also updates the MediaPlayer to get rid
of setParcelSurfaceTexture() and modifies setTexture() to use the new Surface
functionality in order to simplify the code.
Change-Id: Iafa75ea3188263928128325d8a726786971b4de4
The built-in ZipFile class was quite a long time to find an unpack
libraries. Move everything to using the libutils ZipFileRO class that
goes quite a bit faster. Initial measurements are 6 times faster than
the Java code.
Also, read files off the disk and compare their CRC against the APK's
CRC to see if we need to write the new file to disk. This also cuts down
the bootup time by up to a second per APK that has native files.
Change-Id: Ic464a7969a17368fb6a6b81d026888c4136c7603
This adds a new ParcelSurfaceTexture.java class that can be instantiated with
a SurfaceTexture and used to send the corresponding ISurfaceTexture interface
to another process via Binder. The ParcelSurfaceTexture java object can then
be used to create an ANativeWindow based on the SurfaceTextureClient interface.
Change-Id: Ie38ea948b866e52f36a6d0f6cde19b54a8546817
