DO NOT MERGE
this change must be hand-merged into master due to directory
restructuring.
Fix issues with continuity threshold handling; notably
+ If the steady-state continuity threshold is exceeded, be sure to
clear the on-time flag. Failure to do this will result in the
system picking a new mix point which simply satisfies the
steady-state continuity threshold instead of the startup threshold.
Since we are putting a discontinuity in presentation anyway, we
really want to pick a perfect point, not just an OK point.
+ Tighten the steady-state continuity threshold. It was currently set
to 100mSec which is enormous. 4mSec (the new setting) is much more
appropriate. On systems with a VCXO (like tungsten) this should
never be wrong by more than a sample. If TimedAudioTracks are ever
to be used on VCXO-less systems, this threshold should probably be a
a parameter configurable by applications on a track by track basis
so they can make the tradeoff between allowed error and frequency of
disruptive corrections.
+ Reset the on-time flag if the mixer provides no PTS during a mix
operation. This makes for a convenient way for the HAL to reset
timed tracks when it makes changes for delay compensation across
multiple outputs.
Change-Id: I2cb23de5a3d1f75618abc1c8ab903db883837aa8
Signed-off-by: John Grossman <johngro@google.com>
Keep track of the number of frames pending in the timed audio queue so
we can implement framesReady in O(1) time instead of O(N). This
change partially addresses bug 6020970; the bug will be completely
addressed once this change has been up-integrated into master.
Change-Id: I599eb15ea1f6d715b97b30e65214fb6fadd169df
Signed-off-by: John Grossman <johngro@google.com>
Addresses issues seen in bug 6260139.
This is a really tough bug to repro, but there is no doubt that it is
happening occasionally on our super huge A@H subnet. I have collected
data all weekend; the failure did not occur, but I got enough to have
a theoretical sequence of events which could trigger this behavior.
The sequence goes like this.
1) A network is running and happy with a timeline master M,
maintaining timeline X.
2) Device B boots, but its network is taking a long time to come up.
After 60 seconds of waiting for the network to come up, device B
goes into networkless master mode and creates timeline Y.
3) Device B's network comes up. It immediately sends a master
announcement saying that it is the current low-priority master of
timeline Y (its low priority because it has never had any real
clients)
4) Master M ignores B because B is low priority.
5) Device C boots and sends out a who is master request. It is a race
between M and A to see who will respond first. In this case, A
responds first.
6) C sends B a request which B receives. B now has its first client
and is now high priority. In this scenario, B matches M in all
aspects of the priority ranking function, including winning the tie
breaker (larger MAC address when interpreted as a 48 bit integer)
7) M sends its master announcement; it is ignored by B since B
now wins in the ranking function vs M.
8) Finally, B sends its next master announcement. M sees it, realizes
that there is a higher priority master out there (looks like a
bridged network scenario to M). M gives up master status along
with timeline X. The clients of M become clients of B and move
from timeline X to timeline Y (something which should only be
needed during an actual network bridging event)
This change has a few different things meant to severely minimize the
chance that this can happen.
First, and the most important change, is that networkless masters do
not immediately announce themselves as masters on the network they are
joining. Instead, they transition into Ronin to discover any
pre-existing masters on the network. If there are no masters out
there, the device will simply transition back to master and continue
to maintain the timeline it had in networkless mode. In the scenario
above, however, B should discover M and become its client, preserving
the established timeline X.
Second, any time a device experienced an interface reconfiguration
(including coming out of networkless mode), it clears its high
priority bit. This is a good thing. The bit used to get set again
any time...
1) The device is master and receives a client request.
2) The device becomes a client of another master on the network.
3) The device becomes a master.
Number 3 in this list is a mistake. The high priority bit should only
be set for devices during master election which have been
participating in a timeline which has been used by multiple devices.
We know that this is the case when we are master and receive a
request. We also know that this is the case when we hear from a
master and decide to become its client. Simply becoming a master
should not make us high priority. This behavior has been removed.
Third, timeouts have been adjusted just for some extra "stickyness"
when it comes to master status. Clients now say in the Ronin state
for up to 10 seconds looking for a master sending up to 20 discovery
requests, instead of only 3 seconds (sending 6 requests). The
wait-for-election timeout has been adjusted up from 5 seconds to 12.5
seconds to track the longer election cycle as well. Also, while in
steady-state, clients will now wait until 10 packets (10 seconds)
have not been answered by its master before giving up and dropping
into Ronin.
Change-Id: I438b39f31265e34d6719d4adfa9e8b95a2afc188
Signed-off-by: John Grossman <johngro@google.com>
Stop ANR dialogs from appearing on devices where the ActivityManager dialogs
should not be shown. Instead, kill the process. This is preferable because the
user can't actually do anything on the device.
TESTED = runs on device with that config, simulated ANR using test app.
Change-Id: I6267000afd12ef929f0c625220184c6ab0139552
Fix an issue with buffer lifecycle management which could cause audio
pops on timed outputs. There were two issues at work here.
1) During trim operations for the queued timed audio data, buffers
were being trimmed based on their starting PTS instead of when the
chunk of audio data actually ended. This means that if you have a
very large chunk of audio data (larger than the mixer lead time),
then a buffer at the head of the queue could be eligible to be
trimmed before its data had been completely mixed into the output
stream, even though the output stream was fully buffered and in no
danger of underflow.
2) The implementation of getNextBuffer and releaseBuffer for timed
audio tracks was not keeping anything like a reference to the data
that it handed out to the mixer. The original architecture here
seemed to be expecting a ring buffer design, but timed audio tracks
use a packet based design. Pieces of packets are handed out to the
mixer which then frequently will hold onto that chunk of data
across two mix operations, using the first part of the chunk to
finish a mix buffer and then using the end of the chunk for the
start of the next mix buffer. If the buffer that the mixer is
holding a piece of got trimmed before the start of the next mix
operation, it would return to its heap and could be filled with who
knows what by the time it actually got mixed. On debug builds,
they seem to get zero'ed out as they go back to the heap causing
obvious pops in presentation.
This change addresses both issues. Trim operations are now based on
ending presentation time for a chunk of audio, not the start. Also,
when the head of the queue is in flight to the mixer, it can no longer
be trimmed immediately, merely flagged for trim by the mixer when the
mixer finally does call releaseBuffer.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: Ia1ba08cb9dea35a698723ab2d9bcbf804f1682fe
Activity.setImmersive(boolean) / android:immersive="bool" are now public.
In addition, if the foreground activity is immersive then an update lock
will be held on its behalf. This lets applications such as movie players
suppress the display of intrusive notifications, OTA-availability dialogs,
and the like while they are displaying content that ought not to be
rudely interrupted.
The update lock aspect of this mode is *advisory*, not binding -- the
update mechanism is not actually constrained; it simply uses this information
in deciding whether/when to prompt the user. It's more a guideline than
a rule.
Bug 6154438
Change-Id: Ibd3491fc437077f3fa0d9708ed91955121e8c877
Some audio HALs do not support well a device selection of 0 (no device)
received on an input stream.
This can happen because of a problem in the audioflinger code that handles
the forwarding of the output device selection to the record thread for use by
the pre processing modules that need it. If the output device is 0 (meaning
no op, which happens when stopping playback over A2DP) audioflinger could not
detect it was an output device selection and would forward it to the input
stream (see AudioFlinger::setParameters() and RecordThread::checkForNewParameters_l().
Issue 6179641.
Change-Id: Idae534521866538e0d12ba259a2834f402a922e2
The activity manager now has a tick when launching an app every
500ms, where it collects the current stack traces of the app if
it hasn't finished launching. These traces are included as part
of dumpstate.
This is only done on non-user builds.
Change-Id: I7f09ea00aab821ac81795f48c9d68fcca65f89fe
If you cleared the last usb mode it would fail (and so would setting
it if you started with none). This fixes it to set and unset the
last property correctly.
Change-Id: I8aa62a65ccda5f3872d2995f30d80426f07a281c
A new switch was introduced in AndroidAtHome to deal with a race
condition between the WiredAccessoryObserver and the HW composer HAL.
When the new switch ("hdmi_audio") is present, we want to pay
attention to it instead of paying attention to the old switch
("hdmi"). This change checks at startup for the presence or absence
of the new switch and uses it if available, otherwise it falls back on
classic behavior.
see change ID I960cfc2f3e8df5342e7248a26fd313fdad2ca322 for the kernel
side changes.
see bug 6023647 for a discussion of the issue.
Change-Id: Ia2f2c399c3d85896ede0fff57ecbd51f332b3e0e
Signed-off-by: John Grossman <johngro@google.com>
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: Ic1548dd43935f45d4efc67f970abdc290a45f715
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
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
Two things: (1) make sure the boot message is always positioned within
the entire unrestricted display, and (2) allow the dim background to go
on top of the nav bar when being used for the boot message (this latter
is really a hack that should be more generally fixed in the future).
Change-Id: I7261b044eb802a39cadff931b50a679ff18781d6
Change clock sync control to velicity form PI loop. Tuned for office LAN and
WiFi conditions, will probably perform better in clean environments.
Improve packet filtering to prevent clock sync on bad rtt.
Changed diag interface to take rtt times, P, I, D are no longer supported.
Change-Id: Id7758262c5f987f07d7091aba6c0874d7c19f387
Backported from master, including a bug fix and a cdma enhancement.
Even if other people are sharing the connection (ie, carrier wants
default and tethered traffic on the same APN) stop using a carrier-
described APN when the tethering stops.
bug:5972599
Change-Id: I25e4831855e6b62c0c3ab3a6f4d4846aaee6ac50
Add a bandaid to prevent a segfault which can occur while handling
timed audio buffers. There is a deeper problem which should
eventually be addressed, but for now this fix should prevent any
crashing.
The deeper problem is as follows.
When the AudioFlinger mixer gets data to mix from an AudioTrack, it
ends up getting a structure filled out which points into an IMemory
region owned by the AudioTrack. Unfortunately, this structure is not
holding a refcount on the IMemory which it points into. If the
IMemory refcount hits 0 and the chunk of RAM is retuned to the binder
heap it came from, there can still be a Buffer object being held by
the AudioFlinger mixer which points into the region of memory which
was retuned to the binfer heap. If AF reads from this buffer, it
could read corrupt data (if the region of memory gets handed back out
to a writer), or it could segfault (if the heap has been freed and the
pages unmapped). Similar problems could happen if AF attempts to
write to the buffer, heap corruption in one case, segfaulting in the
other.
In the past, this has not been an issue for AF, because tracks
allocate a single IMemory (which serves as a ring buffer) and the
IMemory lives for as long as the track lives. As an artifact of the
way the code came out, the mixer cannot be holding a Buffer structure
pointing into the IMemory which used to be owned by a track if the
track no longer exists. Tracks cannot come into or out of existence
during a mix operation, which is the only thing which makes this safe.
TimedTracks work differently, however. Timed tracks each allocate a
small binder heap, and then hand out IMemory instances broken out of
this heap. The heap lives as long as the track, so the worst which
could happen here is that a TimedTrack's IMemory gets returned to the
heap while there is still a buffer structure in flight pointing into
the memory region, then the region gets handed out again and
overwritten by new data causing the mixer to mix the wrong audio. The
timing to cause this to happen is very difficult to encounter, and you
to generate the timing conditions required, you need to be in a pretty
bad failure state where audio is already breaking up and skipping, so
its unlikely that anyone would notice (which is why I'm band-aiding
the segfault and letting the deeper issue slide for now).
In general, however, it might be a good idea to revisit this buffering
design. On principal, if someone is going to hold pointers into a
refcounted object, they should be holding a ref on the object at the
same time. Failure to do this will usually lead to a situation where
there are corruption or segfault issues, or to a system where the
refcounted object's lifetime must be implicitly managed very carefully
in ways which are usually non-obvious and are easy to break by new
engineers on a project.
Change-Id: Ib391075395ed0ef46a03c37aa38a82d09e88abeb
This patch is adding a capability so that OEM can override USB mode
in case the device is boot up with OEM specific mode. (i.e. modem
debug, factory test etc.)
Bug:5964042
Change-Id: Ic8e23d302563ce71eedb74ce94cca8c65838a4f7
Check the string returned by a HAL's implementation of get_parameters
for NULL before attempting to make use of it. That way, we won't
bring down the mediaserver because of a poorly written HAL.
Change-Id: I45f0fd3de003151f98acf32c36c42f58d053f3a0
Fix an issue I discovered while back-porting this code to master. The
common time service was using the MAC address of "eth0" (hardcoded) as
its device ID instead of fetching it from the interface it is
currently bound to. On phones (or any other device with no eth0) this
causes time service to never be able to fetch a device ID as it
should.
Change-Id: Icf8a2006924088efc86065927a648f7f53638657
Change the CCHelper class to be an instanced instead of a static
pattern. The CCHelper instances all share an interface to the common
clock service and register/unregister a callback handler in response
to there being CCHelper instance in the system or not. This brings
usage of the CCHelper into like with the new auto-disable
functionality of the common time service. For any given process,
whenever there are CCHelper instances active, the process will
maintain a callback target to the common clock service and will be
considered to be an active client.
Also change all of the users of the CCHelper interface to manage the
lifecycle of their new CCHelper instances.
Change-Id: I7c28c5d70d9b07ba7407b4ac706e7e7d7253001b
Add a small service to the high level core set of system services to
control the configuration of the native common time service. This
service is responsible for controlling policy regarding when the
common time service should be allowed to run, which networks it is
allowed to run on, what priority it runs at in the master election
algorithm, and so on.
Change-Id: I37308e882a0e8c4cd3e38c4f47b7c40b9150ba31
Major re-factor of the common_time (formally aah_timesrv) service in
preparation for up-integration into Android master. This work
includes bug fixes, new features, and general code cleanup. High
points are listed below.
+ CommonClock interface has been enhanced to allow querying of many
more low level synchronization details; mostly for debugging, but in
theory useful to an application as well.
+ CommonTimeConfig interface has been implemented. This allows a
management process to configure a number of different parameters
(many of them new) to control the behavior of the common_time
service. Most importantly, the time service can be bound to a
specific network interface and should only operate on that interface
an no others.
+ Enhance log messages to be more useful in determining what the time
service state machine is doing and why.
+ Enhance information provided by dumpsys to provide many more details
about the quality of time sync and the network conditions which gave
rise to the current quality conditions.
Features, features, features....
+ Add a feature which lets the high level choose a different master
election endpoint so that multiple time synchronization domains can
co-exist on the same subnet (mostly to support a potential use case
of multiple home domains in a multiple dwelling environment like a
hotel, dormitory or apartment complex).
+ Add a feature which lets the high level assign a 64-bit group ID
which allows partitioning of time synchronization domains even when
the master election endpoint is shared (as it might be if broadcast
is being used instead of multicast)
+ Add an auto-disable feature which lets the time service drop into
network-less mode when there are no active clients of the
common_time service in the device. Mostly for phones, this allows
phones to not consume network/battery resources when they don't need
to maintain common time.
+ Add a feature which lets the high level choose the priority of the
common_time service in the master election protocol. This allows
high level decisions about things like mobile vs non-mobile, wired
ethernet vs WiFi to affect who ends up with the job of master on a
given network. Priority overrides at the low level also allow
clients coming in from network-less mode to lower their effective
priority as they join a new network so as to not disrupt any
stable long-running timeline which may already be active on the
network.
+ Add the ability to control some of the core parameters of the time
sync service which effect network load (like the sync polling
interval and the master announce interval)
Change-Id: I71af15a83cfa5ef0417b406928967fb9e02f55c6
Define a native service interface for configuring and controlling the
common time service. Implement the native marshallers and stub the
implementation of the new interface.
Change-Id: Ia6a6a20ef3d221e8829c55be1dd5f98ed996c610
Add marshallers and stub implementations for new methods in the common
clock interface to support new functionality being added in the
process of integrating the common time service more closely with the
Java level of Android.
Change-Id: Iac2d3fb405d1b64cea1d8e13f988160afb76a06d
Move the State enum up to the ICommonClock interface so it can be
returned for status/debugging up to clients.
Change-Id: I81fef5b96ffc69a4f2e9801b3744feea099ccd47
Bulk name change to remove references to Android@Home from the common time
service in preparation for cleanup and up-integration into the master
branch. Basically, aah_timesrv is now common_time.
Change-Id: I3d3db212f96e8ba171aa36b9c58e27e4a336cb0a
