* commit '2a1d19174e32bb6056086ec603948cd476a2ea67':
docs: move USB installation info into the OEM USB Drivers document because the Google USB Driver is deprecated, so consolidating the USB info makes more sense for the common case of needing an OEM driver A few changes to the device setup doc also; such as removing the "unknown sources" step, because that doesn't apply to adb installs.
the Google USB Driver is deprecated, so consolidating the USB info makes more sense
for the common case of needing an OEM driver
A few changes to the device setup doc also; such as removing the "unknown sources"
step, because that doesn't apply to adb installs.
Change-Id: Ice78c997cbb147865ead78fb037d0b6b64db75bd
This is a grotesque hack to avoid showing status bar controls. The real
solution will be coming via master but not extremely soon; stay tuned but
this gives the right presentation for now without affecting normal products.
Bug 5824373
Change-Id: Ib5348024853ad2e7715b824aba522d80b6a99048
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
Since CDMA doesn't use APN settings there was no place to say what a cdma
device's DUN connection would support, so by default normal device
originating traffic would be blocked on a tethering single-connection device.
With this change you can (via overlay) say that it supports everything
so mms and on-device browsing/email will still work even when on a dun connection.
The reason to allow both: some carriers will charge per byte for dun access
and so they don't want lots of non-tethering traffic used (costs the user alot)
but other carriers just use a dun connection to limit access to tethering, but
once there give unlimited data, so it makes sense to support everything there.
bug:5972599
Change-Id: I78fd7f3ac63c51a0560b659ed5ec219b10a93f8d
If config_alwaysUseCdmaRssi is true, the RSSI signal bar only
shows the CDMA value, no matter it connects to EVDO or WiMax .
bug:5941743
Change-Id: I4187571898a9fb47162e1ccf0cc4c59c3136ae0b
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
