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
Previously we have added methods to manipulate color transform for each
surface, this patch exposes this API to Java code land for WindowManager or
display service to set the color transform.
BUG: 111562338
Test: Build, flash and boot.
Change-Id: I0388eed5d72b043820786264f060cde2bd7a6aea
ConfirmDeviceCredentials sometimes shows up without a title. Since CC
is now using BiometricPrompt, we need at least a private API that allows
the client to have the dialog show a default title.
Bug: 111461540
Test: Manual test with modified BiometricPromptDemo, to launch CC with
empty string
Change-Id: I02a3c9327635c04f201f76754f7c0e1135e5ff36
Also added callouts for fields that no longer sort results based on
contacts frequency.
Bug: 116422556
Test: make ds-docs -j32
Change-Id: I738e08bd4686e30b875fa37123ecebb4a5e179d3
Merged-In: Iddcd0b41b6ad991423a5ced78522a9ab2ad831a1
The android.content.pm.PackageInstaller install + uninstall APIs are
fully functional. No need to try to keep the intent based APIs
feature compatible.
In the future we will be able to restrict app targeting old targetSDK
levels from using the intent-based API. Even further in the future we
can radically simplify the package installer app.
Fixes: 116616700
Test: Built
Change-Id: Ia225d70fbee3fa31a3c1de388dcb05ff1063dccd
Also added callouts for fields that no longer sort results based on
contacts frequency.
Test: make ds-docs -j32
Bug: 116422556
Change-Id: Iddcd0b41b6ad991423a5ced78522a9ab2ad831a1
Original-Change-Id: I738e08bd4686e30b875fa37123ecebb4a5e179d3
On devices with multiple biometrics, ConfirmCredentials can
potentially ask the user to authenticate using more than one
biometric. This is a wrapper that sets the active user for
all modalities.
Bug: 111461540
Test: With work profile set up, CC has same behavior as
device running P.
1) With one lock disabled, use modified BiometricPromptDemo
to authenticate using CC in the work version of the app
2) Go to normal version of the app, authenticating
using BP (not CC) works with non-work biometric
Change-Id: I04b6f64d3fe373269366c243f406d897cb6fd83a
The check within BiometricService is done from system server process
so we need to pass in the actual userId.
Bug: 111461540
Test: With normal profile and FP enrolled, with work profile and no
FP enrolled, launching BiometricPromptDemo for work profile
and attempting to start authentication shows "none enrolled" message.
Change-Id: I45a1136d2b33bc7c594a3401e2a087103fb839f3
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
Now CalendarTracker will track the events of all calendars
that the current user syncs events for and has ownership
contributor or higher.
Test: runtest -x /extra/master/frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/ZenModeConfigTest.java
Change-Id: I898fc603c3247e6e3c560837e9eefd0a1e0dac3c
Fixes: 113368047
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
