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
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
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
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
SipURI returns port -1 when port is not present in the URI.
Don't call SipProfile.Builder.setPort() when that happens.
Bug: 3291248
Change-Id: I8e608cbc56ea82862df55fdba885f6a864db83ab
The problem is that when an input stream is opened for record over bluetooth SCO, the kernel
mono audio device should be opened in RW mode to allow further use of this same device by an output stream
also routed to bluetooth SCO.
This does not happen because of a bug in AudioSystem::isBluetoothScoDevice() that does not return true
when the device is DEVICE_IN_BLUETOOTH_SCO_HEADSET (input device for blurtooth SCO).
Change-Id: Ic78bf324b4a68e65721d763dc7682ce7a8f14f75
docs: misc changes;
add path to adb tool in sdk;
fix broken link to ninepatch docs;
fix and add some other links
Change-Id: I27c7284ac2db2e6020c9cb0115fb932a2f503033
