This change fixes an issue involving buffer reallocation and the
ALLOW_DEQUEUE_CURRENT_BUFFER mode in SurfaceTexture. The bug happened
when the buffer slot currently attached to the GL texture was selected
for dequeuing, but the dequeue operation caused the buffer to be
reallocated. Because the buffer is new, the image producer could fill
the buffer and queue it before an updateTexImage call, which would
result in the "slot %d is current" error in queueBuffer.
Bug: 5631630
Change-Id: Icdd8bc5cad3c7db43953446d9be2603aaea11a8d
CallerInfo.doSecondaryLookupIfNecessary() was assuming that SIP addresses
would always contain the character '@', but that's not always true since
the username/domainname delimiter can actually be "%40" (the URI-escaped
equivalent.)
This would cause the in-call UI to crash if you ever called a SIP address
like "xyz%40example.com".
TESTED:
- Make an outgoing call to the SIP address "xyz%40example.com"
==> The call ultimately fails, but the in-call UI no longer crashes when
it first comes up.
Bug: 5637074
Change-Id: I62d15a7ccd509924d38b780b92e657b9efa26125
* commit '08d40d71806d482fa92f6a9b952487c3ccc63bb3':
docs: Big update to action bar guide for ICS. Added section for action provider, new APIs for handsets such as split action bar, more information and diagrams for up navigation, guidelines for picking action items, revised sample code and discussion for tabs, add expandible action view info, and expanded discussion for customizing action bar styles bug:4726917
* commit '4750cbd9311b763265f8ab6ddee187e0c9a71665':
DO NOT MERGE: Bluetooth HDP sample. Cherry pick from ics-mr1 Change ID I7035cb13da6f6cd64e63df8a5ccf2391fe41f18e
Added ObjectGc and FinalizingGc to stress single-object allocation and
collection with/without the presence of finalizers.
Also added GcOp() to the menu of available single-shot tests.
Change-Id: I36d3254dfe2e97e504f9e4f77c8addda98ab4f4b
The window manager now monitors the plug state; the screen
saver will never be automatically started if the device is
running off battery.
Change-Id: Ib1064d9cdd540238957df3ba7020303b0f6943c2
vril-dump was causing adb bugreport to hang on Xoom. The OEM fixed
the utility and we can now run it again as part of the bug report.
Bug: 5482585
Change-Id: I1db3b50c327d50d18fb9c6327c4cd521e09f3916
Added section for action provider, new APIs for handsets such as
split action bar, more information and diagrams for up navigation,
guidelines for picking action items, revised sample code and discussion
for tabs, add expandible action view info,
and expanded discussion for customizing action bar styles
bug:4726917
Change-Id: If61a5f2aad5ed21b0b23b3fc14309a50617f86ce
Bug 5342918
The content rect of the WebView was being retrieved during
the draw while the viewport rect was being set when the
draw functor was setup. During animations, the content
rect was changing between the time the draw functor was
retrieved and it was executed. The content rect is now
being set with the viewport rect.
Wekbkit Change: I05d68dcc
Change-Id: I1b0978eeb27d9f1deddfeba3ede869f735f74394
This change updates isEmergencyNumberInternal() to always return false if
you pass in a SIP address, since the concept of "emergency numbers" is
only meaningful for calls placed over the cell network.
Previously we *did* try to compare SIP addresses against the list of known
emergency numbers, which caused bad behavior with SIP addresses that even
contained "911"/"112"/etc as a substring (since we were filtering out
non-dialable characters before doing the comparison!)
TESTED:
- Before this change, calls to "abc911def@example.com" or
"911abcdef@example.com" were incorrectly detected as emergency
numbers, and fail.
- After this change, SIP addresses like "abc911def@example.com" and
"911abcdef@example.com" work fine.
- Also, confirmed that this change doesn't break the restriction that
3rd party apps shouldn't be able to make emergency calls.
Specifically, I fired off ACTION_CALL intents (using the CallDialTest
activity) for a bunch of numbers *similar* to emergency numbers, and
confirmed that none of them actually resulted in an emergency call
being placed.
The specific ACTION_CALL intents I tested were:
"911" ==> Didn't place the call; brought up dialer instead
"tel:911" ==> Didn't place the call; brought up dialer instead
"911@foo" ==> Tried to start a SIP call (which failed)
"911%40foo" ==> Tried to start a SIP call (which failed)
"tel:911@foo" ==> Tried to start a SIP call (which failed)
"tel:911%40foo" ==> Tried to start a SIP call (which failed)
"911@example.com" ==> Tried to start a SIP call (which failed)
"sip:911" ==> Didn't place the call; brought up dialer instead
"sip:911@foo" ==> Tried to start a SIP call (which failed)
"sip:911%40foo" ==> Tried to start a SIP call (which failed)
Bug: 5515452
Change-Id: I6f9f8690b08564c53c7a76f480654477b475d94d
