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
o This patch will prevent applications from abusing the API by using
arbitrary int value for DrmErrorEvent or DrmInfoEvent types.
o We should have not defined some type constants in the super/base
class, DrmEvent.
Change-Id: Id0bb12caa8ce471cb6951cc2b5d37ea408f90063
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
Local prototype declarations are added where no suitable ones are
available in headers.
This fixes warnings when compiling as C - while the source
files are named .cpp, they actually are compileable as pure C.
This was committed on the master branch of the opencore
repository in commit a0acb494ea6682ca966b5ebbd3676c89c56d63a6,
based on AOSP contribution 10303.
Change-Id: Ib4e27ea30302c66e0233e63e5a4652f6339bc940
This was committed on the master branch of the opencore
repository in commit da3d0463c999871ee584a0d750be65be65d19b00,
based on AOSP contribution 10302.
Change-Id: I4ad5526634efecc2d2bb3d2169184b8d4d4d7671
This was committed on the master branch of the opencore
repository in commit 5ce7a6fdf125116ffce2e692e14eafef1c807628,
based on AOSP contribution 10301.
Change-Id: Ie32b32c7407f449e382c0b4fd2d60a664e0daa33
This fixes compilation as C - while the source files are named
.cpp, they actually are compileable as pure C. Prior to this,
this table produced multiple definitions of the same symbol.
This was committed on the master branch of the opencore
repository in commit a803bd49a631317e0d52ff060cf1799f7741a47e,
based on AOSP contribution 10017.
Change-Id: Id76274964242b119ab61b8181e557477df1e1521
Some of these tables exist in both the amrnb and amrwb libraries,
but with different content.
This avoids some cases of multiple definitions of symbols, if
linking in both libraries statically into the same executable,
if the libraries are built as C. (As C++, the local symbols
get mangled so they don't conflict with the external C symbols
in amrnb, that are unmangled.)
Most of this was committed on the master branch of the opencore
repository in commit 0cd4b3ac412dd0a8370ce339e89cf346c6cfe395,
based on AOSP contribution 10016.
Change-Id: I5387e699ce54a56dc43fcfa0396dee5c99280fd9
This fixes compilation as C - while the source files are named
.cpp, they actually are compileable as pure C (except for this
cast).
This was committed on the master branch of the opencore
repository in commit ae27d9b2ef68c4e6fc383a8cab93d6baa235ff6b,
based on AOSP contribution 10014.
Change-Id: I4f533313be041ad3e0a03ffc5f4207480894ddd1
1. A bad merge on my part caused ViewRootImpl not to register
for accessibility state change.
bug:6064348
Change-Id: Idf7b8b444e9021e9d9ec3749164cfe448c8268ab
