If a normal app does not have launcher icon, launcher api
will return app details activity instead, so user will
be noticed that the app is still installed.
Bug: 111348460
Test: Installed an app without launcher activity, an app icon is being
shown in launcher allapps, and it forwards user to app details page.
Change-Id: I9c17f5edfdefe19727145e7176d7e113286c997d
1. We now apply smart replies to the first action button that has
(freeform) remote input. For example, if the notification have
both reply and reply all buttons, smart replies will be applied
to the first button only.
2. Enforced getAllowGeneratedReplies check in system generated
smart replies.
3. Fixed an bug that smartRepliesAdded is not called for system
generated smart replies.
BUG: 111546109
BUG: 111406942
Test: atest com.android.server.notification.NotificationTest
Test: Check apps generated smart replies via Messenger
Test: Check system generated smart replies via Hangouts
Change-Id: I4db34f557f7e9988be612e4162347b86393d1faf
This requires RestrictedLockUtils to change which then causes further
changes.
I left the old APIs available for non-system-api customers.
Test: RunSettingsLibRoboTests
Bug: 116798569
Change-Id: Id5384ee074bb245e615012b7e0d5298b8bf27ba4
This covers directories through /app.
removed unused import in KeyguardManager.java
Test: make ds-docs
Bug: 117494359
Change-Id: Ie2536676ae8d3ab9349aa43dc3e3248b618dd143
Exempt-From-Owner-Approval: Docs-only change
InputMethodManager has been a per-process singleton object. In order
to support behavior changes for multi-display support in Android Q,
however, InputMethodManager now needs to be per-display objects.
With this CL, context.getSystemService(InputMethodManager.class) will
start returning per-display InputMethodManager (IMM) instance.
Why?
There are two major reasons.
1. To support per-display focused window.
2. To support more simplified API for multi-session IME.
Currently per-process InputMethodManager instance directly receives
callback from ViewRootImpl upon windowFocusChanged, then it keeps
track of which Window is focused by storing its root view into
InputMethodManager#mCurRootView.
This design assumes that (within the same process) at most one Window
can have window focus, which is no longer true once we start
supporting per-display focused window (Bug 111361570).
Why we need to do this to support per-display focused window:
For traditional non multi-session IME cases (e.g. apps that use
Virtual Display APIs on phones), internal state of IMM can be easily
messed up once the system starts sending per-display
windowFocusChanged events to the same process, because IMM still
doesn't know that now each display has focused window. It is hard to
precisely predict what kind of issues we would see simply because such
a use case is most likely not expected in the original design.
Why we need to do this for multi-session IME:
For multi-session IME scenarios, in addition to the above concern in
InputMethodManager, the current design allows at most one IME session
per process. This means that if a process X is showing Activities to 3
different displays, only one Activity can interact with the
multi-session IME at the same time. If we do not change the current
design, the only way to work around is to ask app developers to
explicitly use different processes for each Activity, which may
require a lot of work (e.g. SharedPreference is not optimized for
multi-process use cases). This would also make multi-session IME
development complicated because the IME cannot know on which display
the IME is interacting until startInputOrWindowGainedFocus() is
actually called, and needs to do all the preparation and cleanup tasks
whenever startInputOrWindowGainedFocus() is called for a different
display than it's currently interacting with.
Alternative solutions considered:
Another possible approach is to update InputMethodManager singleton to
be able to maintain multiple mCurRootView and mServedView for each
display. This approach was abandoned because those fields and methods
are already marked as @UnsupportedAppUsage. I concluded that touching
@UnsupportedAppUsage things would have bigger compatibility risks than
per-display instance model.
Implementation note:
* Public APIs in IMM that take View instance as the first parameter
will verify whether the given View and IMM are associated with the
same display ID or not. If there is a display ID mismatch, such an
API call will be automatically forwarded to the correct IMM instance
IMM with a clear warning in logcat which tells that app developers
should use the correct IMM instance to avoid unnecessary performance
overhead.
* As a general rule, system server process cannot trust display ID
reported from applications. In order to enable IMMS to verify the
reported display ID, this CL also exposes display ID verification
logic from WMS to other system components via WindowManagerInternal.
* isInputMethodClientFocus() in WindowManagerService (WMS) is updated
to use top-focused-display to determine whether a given IME client
has IME focus or not. This is now necessary because with a recent
change [1] each display can have focused window. The previous logic
to check all the displays that belong to the given pid/uid [2] no
longer makes sense.
* Currently per-display InputMethodManager instances will not be
garbage collected because InputMethodManager#sInstanceMap keeps
holding strong references to them. Freeing those instances is
technically possible, but we need to be careful because multiple
processes (app, system, IME) are involved and at least system
process has a strict verification logic that lets the calling
process crash with SecurityException. We need to carefully
implement such a cleanup logic to avoid random process crash due to
race condition. Bug 116699479 will take care of this task.
[1]: I776cabaeaf41ff4240f504fb1430d3e40892023d
1e5b10a217
[2]: I8da315936caebdc8b2c16cff4e24192c06743251
90120a8b5b
Bug: 111364446
Fix: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: I7242e765426353672823fcc8277f20ac361930d7
The way we were checking Settings was invoking a 2ms hit.
Move ANGLE_ENABLED_APP to CoreSettings, which are already
available to the ActivityThread, eliminating the hit.
Test: Verify developer option works as expected
Test: atest google/perf/app-startup/benchmark-app-hermetic/cold-dropcache-test
Bug: 117107368
Bug: 80239516
Change-Id: I3df4c3c43489a338b3631484a8811b38c4eff2e6
Several java files had the typo {#link (for cross-references to other
Javadocs) instead of the proper {@link format. This was confusing the
new doc publish tool (Mivi) since that's the format used for {# Django
comments #}.
Fixed a couple of links that had other errors (which prevented building
once the {# -> {@ was done) and other typos.
Replaced throughout the frameworks/base project; I'll need a separate CL
for the AndroidX fixes.
Staged to:
go/dac-stage/reference/android/app/Instrumentation.html
go/dac-stage/reference/android/bluetooth/BluetoothAdapter.html
go/dac-stage/reference/android/bluetooth/BluetoothDevice.html
go/dac-stage/reference/android/bluetooth/BluetoothServerSocket.html
go/dac-stage/reference/android/inputmethodservice/InputMethodService.html
go/dac-stage/reference/android/view/KeyCharacterMap.html
go/dac-stage/reference/android/view/KeyEvent.html
go/dac-stage/reference/android/media/AudioManager.html
go/dac-stage/reference/android/net/wifi/WifiConfiguration.html
(Other files were not in the public Javadocs.)
Bug: 111925950
Test: make ds-docs
Exempt-From-Owner-Approval: Docs-only change
Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Merged-In: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Several java files had the typo {#link (for cross-references to other
Javadocs) instead of the proper {@link format. This was confusing the
new doc publish tool (Mivi) since that's the format used for {# Django
comments #}.
Fixed a couple of links that had other errors (which prevented building
once the {# -> {@ was done) and other typos.
Replaced throughout the frameworks/base project; I'll need a separate CL
for the AndroidX fixes.
(Other files were not in the public Javadocs.)
Bug: 111925950
Test: make ds-docs
Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Original Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Exempt-From-Owner-Approval: Docs-only change
Class for managing the connections to services on the AM side that
activities on the WM side bind with for things like oom score adjustment.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I4ab5140dd7f888f448ce19107bda92c01066a3dc
fixing order of import statements to clear repo hooks
Test: make ds-docs
Bug: 37126744
Change-Id: I0ebb3d1d2599a411afd9b8ffd6f2497d821deb2b
Exempt-From-Owner-Approval: Docs-only change
This adds a new framework user restriction that can be used by the DPC
to block installs from unknown sources on all profiles of a device.
Test: Manual test, disallowing installs in TestDPC disables installing
unknown sources apps.
Bug: 111335021
Change-Id: Ib9fb672c5e5dea2ac63bf8cbd1b04484b12b4056
Fixes promise of StatusBarManager#expandSettingsPanel to document what
happens on invalid tile name.
Added test to verify correct behavior.
Change-Id: I057210eb47411cf2a7dfefdd4efe49b96fd33f69
Fixes: 111128728
Test: runtest && manual
