This fixes a bug where the device could see a priority inversion when
updating display brightness. The problem occurs because the code that
manages screen brightness holds the master lock while waiting for the
native method to complete. On some devices, each call can amount to
tens to hundreds of ms, which meant clients using PowerManager APIs
could block for the duration of the call. In some cases, the animation
could block for many seconds because the unfairness of Java locks.
The solution is to handle all brightness updates in a separate thread that
does not hold the master lock while calling native methods.
This also makes the animation more consistent by animating by actual
wall clock time rather than depending on the round-trip from the driver.
Change-Id: Ifad76fb2fb77e7b2a72dd9150440d87e22581b40
this could happen after an orientation change. basically
we need to triger a geometry-changed when the very first buffer
is received
Change-Id: I097e411fd6612c18725737cffccdbf6b2af3511c
Useful especially for last kmsg (e.g. IMG/DSS logs truncate
and loose useful info). Since this is a max, won't affect files
that are already shorter than 64kb.
Change-Id: Ia5bb178678067e69384285e8c338dc8cb6ad071b
No need to check for presence of item before removing
(but we do lose the log of the previous value).
Change-Id: I2838430824de5f257f2ee15db0c22b1920c67d08
Change the wording of the logs in the various copies of threadLoop()
to be identical. This will make it easier to merge them soon.
Change-Id: Idfa181e437738712c784dc7f746cac79f83d2931
mixerStatus was being declared (and initialized) too early,
which also resulted in a duplicate initialization. Moved
the declaration into the block where it is actually used.
Change-Id: Ifdcfefe362a5efe3493dd616cdb44645c6f9aed5
Also fix the error handling for the property_get.
This is part of preparation for the threadLoop() merge.
Change-Id: I6405190ea18146d1271575e1dfe9f279e8f36b17
As part of the upcoming threadLoop() merge, this CL makes it clearer
what are the similar and different parts before and after unlocking
effect chains.
In each threadLoop(), the old code was:
if (sleepTime == 0) {
// A
unlockEffectChains(effectChains);
// B
} else {
unlockEffectChains(effectChains);
// C
}
The new code is:
if (sleepTime == 0) {
// A
}
unlockEffectChains(effectChains);
if (sleepTime == 0) {
// B
} else {
// C
}
Also this is slightly slower by one "if", it has the advantage of making
it much more obvious about what is done before and after the unlock,
and also to see the similarities and differences among the various
copies of threadLoop().
Change-Id: I7bf4369d2dcb072573ec43b7e52c637f0097dc00
re-add support for pixelformats L_8, LA_88 and RGB_332 in libui
for backward compatibility.
This may or may not fix 6058926
Bug: 6049685
Change-Id: Ic1b8b4cc994522f7fe664da64c0ef76b98bc6d53
This is not a real race, because addOutputTrack was only called in two
places, and in both places there could be no other threads referencing
the DuplicatingThread instance.
Those two places are:
- the DuplicatingThread constructor, which is of course safe
- openDuplicateOutput - this is safe because it's called immediately
after the new DuplicatingThread, and there are no sp<> either in the
constructor or here which could cause onFirstRef() to do Thread::run().
But for safety in case addOutputTrack is ever called somewhere else,
or there are sp<> created earlier, it is safer to take the thread lock.
Change-Id: I1502d014fa37ec5dbf4bf40d3e2884af311cd5e9
Add comments about which methods implement the AudioBufferProvider interface.
Simplified the definition of kInvalidPts. <stdint.h> is very hard to work
with, there seems to be no way to use it reliably to get INT64_MAX without
having a separate source file, which is ugly because it means kInvalidPts
is not a compile-time constant. So I just deleted AudioBufferProvider.cpp
and used a hard-coded constant instead.
Added a default constructor for Buffer so that the fields aren't random
(especially .raw which is used to determine if the buffer is valid).
Make the pts for getNextBuffer default to kInvalidPTS so code that
doesn't need a pts doesn't have to specify a value.
Rename the parameter to AudioMixer::setBufferProvider to make it clearer.
Change-Id: I87e7290884d4ed975b019f62d1ab6ae2bc5065a5
At end of AudioFlinger::onFirstRef(), the hardware status was being left
in wrong state. It should be AUDIO_HW_IDLE but was AUDIO_HW_INIT.
mHardwareStatus was being set to AUDIO_HW_OUTPUT_OPEN too early, and so
a return would leave it in the wrong state until next hardware operation.
Take the hardware lock for dev->get_parameters, and update mHardwareStatus
before and after.
Keep hardware lock only for the duration of the dev->set_parameters.
Rename two constants in enum hardware_call_state to have the prefix
AUDIO_HW so they follow the naming conventions.
Add comments.
Change-Id: I6c7450b11f9b13adaeef9cec874333e478a58fc0
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
The bit-field TrackBase::mFlags was supposed to have track-specific
flags in the upper 16 bits, and system flags in the lower 16 bits.
The upper 16 bits of mFlags were initialized in the TrackBase
constructor from the flags parameter of IAudioFlinger::createTrack()
and IAudioFlinger::openRecord(), and the lower 16 bits were cleared.
However, the upper 16 bits of mFlags were never acccessed again.
So really there are no track-specific flags. I left the flags
in the parameter list of createTrack() and openRecord() but made a
note that these should be removed eventually as they are dead.
This leaves only the one system flag "step server failed". I replaced
the bit-field mFlags by bool mStepServerFailed, which is simpler and
slightly faster.
Change-Id: I6650f5487be72791b4a67d73adcd10ffa04e2aa5
This change introduces a few new bits of data on
Notification that will help the Notification Manager and
System UI route and display them more intelligently:
-> priority: an integer in a predefined range that
indicates the app's best guess as to the relative
importance (to the user, right now) of that information
-> kind: a tag (really, set of tags) indicating the general
type of notification (realtime, asynchronous, etc)
-> extras: a Bundle of additional key/value pairs
associated with this notification (currently @hidden)
The notification manager takes these data into account when
assigning to each notification a score which is passed with
the notification on to the system UI, where it can be used to
affect presentation. For example:
- Spammy apps (identified explicitly by the user or by
some other means) will have their notifications scored
very negatively by the notification manager, allowing
the UI to suppress them
- Notifications of higher score might be shown larger
or in a different way
- Very important notifications (indicated by a very high
score) might interrupt the user during an otherwise
important task (videochat, game, etc)
Implementation note: This replaces/extends the old internal
notion of "priority", which was mostly used to organize
ongoings and system notifications at the top of the panel.
Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
1. Before there were two caches one in the app process that
kept track only the ids of infos that were given to a
querying client and one in the querying client that
holds the infos. This design requires precise sync
between the caches. Doing that is somehow complicated
since the app has cache for each window and it has
to intercept all accessibility events from that window
to manage the cache. Each app has to have a cache for
each querying client. This approach would guarantee that
no infos are fetched twice but due to its stateful nature
and the two caches is tricky to implement and adds
unnecessary complexity. Now there is only one cache in
the client and the apps are stateless. The client is
passing flags to the app that are a clue what nodes to
prefetch. This approach may occasionally fetch a node
twice but it is considerably simpler and stateless
from the app perspective - there is only one cache.
Fetching a node more than once does not cause much
overhead compared to the IPC.
Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
These are permissions that an application can request, but won't
normally be granted. To have the permission granted, the user
must explicitly do so through a new "adb shell pm grant" command.
I put these permissions in the "development tools" permission
group. Looking at the stuff there, I think all of the permissions
we already had in that group should be turned to development
permissions; I don't think any of them are protecting public APIs,
and they are really not things normal applications should use.
The support this, the protectionLevel of a permission has been
modified to consist of a base protection type with additional
flags. The signatureOrSystem permission has thus been converted
to a signature base type with a new "system" flag; you can use
"system" and/or "dangerous" flags with signature permissions as
desired.
The permissions UI has been updated to understand these new types
of permissions and know when to display them. Along with doing
that, it also now shows you which permissions are new when updating
an existing application.
This also starts laying the ground-work for "optional" permissions
(which development permissions are a certain specialized form of).
Completing that work requires some more features in the package
manager to understand generic optional permissions (having a
facility to not apply them when installing), along with the
appropriate UI for the app and user to manage those permissions.
Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
