Includes the following commits:
==
New system feature: eUICC.
Presence of this feature implies that eUICC-related APIs are expected
to function as long as an eUICC is present in the device. Note that an
eUICC may be embedded in the device but may also be removable.
==
Add empty EuiccManager API and plumbing.
==
Add stub EuiccService.
EuiccService is the class that the LPA app must implement; for now,
just define the action and priority so that the implementation can be
found. Actual methods will come later.
Also declare two relevant permissions: BIND_EUICC_SERVICE, which the
implementation must require (so that nobody else can bind to the
service directly), and WRITE_EMBEDDED_SUBSCRIPTIONS, which permits
signature|privileged apps and CTS (via development) to access
EuiccManager APIs.
==
Add UiccAccessRule based off UiccCarrierPrivilegeRules#AccessRule.
This class can be used to transfer access rules between an
EuiccService implementation and the platform.
We also add a simple encoding/decoding of a list of rules so that they
may be stored in the subscription info table.
==
Add getEid() to EuiccManager/EuiccService.
getEid() fetches the EID. It requires either a privileged permission
(READ_PRIVILEGED_PHONE_STATE) or carrier privileges on the
currently-active profile. Until there is a use case that requires
opening this up to apps with only READ_PHONE_STATE, we shouldn't do
so.
To avoid churn in the future, the API signatures for EuiccService
include a slot ID to identify which SIM slot is being used. However,
this parameter is currently not populated correctly (nor is it usable,
as no Telephony APIs accept a slot ID to address commands). There is
no need to expose it yet in the EuiccManager APIs as we expect to
follow the TelephonyManager pattern of allowing per-slot instances of
EuiccManager in the future while keeping other method signatures the
same.
==
Define Euicc UI actions in EuiccManager/EuiccService.
The EuiccManager actions are to be implemented by the platform (and
only the platform), which forwards the actions to the active
implementation.
Also, remove our explicit priority meta-data tag as we can just rely
on android:priority in the corresponding intent-filter.
==
APIs for downloading embedded subscriptions.
Includes:
-getDownloadableSubscriptionMetadata, used by the platform and LUI to
fetch metadata about a downloadable subscription. The platform will
use this to perform the necessary permission checks (only allowing
otherwise-unprivileged apps to download profiles that are permitted
per the subscription metadata), and the LUI can use this to present
the name of the profile.
-downloadSubscription, to actually perform a profile download.
The stub for startResolutionActivity is included but not implemented;
resolution activities will be handled in a follow-up change.
==
Test: TreeHugger
Change-Id: I47b1da5a69f0736012cb137e02cd6c4e07fdaace
On ViewState: split value into mCurrentValue and mAutofilledValue.
On Session: replacing mAutofilledDataset by mDatasetWaitingAuth and
ViewState.getAutofilledValue() (mAutofilledDataset is still needed,
but will be removed in the first partitioning CL).
Also fixed a missed 'return' on TimePicker.autofill()
Bug: 35707731
Test: CtsAutoFillServiceTestCases pass
Change-Id: Icc32701ae3e499a77d99e6ae1daa7d070a3df631
Explicitly send broadcasts to systemui, because thats where they are
going.
Test: cts
Change-Id: I2fdc74f2cf874e818ef52f37a58adf7cd38ca455
Fixes: 35704517
(cherry picked from commit c7f7111095)
Explicitly send broadcasts to systemui, because thats where they are
going.
Test: cts
Change-Id: I2fdc74f2cf874e818ef52f37a58adf7cd38ca455
Fixes: 35704517
Use VrManager as a proxy to pass the controller data file descriptor
from VrCore to VrWindowManager, since the latter is a purely native
service with no Java visibility.
This is intended to be replaced by moving the relevant parts of
VrWindowManager into VrCore (b/36506799).
Bug: 35619424
Test: manual on device
Change-Id: I9545349893ed9b23de4ba8d3cb61c7d403ad0b97
This reverts commit 2abf1c60cc.
We need the ability to register remote callbacks for persistent vr mode,
so vr flinger can register for persistent vr mode events.
Bug: 35885165
Test: Manually confirmed vr flinger can register and receive persistent
vr mode events.
Change-Id: I7713c4c8acae9a369fd0c06695ef712fddd12be8
We need the ability to register remote callbacks for persistent vr mode,
so vr flinger can register for persistent vr mode events.
Bug: 35885165
Test: Manually confirmed vr flinger can register and receive persistent
vr mode events.
Change-Id: I28ee7f4e103fc53ae3e5d8e692cb2f6fa7bdbc82
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
- Added a requestAutofill(view,flags) method, that when passed with
FLAG_MANUAL_AUTOFILL triggers a manual request.
- Added same method for virtual views
- Overloaded existing AutofillService request methods to take a flag.
- Added an AUTOFILL context menu option on TextViews.
- Added a canRequestAutofill() that is used to enable the context menu.
BUG: 35708229
Test: manual verification
Test: existing CtsAutoFillServiceTestCases pass
Test: android.autofillservice.cts.LoginActivityTest#testManualAutofill pass
Change-Id: I1a64d40da3373774451d178b1cabf20f11120e9d
The FillResponse was automatically adding the AutofillId of all Datasets to
the SaveInfo object, but that would cause problems when the AutofillService
is not able to save some data (for example, if it comes from a read-only
backend).
Bug: 36076444
Test: OptionalSaveActivityTest pass
Test: m update-api
Change-Id: I1d5faaddf29e1be0f357438c8485e07caf975293
Add an API to get the compatibility display ID from CompatibilityDisplay
in the framework.
Testing Done: Compiled, built and used this API from ActivityManager and
it works.
Bug: 36071574
Change-Id: Ie4d1eb6a6befa7dbc3413519de20e2762529079d
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
1. Added a new API for a connected auto-fill service to
disable itself
2. Added a new shell command to destroy all pending sessions
which is used in CTS tests
3. Fixed a bug where the unbind timeout was in minutes
instead of seconds
Test: wrote CTS tests, all auto-fill tests pass
bug:35848030
Change-Id: I681605aa0b8c004a0f14e30b57117c291d89a894
For now it's a "1-to-1" refactoring that keeps the same
functionalities, but soon SaveInfo will be expanded to
allow the AutoFillService to customize it.
Bug: 35727295
Test: CtsAutoFillServiceTestCases pass
Test: m update-api
Change-Id: I5aaa705be2b32590048f70ed0142437e05df94b7
When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.
Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
