The cause of the problem is that AudioTrack::start() can fail if it is called from a newly created
thread that has the same ID as the AudioTrack callback thread that has just been stopped and not yet exited.
This is possible as the thread ID used by the Thread class is not the TID.
The fix consists in clearing the thread ID before exiting the thread loop.
Change-Id: I66e679665c384403cb3ba2c31746f5de72d5836d
Originally a stream does not send packets when it is receive-only or there is
nothing to mix. However, this causes some problems with certain firewalls and
proxies. A firewall might remove a port mapping when there is no outgoing
packet for a preiod of time, and a proxy might wait for incoming packets from
both sides before start forwarding. To solve these problems, we send out a
silence packet on the stream for every second. It should be good enough to
keep the stream alive with relatively low resources.
Bug: 3119690
Change-Id: Ib9c55e5dddfba28928bd9b376832b68bda24c0e4
The wakelock will be kept held if there is outstanding requests
in request list. When WAKE_LOCK_TIMEOUT occurs, all requests
in mRequestList already waited at least DEFAULT_WAKE_LOCK_TIMEOUT
but no response. Those lost requests return GENERIC_FAILURE and
request list is cleared.
bug:3292426
Change-Id: I369c6ba4d6836d65ef616140e48c7304faf888f0
ServiceRecord's bindings is a hashmap to keep track of all active
bindings to the service. This is not cleared when the service is
brought down by activity manager. This adds up the references to
IntentBindRecords and its references to ServiceRecord. Fix is to
clear the bindings.
ServiceRecord's restarter is a reference to the service and is not
cleared when the service is brought down by activity manager. This
adds up the references to ServiceRecord. Fix is to set the reference
to null when the service is brought down by activity manager.
Change-Id: Ica448cd5f60192c8adb23209b5d0e2cf0c04e446
...current process has android.permission.WAKE_LOCK
When updating a system app, we would actually uninstall the package
of the system app, which also meant removing its uid...! It was just
luck that we would get the same uid when installing the update after
that. During that time, if anyone tried to do anything related to
that uid, it would be unknown.
This change tweaks how we go about replacing system apps by making
it more like normal apps -- to make this work, if we need to disable
the system app, we generate a new PackageSetting from the current
system app and replace it into our data structures, so we can update
that without trashing the current correct information about the (still
actually there) system app.
Also fixed a problem where we were not killing the currently running
app before installing, like we do when updating a normal application.
And fixed a problem where we were not deleting the /data .apk when
uninstalling a system app update.
And added a new option to the "pm" command to clear the data associated
with an app.
Change-Id: I0e879677849aa42950a3c360bf78ad820e87674b
Rewrote interceptKeyBeforeQueueing to make the handling more systematic.
Behavior should be identical except:
- We never pass keys to applications when the screen is off and the keyguard
is not showing (the proximity sensor turned off the screen).
Previously we passed all non-wake keys through in this case which
caused a bug on Crespo where the screen would come back on if a soft key
was held at the time of power off because the resulting key up event
would sneak in just before the keyguard was shown. It would then be
passed through to the dispatcher which would poke user activity and
wake up the screen.
- We propagate the key flags when broadcasting media keys which
ensures that recipients can tell when the key is canceled.
- We ignore endcall or power if canceled (shouldn't happen anyways).
Changed the input dispatcher to not poke user activity for canceled
events since they are synthetic and should not wake the device.
Changed the lock screen so that it does not poke the wake lock when the
grab handle is released. This fixes a bug where the screen would come
back on immediately if the power went off while the user was holding
one of the grab handles because the sliding tab would receive an up
event after screen turned off and release the grab handles.
Bug: 3144874
Change-Id: Iebb91e10592b4ef2de4b1dd3a2e1e4254aacb697
Allow a non-epidited ignore-backoff op to pass through
an expidited backed off op.
To do this, I first refactored the complicated if statement:
if (best == null
|| ((bestSyncableIsUnknownAndNotARetry == syncableIsUnknownAndNotARetry)
? (best.expedited == op.expedited
? opRunTime < bestRunTime
: op.expedited)
: syncableIsUnknownAndNotARetry)) {
best = op;
bestSyncableIsUnknownAndNotARetry = syncableIsUnknownAndNotARetry;
bestRunTime = opRunTime;
}
Into a more readable:
boolean setBest = false;
if (best == null) {
setBest = true;
} else if (bestSyncableIsUnknownAndNotARetry == syncableIsUnknownAndNotARetry) {
if (best.expedited == op.expedited) {
if (opRunTime < bestRunTime) {
// if both have same level, earlier time wins
setBest = true;
}
} else {
if (op.expedited) {
setBest = true;
}
}
} else {
if (syncableIsUnknownAndNotARetry) {
setBest = true;
}
}
if (setBest) {
best = op;
bestSyncableIsUnknownAndNotARetry = syncableIsUnknownAndNotARetry;
bestRunTime = opRunTime;
}
The refactoring was all done automatically with IntelliJ to avoid human error
in the conversion.
After verifying this code still behaved as expected including the error
condition in the bug, I added handling for the cases when a non-expidited op
may override an expedited op if certain conditions occur, specificaly, if the
expidited op is backed off and the non-expidited op is not.
Finally, refactored to make it testable and added tests and logging.
Bug: 3128963
Change-Id: I131cbcec6073ea5fe425f6b5aa88ca56c02b6598
This fix improves the performance by caching the string that should
be returned, and reuse it next time if possible.
This will make it faster to switch between activities, approximately
half the time to create the new view when changing from landscape to
portrait. Also, the time for starting a new application is be reduced
as WindowState.toString is being called thousands of times in this
case.
Change-Id: I2b8b9bc1e251d1af43b6c85f049c01452f2573a2
It's not easy to determine if this
is possible, so instead apps should
attempt a format and handle errors
in the format request.
Change-Id: I078a208b849e71ef3fb6b5970a9111ece4a2d201
This removes the empty iTxt meta tags in png which are not supported by
Java 1.5. This script should be run every time the SDK is released.
Bug 3069421
Change-Id: I1610e52597937040f9da343046cd98aa075f728d
Reports that we sometimes didn't report NO_CONNECTIVITY led to this suggested change.
Could not repro the problem, but the change looks ok anyway. Better safe than sorry.
bug:3276408
Change-Id: I0cdb48a05a5c9dfcf3a0b468a6eae43d461023b1
This is to make SipManager.isVoipSupported() effective.
Also add NPE check now that we may return null SipAudioCall when VOIP is not
supported.
Bug: 3251016
Change-Id: Icd551123499f55eef190743b90980922893c4a13
reviewed for Froyo, but we didn't want to make it
public then because it wasn't until our first
Market release of Voice Search that the APIs would
be in use by our app.
http://b/3135351
Change-Id: I49053717cac08e3976c22e3a105139b6755aadb8
- It's useful to have accessors at block level, so apps don't really have to know
about the sector structure (and how many blocks there are in a sector).
- There's no way to tell whether a read/write/ didn't work because of auth
failure. The documentation should be changed to make this point clear.
- Added increment/decrement commands, for atomic increment/decrement of value blocks.
Change-Id: I590feacbcd1443f1be7a86ab046a5b1f33e2e04c
