- We should be checking the actual launched-from package since that stores
the source package across trampoline activities
Bug: 35458117
Test: Enter PiP from a trampoline activity, launch again from Launcher
and ensure that it is expanded
Change-Id: Ia0e586e8b21dee63b513bd61a41a24e7da4325e1
This new command is used to attach runtime agents to a running application:
attach-agent <PROCESS> <FILE>
Attach an agent to the specified <PROCESS>,
which may be either a process name or a PID.
Test: m test-art-host, manual testing:
. invalid syntax, missing arguments
. invalid syntax, extra arguments
. invalid numeric PID
. invalid process name
. valid process, not debuggable
. valid process, missing agent
. valid process, valid agent
Bug: 31682382
Change-Id: I61cc8bf20addb1702acc8e7aae65b2f9ed7c5ca0
Merged-In: Ife88dbf23991dde7945d9208e54cd014bb7ecdc6
Currently the icon defined by the host AbsListView is displayed
over the fast scroll area.
Bug: 35424111
Test: manual
Change-Id: Ia9897a44550922f16573b97337841c3f6ae263da
The request network with timeout was originally created with a
check of max timeout against a constant of 100 minutes. However,
the API was not public and did not implement a timeout. Any users
were internal and never got any onUnavailable() callback (since
timeout never triggered).
There is no reason to have a max timeout so the constant is
remove.
Bug: 31399536
Test: unit tests and CTS of ConnectivityManager
Change-Id: Icbedfb4299d75b6a7e3e43720111531f1faafd06
This is a follow up CL to my previous CL [1], which caused an unexpected
side effect that leads the current IME to crash due to a too strict
requiremnt.
It turns out that it was too early for us to start requiring non-null
StartInputToken in InputMethodManagerService#setImeWindowStatus()
because in many places we have assumed that an IME can show/hide its
software keyboard even before an IME target window is associated with
the IME.
There are two major cases that we missed:
- InputMethodManager#showSoftInputFromInputMethod(IBinder, int):
This method does not require that the calling IME is already bound
to an IME target window.
- InputMethodManager#showSoftInputUnchecked(int ,ResultReceiver):
This @hide method allows the caller application to let current IME
show the software keyboard with bypassing all the normal focus
management tasks in InputMethodManager. We should seriously
consider to deprecate this @hide method, but to do that we have to
clean up some internal components and SearchView in the support
library that still rely on this method.
Bug 35395372 is triggered by the second scenario, but until we sort out
all the possible corner cases, we should allow null startInputToken as a
valid request, like we had have done so before the CL [1] introduced
such a validation.
[1]: I9921b381e02106dbffff5e0b3d13f0a1245ce807
6db3bfe33d
Test: Made sure Bug 35395372 is no longer reproducible, that is,
1. Flash a new image and complete the setup wizard on a
direct-boot unaware device.
2. Set a device password and require it upon each device boot.
3. adb reboot
4. Observe the default IME does not crash because of
InvalidParameterException thrown by IMMS.
Test: Made sure IMM#showSoftInputFromInputMethod(IBinder, int) does
not throw an InvalidParameterException even in an extreme case.
1. Rebuild LatinIME with the following code in LatinIME.java
@Override
public AbstractInputMethodImpl onCreateInputMethodInterface() {
return new InputMethodService.InputMethodImpl() {
@Override
public void attachToken(IBinder token) {
super.attachToken(token);
final InputMethodManager imm =
getSystemService(InputMethodManager.class);
final IBinder imeToken =
getWindow().getWindow().getAttributes().token;
imm.showSoftInputFromInputMethod(imeToken, 0);
}
};
}
2. adb install -r LatinIME.apk
3. adb shell ime enable com.android.inputmethod.latin/.LatinIME
4. adb shell ime set com.android.inputmethod.latin/.LatinIME
5. Tap any text field.
4. Observe LatinIME does not crash because of
InvalidParameterException thrown by IMMS.
Bug: 34628091
Bug: 35079353
Fixes: 35395372
Change-Id: Ib9448c551d9a30776a999c27a5ff20f1a095633a
Companion apps can declare they want background access and
background execution exceptions via dedicated permissions
in their manifest. If such a permission is requested we
auto-grant the corresponding exception after the user has
chosen a device from the companion UI. These permissions
are appop ones allowing us to use the app ops for gauging
whether the user has made a change after we auto-granted
the permission since we would like to revoke these special
privileges when the app disassociates itself from the
companion device if the user did not make an excplicit
choice otherwise.
While at this auto-grant fixed location permission to the
companion device discovery service.
Test: manual
Change-Id: I46ee4291e5e5a8f7613f0dd75eb61d6b9341f306
