The java counterpart of the JNI is now moved to external/libtextclassifier.
Test: atest android.view.textclassifier.TextClassificationManagerTest
Change-Id: Ide5e58d1c80d9a028cea4e9192a91aeac2843c71
ext.jar can be built using only public SDK APIs. This
makes that obvious.
Bug: 113148576
Test: make ext
Change-Id: I792b14924878623f832f3afbb1d3e23fba34d5bf
Add APIs for apps to access a LTE broadcast group call service provided
by a preinstalled middleware app, and add system APIs for the
preinstalled middleware app to communicate with frontend apps.
Bug: 112731375
Test: CTS
Change-Id: Ie6817cbc6c3b69de7a4d66c4cfc103b02e15ad6b
Add comment to provide some cautions in case of we make some changes on
the doc target names in the future.
Test: N/A
Bug: b/116221385
Change-Id: Ibb21ca51c1eed990fe5dfceb6a8170821e70f8cf
This is in preparation for BiometricManager. Each Manager should have its
own Service.
Bug: 112570477
Test: BiometricPromptDemo works
Change-Id: Ibbbd499a0fd5a2050b329ee038776c6c9f49cdb2
All of the annotations under this are intended for use in the SDK. In
order to make this clear (because other types of annotations are
planned), this change renames the target to
ojluni-annotated-sdk-stubs.
Bug: 115746226
Test: `make api-stubs-docs`
Change-Id: I11366b6293b681cb4c8118fc117601a671c33282
These targets all depend on libcore sources which are blocker for us to
enable java9 feature, so convert them to Metalava.
Also enable API level annotations for api-stubs-docs, offline-sdk-docs,
and online-sdk-docs.
Test: m -j docs
Bug: b/78245848
Change-Id: I354d699a79cc5e6580b50e0613e7602c77b9c0b5
Historically, InputMethodService (IMS) has relied on
InputMethodManager's hidden methods to communicate with
InputMethodManagerService (IMMS). Because of this, InputMethodManager
(IMM) has ended up being a mixture of IPC endpoint for both IME
clients and IME itself.
There are multiple problems.
* IMM is instantiated in almost all user mode processes. This means
that unnecessary IPC endpoints have been accessible to them via
reflection. Even though those endpoints refuses request without a
valid IME window token, and even though we have tighten up use of
private APIs in the runtime level, exposing unnecessary IPC
endpoints is still questionable.
* Mixing multiple responsibilities has been caused unnecessary
complexity in IMM. In Bug 70282603, we have moved some APIs from
IMM to IMS to sort out this complexity that are surfaced in API
boundary, but in the implementation level everything remained to be
the same.
Now that Bug 70282603 is fixed, the natural next step is to start
implementing actual an IPC connection from IMS to IMMS without relying
on IMM.
Here is the new diagram that describes (most of) IPC interfaces around
IMEs.
APP---(1)---IMMS
\ |
\ |
\ |
\ |
\ |
(2) (3)
\ |
\ |
\ |
\ |
\|
IME
(1): IInputMethodManager.aidl: send requests from APP to IMMS
IInputMethodClient.aidl: send requests from IMMS to APP
(2): IInputMethodSession.aidl: send requests from APP to IME
IInputContext.aidl: send requests from IME to APP
-> this is the actual interface behind InputConnection
(3): IInputMethod.aidl: send requests from IMMS to IME
IInputMethodPrivilegedOperations.aidl:
send requests from IME to IMMS
IInputMethodPrivilegedOperations.aidl is what this CL is adding.
With that, this CL moves 5 IPC methods
from IInputMethodManager.aidl (1)
to IInputMethodPrivilegedOperations.aidl (3).
There remain some IPC methods that are intended to be used only from
IMEs in IInputMethodManager.aidl because those methods have been
unfortunately exposed via public APIs in InputMethodmanager.
Although all of those public APIs were deprecated in Android P as part
of Bug 70282603, we still need to keep maintaining those APIs until
(most of) IMEs migrate to APIs that are newly introduced in
InputMethodService. It would take several years.
IInputMethodManager#getInputMethodWindowVisibleHeight() is another
method that we cannot migrate right now because some apps have already
relied on its corresponding hidden method in IMM, as discussed in Bug
113914148.
Fix: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
Introduce AlternativeNetworkAccess APIs
Bug: 113106744
Test: Verified using test app to make api calls
Change-Id: I7f470cd6028a12cc66a660d58720f803271d38eb
The processor outputs unsupportedappusage_index.csv, containing source
position info for every@UnsupportedAppUsage annotation processed. It is a
mapping of dex signature to the source postion of the annotation on that
signature. It is used as input for scripts which update the annotations.
We include a META-INF file which causes the compiler to automatically
pick up the annotation processor. Otherwise we would need to explicitly
specify the processor with a -processor flag to javac.
We create a new build target for just the @UnsupportedAppUsage annotation
and the @IntDef annotation (which it depends on) so that the processor can
also depend on that directly.
The processor only runs on a new build target framework-annotation-proc
so that it is not invoked as part of a regular build. This is done so
that we don't slow down peoples builds: Soong does not support annotation
processors when javac sharding is in use. This workaround can be removed
once b/77284273 is fixed.
Test: m framework-annotation-proc
Bug: 113853502
Change-Id: Ie9cd5a90ddf7a51f6035e849703fc39ad9127557
