Fix a few things found in our "Constants" section.
- Close unclosed links.
- Avoid periods inside parens for summary sentences.
- Lowercasing in a few places for consistency.
Change-Id: I9aa689fd980b373614dae7c4f8257e0786d2340a
Fix for failing android.speech.tts.cts.TextToSpeechServiceTest#testSynthesizeToFile.
In test env, ParcelFileDescriptor instance may be EXACTLY the same one that client uses.
And if it's closed by a client, then service is prevented from writing anything to the output.
Bug: 8377754
Change-Id: I7f95aae1b877e543ab02d3c548b29537aa852a89
This fixes a bug where keyguard was created without setting
the preferred orientation. The result is it would temporarily
assume the orientation of the device after being hidden.
The fix sets the flag when the keyguard view hierarchy is created
rather than when visibility changes.
Fixes bug 8124979
Change-Id: Ic54a185e4f51f79f2bb7fbc5ffc6992641e89132
Add a minimum size for the event pools for devices which don't have sensors.
Otherwise the system server crash loops on boot.
Change-Id: Ic51c6fc26c8779d9f435f358d4274148a2ddbfb3
This API can be used to run arbitrary tasks on a pool of worker
threads. The number of threads is calculated based on the number
of CPU cores available.
The API is made of 3 classes:
TaskManager
Creates and manages the worker threads.
Task
Describes the work to be done and the type of the output.
A task contains a future used to wait for the worker thread
to be done computing the result of the task.
TaskProcessor
The processor dispatches tasks to the TaskManager and is
responsible for performing the computation required by
each task. A processor will only be asked to process tasks
sent to the manager through the processor.
A typical use case:
class MyTask: Task<MyType>
class MyProcessor: TaskProcessor<MyType>
TaskManager m = new TaskManager();
MyProcessor p = new MyProcessor(m);
MyTask t = new MyTask();
p.add(t);
// Waits until the result is available
MyType result = t->getResult();
Change-Id: I1fe845ba4c49bb0e1b0627ab147f9a861c8e0749
The previous show/hide messages in the queue were still trying
to be honored even after a new ime was attached.
Fixes bug 8263462.
Change-Id: Iee60dbd1d58542f73aedeac5ccb54cddeb5d5dfe
Commit 2a57ca93 introduced a regression in startBluetoothSco()
where the calling pid was cleared before creating the entry for
the client app. The pid in the entry was always the system server pid
and the SCO client verification logic was broken preventing the activation
of the BT SCO connection.
Change-Id: I4e024b22fceb350f829ff0d8664703faeef7af48
You can now declare shared libraries in apks that are
on the system image. This is like the existing mechanism
of using raw jar files as shared libraries, but since they
are contained in an apk the library can actually be updated
from the Play Store. And this even (mostly) works.
There are some deliberate limitations on this feature. A
new shared library *must* be declared by an apk on the system
image. Installing an update to a system image apk does not
allow you to add new shared libraries; they must be defined
by everything on the base system image. This allows us to
get rid of a lot of ugly edge cases (shared libraries that were
there disappearing after an update is uninstalled for example)
and give some brakes on apps that happen to be pre-installed
on devices from being able to throw in new shared libraries
after the fact.
In working on this, I ran into a recently introduced bug where
uninstalling updated to system apps would fail. This was done
to allow for the new restricted users that don't have all
system apps, but conflicts with the existing semantics for
uninstalling system apps. To fix this I added a new uninstall
flag that lets you switch on the new mode if desired.
Also to implement the desired logic for limitations on declaring
new shared libraries in app updates, I needed to slightly tweak
the initial boot to keep the Package object for hidden system
packages associated with their PackageSetting, so we can look at
it to determine which shared libraries are allowed. I think
this is probably more right than it was before -- we already
need to parse the package anyway, so we have it, and when you
install an update to a system app we are in this same state
until you reboot anyway.
And having this fixed also allowed me to fix another bug where
we wouldn't grant a new permission to an updated app if its
system image version is updated to request the permission but
its version is still older than whatever is currently installed
as an update. So that's good.
Also add new sample code showing the implementation of an apk
shared library and a client app using it.
Change-Id: I8ccca8f3c3bffd036c5968e22bd7f8a73e69be22
"[+>" more icon was never show in status bar because
the member variable for this icon was not initialized
from resources. This fix enables "[+>" icon to appear
in status bar when the number of indications in status
bar becomes large.
Bug: 8368569
Change-Id: Ieb3412eed831052d69c0cf63c9b4230c38171e4a
