selection mode
Fix visibility of menus when action modes are initiailized early.
Fix ListView problems persisting check states.
Change-Id: Idc21036dc39259e72f0e6831a0ccb4695f8858ef
This change moves the Surface ctor that takes a SurfaceTexture to the
portion of the file containing the public APIs.
Change-Id: I192df7bf5c0e6d0d0607bd577d72646312b2f717
the screen
Alter preferred options panel gravity policy.
Integrate new menu panel assets for holo apps.
Change-Id: I9fa98ed9359148ea6d1f1d1e727ddcd437b16e2f
Introduce
setNdefPushMessage()
setNdefPushMessageCallback()
setNdefPushCompleteCallback()
Deprecate public API
enableForegroundNdefPush()
disableForegroundNdefPush()
Hide & Deprecate staged (public but never released) API
enableForegroundNdefPushCallback()
The new API's do not require the application to explicitly call
enable()/disable() in onPause()/onResume(), we use a Fragment behind
the scenes to manager this automatically.
NDEF Push can be disabled by using a null parameter, so each
enable()/disable() pair is collapsed to a single set() call.
Application code should now look something like:
public void onCreate() {
NfcAdapter adapter = NfcAdapter.getDefaultAdapter(this);
if (adapter != null) { // check that NFC is available on this device
adapter.setNdefPushMessage(myNdefMessage, this);
}
}
And that's it - no need to explicitly hook into onPause() and onResume() events.
Also - introduce a generic NfcEvent class that is provided as a parameter on
all NFC callbacks. Right now it just provides the NfcAdapter, but using
the wrapper classes allows us to add more fields later without changing
the callback signature. (i'm thinking Bluetooth).
Change-Id: I371dcb026b535b8199225c1262eca64ce644458a
A recent fix for invalidation noop'd calls to invalidate() on
GONE/INVISIBLE views. This logic also noop'd views which might
be GONE, but which are in the process of fading in/out via
LayoutTransition animations. These views should invalidate as
usual.
Change-Id: Ie90a340f70290391a3aa4e68df535c6aabf4e5eb
If the native-side bookkeeping still has strong references to VM-side
DeathRecipient objects at the time when it's being torn down, that
suggests that the app is doing unwholesome. Log a warning to that
effect, with the class name of the objects to try to help the developer
figure out what they're mishandling.
Fixes bug 5202777 -- in particular, it no longer logs in the
working-as-intended case following delivery of the death notices,
when we've got the existing list shell but the weak refs have properly
cleared. Also step down from "error" to "warning" logging as befits
the nature of the actual situation now being described.
This new patch fixes the JNI bug present in the earlier version.
Change-Id: I095862777a8d0e3905cb7f416af658878280041d
When reading network counters, always splice in xt_qtaguid values
to avoid counting backwards. Test to verify.
Remove verbose logging around global alerts, and add dumpsys debug
info for NMS and MDST. Also fix subtle bug around stats persisting
and dumping.
Bug: 5212893, 5211028
Change-Id: I783e5286637a67ee2dd2b09878198711a926d0cb
- Add methods to TelephonyManager to provide access to IMS records on
the ISIM application of the UICC, as well as access to the ISIM
AKA authentication algorithm.
- Add support for the new IMS methods to CDMALTEPhone, using the helper class
ImsUiccRecords to load the IMS records from the ISIM. The same approach
can be used to implement IMS support for UMTS/LTE devices.
- There is a new RIL request, RIL_REQUEST_ISIM_AUTHENTICATION, which is
used to perform IMS AKA authentication using the algorithm on the ISIM
application of the UICC. The challenge nonce and response are both encoded
as Base64 strings.
Change-Id: I73367c7d9bc573d0d883d68adf09891de1319129
- Space was truncated on 'disabled' notification
- Disable reason was getting wiped out on subsequent disabled
- disable reason was not propogating to WifiSettings
Change-Id: I2e57ee33d285aad39aabe1b048e7436d364b02f3
For each synthesis request, we inspect the number of
bytes of audio that have not been written to the mixer yet
and if that is above a certain threshold (currently 500ms),
we block the synthesis thread.
bug:5214603
Change-Id: I24c64c48466bdb96ce47b34cee7da2523ee5f0eb
