Currently, the onProvideAutoFillStructure() methods can be called
twice: to auto-fill an activity and to save the activity's data
in the service.
The problem with this approach is that when the save workflow is
called, the activity might have been gone. Hence, a proper approach
is to keep the initial AssistStructure data in the system_service
memory, watch for view changes, and then passed the new structure
back to the AutoFillService.
A side effect of this change is that we need another way to determine
if the view is sanitized or not. For "standard" views, that will be
defined based on whether the view content come from a resource or not,
but that logic is not implemented yet (for now, all views will be
considered sanitized, except for TextView passwords). For "custom"
views (such as WebView), this logic is responsibility of the view
implementation, through the newChild() method, which now takes a
flag (whose value could be AUTO_FILL_FLAG_SANITIZED for sanitized
views).
The SaveCallback.onSuccess() method was simplified: it does
not need a list of saved ids anymore the auto-fill UI will not use it
anymore.
Another side effect is that the Save notification is gone - until
it's attached again, it can be test by using:
adb shell cmd autofill save
Finally, hook AutoFillUI on ACTION_CLOSE_SYSTEM_DIALOGS events.
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I907a7e21d1b3cd1ab6dec3a08d144a52655da46f
Mentioned that in the documentation, cleaned up the code
a bit and added unit tests
Bug: 34614754
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Change-Id: I91232bbe494398015094ab977c6a2adce339811f
And move references to the deprecated fields to
NotificationRecord for testability.
Test: runtest systemui-notification
Change-Id: If3910dc78297ad66679b1efa380315127261a018
* Fragment#isStateSaved: report whether a given fragment has been
through state save within its given FragmentManager. This will
additionally echo the state of its child FragmentManager, indicating
whether it is safe to perform transactions without losing state.
* Fragment#setArguments can now be called at any time before a
fragment's state is saved, not just before an internal index is
assigned. This fixes an issue with assigning arguments during
fragment inflation in some code paths.
* FragmentTransaction#postOnCommit: Add a Runnable to a
FragmentTransaction that will be executed once the operations in the
transaction have been fully executed. Transaction optimization may
mean that other transaction ops could run before this is executed,
or that specific operations from this transaction were optimized
out. (e.g. a fragment in this transaction was added, but then
removed in a subsequent transaction before pending operations were
executed.) This may not be used for transactions added to the back
stack, as we cannot persist the runnable for later to guarantee
running it when the transaction is reversed.
Test: CTS
Change-Id: I4eb90588135e30f287c6487aa62ebda231f3dad3
Messaging notifications now get an increased boost in size,
since those are usually important to the user.
Test: existing tests pass
Bug: 34469375
Change-Id: Idfc2d2403b04c4c2d17b821e3ccbbbd48d31654d
This change adds APIs for instant apps to store cookie data
that is presisted across instant installs and across the
upgrade from an instant to a standard app. Standard apps
can use the cookie APIs but when they are uninstalled the
cookie is also deleted. The cookies are kept longer than
the instant apps as they are much smaller - 16KB by default.
We can change the cookie size via a system setting i.e.
after we ship we can increase size if needed.
We also add internal APIs to surface information about
installed and uninstalled instant apps which should be
used for showing them in the UI. For this puporse we store
the icon, permissions, and label of uninstalled apps. If
the app is re-installed we drop this meta-data but keep
the cookie around. If we have cookie data stored and the
signing cert of the app changes when it gets re-intalled
we wipe the cookie.
Test: CTS tests pass; hiddent APIs tested manually
Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
Add note on DPM#setDelegatedScopes documentation regarding the
broadcast sent to the delegate package to notify its new scopes; and
change the admin ComponentName annotation to @Nullable in
DPM#getDelegatedScopes.
Bug: 33099995
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegation
Change-Id: I28fe3a631c05a9e6b8dae766ce6c42881f2e3a00
Testing utilities want the ability to know whether things in the UI
are in flux and they need to wait before testing on-screen values.
These changes (a subset of what's needed, but will have to do for
a start) allow querying of ActivityTransitions and ProgressBar, two
common/difficult pieces in the puzzle.
Test: CTS tests at ag/1835467
Bug: 30978257 Provide view transition Api to prevent flaky tests
Change-Id: If63b3d0dde2178d826ac1dbfad0fc50e5ed9a780
Port of I82cd22cda6e9ee22fe293c36859e99f49d36a129 from frameworks/support
Add API to track the "primary navigation fragment" for a
FragmentManager. This allows designating one active fragment in a
FragmentManager as the intended nested recipient of navigation actions
such as popping the back stack.
The FragmentManager popBackStack methods will now delegate to the
child FragmentManager of the current primary navigation fragment first
before trying to pop its own back stack. This can only happen if a
back stack transaction id or back stack entry name is not provided to
the pop operation, as these names and ids are namespaced to each
individual FragmentManager.
Primary navigation fragments are set as part of a FragmentTransaction
and follow the associated expectations. Transactions added to the back
stack will be fully reversed when popped, restoring the previous
primary navigation fragment for the FragmentManager. If a primary
navigation fragment is removed from the FragmentManager, the primary
navigation fragment will be set to null.
Bug: 30596279
Test: CTS
Change-Id: Ied7c1515f27142d6f4cd523f16eb35d38a2a2380
* commit 'a19056c35d16ddb5a6c1d3343729701b8939f1e1': (35 commits)
NetworkMonitor: send one DNS probe per web probe
NetworkMonitor metrics: add first validation information
APF: also drop any ICMPv6 RSs
ConnectivityServiceTest: fix testAvoidBadWifiSettings
Fix ConnectivityServiceTest testRequestBenchmark
Switch over to new "time.android.com" NTP pool.
Define API for metering network stats buckets.
Refactored NetworkStatsServiceTest to use Mockito instead of EasyMock.
Use @Ignore to explicitly disable a @Test method.
Fixed NetworkStatsServiceTest and converted it to JUnit4.
VPN network stat accounting changes.
ConnectivityThread: use lazy holder idiom
ConnectivityManager: use ConnectivityThread looper
ConnectivityManager: a simpler CallbackHandler
Indicate the NsdServiceInfo attributes are only filled in for a resolved service.
Add a null check for the OnStartTetheringCallback.
TokenBucket for rate-limiting and throttling
IpConnectivityMetrics reads buffer size in settings
CaptivePortalLogin: set mixed content policy to compatibility.
Add IP conn metrics to dumpsys and bug reports
...
Ported from frameworks/support change id
I824eb312fbdfd6b548fe94aa2cd5b03afbaa97c7
When a target fragment was set using Fragment#setTargetFragment, all
bets were off, especially when restoring from instance state. Order of
lifecyle initialization was undefined meaning that two bugs could
occur, both of which manifested as the target fragment was not
initialized by the time the referring fragment's onCreate ran. One
could happen if the target fragment is on the back stack, the other
could happen if the target fragment was ordered unfortunately in
FragmentManager implementation details. (!)
Fix both by guaranteeing that any target fragment gets pushed forward
to at least the CREATED state before we dispatch any lifecycle events
for the referring fragment.
Add some sanity checks that try to keep developers from setting target
fragments across different FragmentManagers or from creating target
cycles, both of which are bad ideas.
Bug: 33653458
Test: CTS FragmentLifecycleTest
Change-Id: If624d4665d29e205d37b9b384322e64d6d6d3615
* Encapsulated application-level auto-fill logic on AutoFillSession.
Currently, Activity.java directly manages the IAutoFillCallback binder
object used to auto-fill its views, but this logic need to be
extended so Views can use it to draw the auto-fill bar.
* Pass auto-fill id and boundaries to requests
So AutoFillUI can display its affordance in the right places.
* Uses a new auto-fill id on View (instead of reusing accessibility's).
That allows moving the logic on whether a new request should be made or
the existing UI moved to the service side.
* Split service methods in 2, for shell cmd and app
And applied the right permission check on both.
* Removed CancelationSignal from onSaveRequest()
Since it's not really needed.
* Etc...
¯\_(ツ)_/¯
BUG: 34637800
BUG: 31001899
Test: CtsAutoFillServiceTestCases passes
Test: manual verification
Change-Id: Ibd0cb2cfff6d0f6bb6b697a423ed5e89df687b82
Allow device owners and profile owners on a user
to communicate with each other, rather than restricting
it to device owners and managed profile owners as it is
at the moment
Bug: 34429083
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts -a armeabi-v7a --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerPlusManagedProfileTest
Change-Id: I81561a9838c3ccb623354a1b718da2fc6a5af1fe
