This is tricky: entry.getMessageBox() returns int, so it is
by default boxed to Integer. Map.get() however accepts Objects,
so it ignores the difference, but nothing is find during lookup,
just because Long and Integer objects are compared using equals(),
which has to lead to 'false' result. So, explicit boxning to Long
is unnecessary here.
Change-Id: I967a7829a8926410a00274c6b5e312e1af567299
* commit '611af238185cf924a425a1a2154b8439b8f8d7a5':
DO NOT MERGE: UsbManager: Don't display activity picker if there are no apps available for an accessory
This provides a mechanism for developing applications to work with
USB accessories in versions of android prior to the introduction
of the android.hardware.UsbManager APIs.
Applications should link against the com.android.future.usb.accessory
library to use this support.
Change-Id: I0b61e20b63eec42c506f0895a0c9a439bdfdf7f5
Signed-off-by: Mike Lockwood <lockwood@android.com>
* 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
