Tooltips are already being shown on long press. This CL
invokes the same logic on mouse hover (but with a longer
tooltip duration).
Bug: 24339237
Change-Id: Icba33b317fe737953c6dace91cfe3539a14a1959
We don't need to set up JIT profiles and register usage etc when
the package context we're trying to construct doesn't request code.
This will correct accounting for packages which are only used for
resources.
bug: 28519185
Change-Id: I849675efa76c8100ae937de478b52254babe384c
This is a follow-up to my previous CL [1] for Bug 15922840 so that we
can clear the following variables in a more reliable way.
- PhoneWindowManager#mLastInputMethodWindow
- PhoneWindowManager#mLastInputMethodTargetWindow
The idea behind CL [2] is that when InputMethodManagerService (IMMS) is
switching from an IME to another IME, IMMS can send a signal to
WindowManagerService (WMS) to remember the current IME's inset so that
the system can continue using it to reduce jank until the new inset is
specified by the next IME. As summarized in Bug 28781358, however, if
the next IME does not show the window after the IME switch, WMS (or
PhoneWindowManager to be precise) keeps using the previous IME's inset
unexpectedly until the new IME shows its window. All we have seen in
Bug 15922840 and Bug 26663589 fall into this category.
The idea of this CL is just adding a hidden API to InputMethodManager so
that InputMethodService#clearInsetOfPreviousIme() can surely terminate
the IME transition state managed in PhoneWindowManager, rather than
relying on a hack of calling SoftInputWindow#show() and
SoftInputWindow#hide(), which actually does not work for Bug 26663589.
[1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
Note that addressing all the corner cases in [2] still requires lots of
non-trivial change. Hence this CL focuses only on Bug 26663589 (and
the case we handled in Bug 15922840).
Bug: 26663589
Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
am: 057a101453
* commit '057a101453ea46a6207588b53952d78c2a80898c':
Add an Activity action to go into the Deletion Helper.
Change-Id: I1f823bcdde7b48f37bfe9016ba68bbc3c27a4357
am: e8ed2ed331
* commit 'e8ed2ed331a056fe2262ac649f71d781df25f363':
Add an Activity action to go into the Deletion Helper.
Change-Id: I09b09f645b455c8a2cde7bd0eadb34b2cc704178
Applications may want to jump to the Deletion Helper to free up
storage when the device is under storage pressure.
Bug: 28675265
Change-Id: I709c39f3e699ab5f51f4ad1272468583276ff050
Added the following APIs to the framework:
VoicemailContracts.ACTION_VOICEMAIL_SMS_RECEIVED
VoicemailContracts.EXTRA_VOICEMAIL_SMS_TYPE
VoicemailContracts.EXTRA_VOICEMAIL_SMS_DATA
VoicemailContracts.EXTRA_VOICEMAIL_SMS_SUBID
TelphonyManager.setVisualVoicemailSmsFilterEnabled()
TelphonyManager.isVisualVoicemailSmsFilterEnabled()
TelphonyManager.setVisualVoicemailSmsFilterPrefix()
TelphonyManager.getVisualVoicemailSmsFilterPrefix()
TelphonyManager.setVisualVoicemailSmsFilterOriginatingNumbers()
TelphonyManager.getVisualVoicemailSmsFilterOriginatingNumbers()
TelphonyManager.setVisualVoicemailSmsFilterDestinationPort()
TelphonyManager.getVisualVoicemailSmsFilterDestinationPort()
TelphonyManager.VVM_SMS_FILTER_DESTINATION_PORT_ANY
TelphonyManager.VVM_SMS_FILTER_DESTINATION_PORT_DATA_SMS
These values are required to implement the VisualVoicemailSmsFilter in
frameworks/opt/telephony
All of the APIs are hidden.
Bug:27816386
Bug:27817303
Change-Id: I07736785da5fece84d1f3d27f270ac6fa94c1c56
Netlink notifications about the state of the modem contains uid too.
This patch adds the functionality to add that. It also fixes the bug to
parse the timestamp in the message even in cases where the length is
greater than expected.
Bug: 28527904
Change-Id: I4643bff3eb5b1ffa2dc0b78f1c6947d60487e0d8
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
am: 3882169d7f
* commit '3882169d7f43e011ad77adb05aca2e5d6175c7f0':
docs: Updates to multi-window and related docs.
Change-Id: Ief8906a4c0e57229b433c4e89c23990d957a4014
Settings is using a MemoryIntArray to communicate the settings table
version enabling apps to have up-to-date local caches. However, ashmem
allows an arbitrary process with a handle to the fd (even in read only
mode) to unpin the memory which can then be garbage collected. Here we
make this mechanism fault tolerant against bad apps unpinning the ashmem
region. First, we no longer unpin the ashmem on the client side and if
the ashmem region is purged and cannot be pinned we recreate it and
hook up again with the local app caches. The change also adds a test
that clients can only read while owner can read/write.
bug:28764789
Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
am: 0b15a5c94f
* commit '0b15a5c94f48eb6c31fefba2c0efb74f542cc66d':
docs: Updates to multi-window and related docs.
Change-Id: Id40a1c06b5a12c02ee26b855ec7c813abac8e554
am: f975b74c0c
* commit 'f975b74c0c60160092262fbc05f42f7e2584f0bd':
docs: Updates to multi-window and related docs.
Change-Id: Ia7b8adbe3140a59d2e2433b3795e58a16763527c
