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
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
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
This avoids warnings about an empty body in an if statement.
mem_free does the same null check, so the accidental extra
semicolon was harmless, and the whole if statement actually
is needless. But if removing the if statements, all the
other ones should be removed too, for consistency.
(This could be done as a separate change).
Change-Id: I1b6064dedd15ffa949043bb5396148aaed9b43f6
The arm specific functions are implemented in .s files,
without any function declarations in headers.
This fixes compiler warnings about implicit declarations
of these functions.
Change-Id: I1512560b6740c1879f378886e05aaad2e3a6c869
