Refactor TakeScreenshot code out of PhoneWindowManager;
add power menu item for Screenshot.
Test: runtest systemui
Change-Id: Ie8602386cd59f8fd991369d2117f7c4d76f65e41
* Added new metrics:
- AUTOFILL_USERDATA_UPDATED
- AUTOFILL_FIELD_CLASSIFICATION_MATCHES
- FIELD_AUTOFILL_MATCH_SCORE
- FIELD_AUTOFILL_NUM_FIELD_CLASSIFICATION_IDS
* Fixed how FIELD_CLASS_NAME is set for AUTOFILL_SERVICE_DISABLED_ACTIVITY
* Added extra info on some existing metrics:
- FIELD_FLAGS on AUTOFILL_SESSION_STARTED
- TYPE_CLOSE on AUTOFILL_REQUEST to indicate a null response from service
- FIELD_AUTOFILL_NUM_FIELD_CLASSIFICATION_IDS on AUTOFILL_REQUEST to indicate the number of ids in a
field classfification request
Bug: 70241978
Test: verified output of 'adb shell logcat -b events | grep sysui' while
running CTS tests associated with the changes
Change-Id: I05d8d0325e9b338dd3d874e5b95a08cedf4b271c
- Dont create a session if the component is not owned by the calling UID.
- Log metrics for forged attempts.
- Avoid possible NPEs on AutofillManager when context or client is null.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAutoFillServiceTestCases -t android.autofillservice.cts.VirtualContainerActivityTest#testAppCannotFakePackageName
Test: cts-tradefed run commandAndExit cts-dev -m CtsAutoFillServiceTestCases
Bug: 69981710
Change-Id: I9695bc046f3eb8aeecfe44f80fd0366f68b2c635
- Default automatic rules are priority only
- Existing user-created rules will be changed to priority only
- New user-created rules will always be priority only
- Metrics for new dialogs and zen preference controllers
Test: manual
Bug: 63077372
Change-Id: I8694d10ebdfa67ba96f4936c74eae17b450e32af
This overloaded method is useful for cases where the service needs to launch
an activity (for example, to unlock the user's vault), in which case it's
launched from the context of the activity being filled.
Test: atest CtsAutoFillServiceTestCases:SimpleSaveActivityTest#testSave_launchIntent
Test: atest CtsAutoFillServiceTestCases
Fixes: 69458616
Change-Id: I41bf5fd4954c38051e3275f2e8500a00dcf24724
add a default value for TextSelectionInvocationMethod
retain some O comments to aid analysis in the future.
add a P end comment to aid the automergers.
Test: mmm frameworks/base/proto
Change-Id: Ia28eaac44856ca21b4590fa46c736266c3541453
Add wpw metrics fields to wifi.proto to track wps usage
Bug: 68652564
Test: Unit test and verifying dumpsys
Change-Id: I224adf7e522af9609569f703f1ccc31b1444d6e4
Adds definitions for soft AP metrics related to number of connected
clients and soft AP sessions
Bug: 68712260
Test: None
Change-Id: I515afd215a04fd50b0045fa1d81eebb9354f7bb2
We are now adding new system UI event fields specifically for smart select.
This CL adds corresponding new metric field values and changes the log
event building accordingly.
Bug: 67674199
Test: Manually tested that the logs are correct.
Change-Id: I5b90c8b194de2d46d7d6be1f1c314be9a2239298
There was a case where a app launch started activity A. A step in
the UI finished A and started B in the same task. Next time A was
started it immediately finished itself, putting B at the top of
the task. Now, this launch was considered aborted because A was
finished during launching, making it invisible.
We fix this by modifying the logic to only abort the launch if the
full task is not visible anymore after an activity has been set to
invisible.
There is another case where an app launches A, finishes A, and then
launches B. In this case the home gets visible in between so we
don't consider this an app launch anymore, and correctly cancel
the logging. However it's still useful to know that this is
happening to expose it to the developer, so we log any cancel
events, no matter where they are coming from.
Test: Launch Snapchat, click Sign Up, click home, relaunch
Snapchat from home
Test: Open slow app and press home quickly to test cancel.
Change-Id: I211636c97fd6785adb3fe443a8ffa1ae766946a4
Merged-In: I211636c97fd6785adb3fe443a8ffa1ae766946a4
Fixes: 67094673
This patch changes instrumentation of default networks and default
network events:
- stop logging events for default network transitions,
but instead consistently log one event per continuous segment
when one given network was the default, including logging an
event for when there is no default network.
- keep a separate rolling buffer of DefaultNetworkEvent for
dumpsys and bug reports.
These changes allow to simplify post aggregation of default network
event metrics by removing any need to do time series processing.
Instead, metrics and counters can be implemented withouth any ambiguity
by following the recipe:
% of x = sum(duration | x = true) / sum (all durations)
where x can be various conditions such as:
- the default network was validated
- the default network was WiFi
- the default network was IPv6
- there was no default network
- ...
Most importantly, this new logging scheme allows to measure much more
reliably:
- the % of the time that a device had Internet, in the sense that the
default network was validated.
- the time transitions between default networks, keyed by previous and
new transports/link layer, which allows to derive wakelock durations
and wakelock power costs from default network switches.
This patch also simplifies the dumpsys interface of the connmetrics
service and reduces the commands to three:
- "flush" for metrics upload.
- "proto" for printing buffered event in text proto format.
- "list" for listing all events and statistics.
Bug: 34901696
Bug: 65700460
Test: runtest frameworks-net
Change-Id: I0521f1681a60cca07ac3bfd5741d64ce44de4cdd
There was a case where a app launch started activity A. A step in
the UI finished A and started B in the same task. Next time A was
started it immediately finished itself, putting B at the top of
the task. Now, this launch was considered aborted because A was
finished during launching, making it invisible.
We fix this by modifying the logic to only abort the launch if the
full task is not visible anymore after an activity has been set to
invisible.
There is another case where an app launches A, finishes A, and then
launches B. In this case the home gets visible in between so we
don't consider this an app launch anymore, and correctly cancel
the logging. However it's still useful to know that this is
happening to expose it to the developer, so we log any cancel
events, no matter where they are coming from.
Test: Launch Snapchat, click Sign Up, click home, relaunch
Snapchat from home
Test: Open slow app and press home quickly to test cancel.
Change-Id: I211636c97fd6785adb3fe443a8ffa1ae766946a4
Merged-In: I211636c97fd6785adb3fe443a8ffa1ae766946a4
Fixes: 67094673
Before this change each permission+action combo had it's own ID. This
was very fragile and did not work for non-system permissions.
Now the action is the log-type and the permission is just a field in the
log.
Test: Used API 23 and API 26 apps to grant and revoke permission and
confirmed logs are as expected
Change-Id: I51f038dd7ab0a9ea269cafca23bfe3e5b181feb1
This API is useful to improve the autofill performance for the scenarios where
the service knows it cannot autofill an app or activity.
Bug: 67867469
Test: cts-tradefed run commandAndExit cts-dev -m CtsAutoFillServiceTestCases -t android.autofillservice.cts.LoginActivityTest#testFillResponseAuthWhenAppCallsCancel
Change-Id: I58e3eb5714db840104e699d614e750c03e26e8ca
