> Moving the size check to a comman place so that it is executed in
all related code
> Fixing size calculation when views are merged as a result of partial
update
Test: Manually tested with a dummy app
Bug: 31790171
Change-Id: Id0ea776796f156455d2cba31c8392d4875116949
This CL has a companion CL to add the @HalfFloat annotation to the
support library.
Test: cts-tradefed run singleCommand cts-dev --module CtsUtilTestCases --test android.util.cts.HalfTest
Bug: 29940137
Change-Id: I4e1dc456687c1c026437150e9cc94a54f3264d4e
Allow DO to bind service of PO in managed profile and vice versa.
DO and PO must be the same package.
Bug: 31895999
Change-Id: I3ce2943aebd1249401d5814757a0ce25b9f85279
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.CorpOwnedManagedProfileTest
the same batch many times
This allows DO to:
a) know that some logs were dropped (by trying with token and not
getting anything)
b) know how many logs were there in each batch (useful especially
for the dropped ones)
c) retry batch retrieval if it failed
Test: will be CTS tested once APIs unhidden
Bug: 29748723
Change-Id: I788359242e3b2a4cb638edb25e5db8b25646c29f
So far AutoFillService only received the assist data from framework; in
this CL, it also offers a method where the auto-fill provider can send
the auto-fill data back to framework.
The workflow is:
- AFMSI calls a new AM method (requestAutoFillData(), instead
of requestAssistContextExtras()).
- The assist receiver is located in the app, not on system service.
- AM uses a new request type (ASSIST_CONTEXT_AUTOFILL) to request the
assist data to the activity.
- ViewStructure has a new setAutoFillId() method which is used to set an
unique id for the view.
- View uses the accessibility id to implement the auto-fill id.
- When the activity fullfills the request, it creates an IAutoFillCallback
remote object - that will be used to set the auto-fill fields - and
returns it in the assist bundle (using the
VoiceInteractionSession.KEY_AUTO_FILL_CALLBACK key).
- The app-visible AutoFillService class offers an onFillRequest() method,
which contains the assist data and a FillCallback used to handle it.
BUG: 31001899
Test: manually built and ran it
Change-Id: I3d208c14e81022dc96dd03f38bbe25a778b24a67
This patch removes isPeripheralModeSupported(), hidden public method
which is always returning true. It also modify the BluetoothLeAdvertiser
to be able to use advertising instance with instance id equal 0.
Bug: 30622771
Bug: 24099160
Change-Id: Id31582621dbe56d5c3a8d4ee5cd296af66a5f026
More progress towards removing blocking calls to improve system
stability.
Test: builds, boots
Bug: 32715088
Change-Id: I5ab2d2687f4f47e0ee68105c6998e74798af061c
Allows option in tuner to switch between system theme overlays
if multiple exist. Requires a restart to take effect.
Test: Settings -> Tuner -> Other -> Theme
Change-Id: Iea43b9cbb67fd91c6008be594ad4cfd19c3f57ec
In some situations it would be useful if the application can give a
hint that the user is not likely to want the IME to update
personalized data such as typing history and personalized language
model based on what the user typed the input area.
Typical use cases are:
* When the application is in a special mode, where user's activities
are expected to be not recorded in the application's history.
Some web browsers and chat applications may have this kind of
modes.
* When storing typing history does not make much sense. Specifying
this flag in typing games may help to avoid typing history from
being filled up with words that the user is less likely to type
in their daily life. Another example is that when the application
already knows that the expected input is not a valid word (e.g.
a promotion code that is not a valid word in any natural language).
Applications need to be aware that the flag is not a guarantee, and
some IMEs may not respect it.
Since this is basically about the general behavior that can be
combined with any of type of input types, this CL uses
EditorInfo.imeOptions instead of EditorInfo.inputType.
Also so far it look OK to do nothing in EditorInfo#makeCompatible()
regarding this flag because 1) this bit (0x1000000) has never been
used and 2) it is less likely that just passing that bit to an IME
that do not know about this bit causes any issue.
Bug: 28157942
Test: compile only as this is just a hint and OS does nothing
Change-Id: Ibf5ac3d2b8f39542baf2635c0cadbe242b059f81
With this CL, one can specify a content URI with an embedded user ID to
InputContentInfo, like such a URI is supported in
Context#grantUriPermission().
Note that such a scenario is actually possible when 1) an application
running as User X sets a content URI to the system clipboard then 2) the
IME runing as User Y who share the clipboard with User X obtains the
content URI from the system and tries to create a new instance of
InputContentInfo.
Bug: 32427307
Bug: 32778718
Test: 'adb shell dumpsys activity permissions' with a custom IME that
instantiates InputContentInfo from the content URI obtained from
the clipboard.
Change-Id: I7918c0a379b8f3e7e64b106447b42447876f9057
Currently Commit Content API work only when the content URI provided by
the IME is accessible to the target application. This is non-trivial if
the target application is running as a different user (profile) and it
is actually a possible scenario when managed profile is enabled.
This CL takes care of such a situation, by fixing up the content URI
when and only when InputContentInfo#getContentUri() is called from a
different user than the owner of the content URI.
This CL also makes it clear that we currently do not support content
URIs that already have embedded user IDs. Since
IActivityManager#grantUriPermissionFromOwner() does not support such
URIs, we should have had a special handling for such a case, which will
be addressed in a subsequent CL.
Bug: 32427307
Bug: 32778718
Test: Made sure that Commit Content API works as expected on a managed
profile created by
https://github.com/googlesamples/android-testdpc
Change-Id: I19d87fc19beea248f49b59ec5a5711b95bcbb466
