Bug #3458256
If an error occurs and simultaneously user cancels the recognition, here is what happens:
1. dispatchCancel() is called since the user requested cancel. It passes the first "if" successfully.
private void dispatchCancel(IRecognitionListener listener) {
if (mCurrentCallback == null) {
if (DBG) Log.d(TAG, "cancel called with no preceding startListening - ignoring");
} else if (mCurrentCallback.mListener.asBinder() != listener.asBinder()) {
Log.w(TAG, "cancel called by client who did not call startListening - ignoring");
} else { // the correct state
RecognitionService.this.onCancel(mCurrentCallback);
mCurrentCallback = null;
if (DBG) Log.d(TAG, "canceling - setting mCurrentCallback to null");
}
}
2. Error occurs in the app, which sets the mCurrentCallback to null:
public void error(int error) throws RemoteException {
mCurrentCallback = null;
mListener.onError(error);
}
3. the second "if" is reached in dispatchCancel()
4. boom
Change-Id: I54cdcc98b495d820a2caead1709d8dee968c461e
* commit 'db52ab69f22e24615eaa2e8f9845e157426d3dd6':
DO NOT MERGE Backport (with modifications ) some changes from Honeycomb, that would allow authenticators to control caching and permissions.
Backport (with modifications ) some changes from Honeycomb, that would allow authenticators to control caching and permissions.
This is backward compatible - both new and old authenticators will work with old and new framework,
but the functionality will only be present if both sides support it.
Change-Id: Ib2838cc2159f45264b38c844cd4c1d6f315d8064
1. Database changes:
- Add a protocol and a roaming_protocol column to the
carriers table in the telephony provider database.
- Set the protocol and roaming_protocol fields when
creating APN objects from the database.
2. ApnSetting class changes:
- Add protocol and roamingProtocol fields to the
ApnSetting class that encapsulates APN settings within
the framework.
- Add the fields to ApnSetting.toString and support a new
syntax containing the fields in ApnSetting.fromString.
- Add a unit test for ApnSetting.
3. Telephony changes:
- Specify the APN protocol when setting up a data call,
using protocol when not roaming and roaming_protocol
when roaming.
This change depends on #86896 in the telephony provider,
which adds the new column to the database schema on
upgrades.
Bug: 3333633
Change-Id: If3d9ed4c851d0192849df0d64581db03b066e052
Backport the protocol changes to setupDataCall and its
callers from master. As in master, hardcode IPv4
connectivity for now. When we add the protocol field to
ApnSettings, it will be fetched from there.
Bug: 3333633
Change-Id: I51880bc0ec192cbf964ac7bbd6a4b7d2eed41d27
* commit '6504490cde3ec5d48321d539e654d1f2072b33f9':
GpsLocationProvider: Clean up HAL initialization/cleanup sequence
Fixed GSM encoded network initiated position request
Ensuring thread-safe usage of DateFormat.
Fixing infinite loop for zero duration.
Fix for an infinite loop while scrolling lists.
WAPPushManager, WAP Push over SMS message handler
Add --non-constant-id to aapt.
* commit 'dff6b8e71dda9f5d841fa26408714aec2aef1505':
GpsLocationProvider: Clean up HAL initialization/cleanup sequence
Fixed GSM encoded network initiated position request
Ensuring thread-safe usage of DateFormat.
Fixing infinite loop for zero duration.
Fix for an infinite loop while scrolling lists.
WAPPushManager, WAP Push over SMS message handler
Add --non-constant-id to aapt.
DigitalClock could sometimes leak when the keylock was recreated.
This happened because onDetachedFromWindow() was called BEFORE
onAttachedFromWindow().
This is the flow that causes the memory leak:
1) The LockPatternKeyGuardView is created and added. This will start
a loop dispatching onAttachedToWindow() to all views involved.
2) PatternUnlockScreen.onAttachedToWindow() is called
3) If the configuration has changed since creation, recreateMe() in
LockPatternKeyguardView.java is called.
4) recreateScreens() is called
5) PatternUnlockScreen is removed (to be re-added later) in
LockPatternKeyguardView.recreateUnlockScreen()
6) Since DigitalClock is a part of PatternUnlockScreen, its
onDetachedFromWindow() will be called.
7) The loop started in 1) will continue to dispatch
onAttachedToWindow() - and will eventually call
DigitalClock.onAttachedToWindow()
8) DigitalClock.onAttachedToWindow() registers a receiver that is
normally unregistered in onDetachedFromWindow(). But since
onDetachedFromWindow was already called in 6), it will not be called
again.
9) The receiver has leaked, and it has a reference to DigitalClock,
so that will leak as well, together with its parents e.g.
PatternUnlockScreen and LockPatternKeyguardView
The fix is to wait with the recreation of the screens (in 4) until
the loop (in 1) is finished. This is done by posting this as an event
instead of calling recreateScreens() immediately.
It is possible that this a fix for the root cause mentioned in
"Fix 3106227: use WeakReferences for receivers in DigitalClock class"
8b886fab5496b0b1f5193f21855220176deddc37 by Jim Miller
<jaggies@google.com>.
Change-Id: I6a5f6f49a565d459bf4e285f34f053cc1022286f
This removes a stack trace message during the boot under emulation.
The observers tried to access a null reference when no USB configuration
is supported by the emulated device. So do not start them in this case.
+ Change a Slog.w into a Slog.i since this is an acceptable condition.
Change-Id: I801f352574716d7868f182bb6e5ee49e5b12e4f1
Add support for separate USB connected and configuration events
Include both USB connected/disconnected and configuration state
in USB_STATE Intent
Remove redundant USB_CONNECTED and USB_DISCONNECTED Intents
Now we just have the sticky USB_STATE broadcast
Move USB disconnnect rebouncing from Tethering to UsbService
Change-Id: I1dea480f4b0daf14247cf37c5f2060498882c002
Signed-off-by: Mike Lockwood <lockwood@android.com>
USB: Add functions for querying if a USB function is supported and enabled.
Rename android.hardware.Usb to UsbManager and UsbObserver to UsbService
Change-Id: I920a211934d993eab8ce744c1cc7b05342389286
Signed-off-by: Mike Lockwood <lockwood@android.com>
'*86' which is set now as a default at CDMAPhone.java,
is default voicemail number for Verizon.
For Sprint, we use user's own number for voicemail.
So we add codes in CDMAPhone.java to use
'config_telephony_use_own_number_for_voicemail',
and use config.xml to set this value as false.
Then we overlay Sprint's own config.xml file to
override 'config_telephony_use_own_number_for_voicemail' as a true.
Change-Id: I110914bdfa9a79aaba89d3b80edbcf044e9aabee
The ICU CLDR data doesn't use the month abbreviations that are
appropriate for the DatePicker, so use the framework copy of the CLDR
data.
Bug: 2641810
Note: cherry-picked from Honeycomb
Change-Id: I3c045dbfb751b8b7ce6361b5a67407206fc64db1
