Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2903583006:
Collect metrics on running Accessibility services on Android (Closed)
|
Created:
3 years, 7 months ago by dmazzoni Modified:
3 years, 6 months ago CC:
aboxhall+watch_chromium.org, agrieve+watch_chromium.org, asvitkine+watch_chromium.org, chromium-reviews, darin-cc_chromium.org, dmazzoni+watch_chromium.org, dougt+watch_chromium.org, dtseng+watch_chromium.org, jam, je_julie, nektar+watch_chromium.org, yuzo+watch_chromium.org Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionCollect metrics on running Accessibility services on Android
We'd like to optimize accessibility by only enabling the features actually
needed by running accessibility services. In order to determine what would
be the best signals of what running accessibility services actually need,
add some code to collect metrics on running accessibility services that we
can analyze later.
Manually verified that TalkBack, Select-to-Speak, and LastPass all result in
very different sets of metrics being collected.
BUG=428494
Review-Url: https://codereview.chromium.org/2903583006
Cr-Commit-Position: refs/heads/master@{#477721}
Committed: https://chromium.googlesource.com/chromium/src/+/f33b08933cff6791612633f2e4a191917bb9d567
Patch Set 1 #Patch Set 2 : Rebase #
Total comments: 6
Patch Set 3 : aelias #
Total comments: 2
Patch Set 4 : Remove duplicate, check ContentViewCore #
Total comments: 8
Patch Set 5 : Address feedback on metrics #
Total comments: 6
Patch Set 6 : Last feedback from mpearson #Patch Set 7 : Remove change to unrelated file #Patch Set 8 : Try again, rebase and remove unrelated file. #Patch Set 9 : Rebase #
Messages
Total messages: 71 (42 generated)
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
dmazzoni@chromium.org changed reviewers: + aelias@chromium.org, paulmiller@chromium.org
Description was changed from ========== Collect metrics on running Accessibility services on Android We'd like to optimize accessibility by only enabling the features actually needed by running accessibility services. In order to determine what would be the best signals of that running accessibility services actually need, add some code to collect metrics on running accessibility services that we can analyze later. Manually verified that TalkBack, Select-to-Speak, and LastPass all result in very different sets of metrics being collected. BUG=428494 ========== to ========== Collect metrics on running Accessibility services on Android We'd like to optimize accessibility by only enabling the features actually needed by running accessibility services. In order to determine what would be the best signals of what running accessibility services actually need, add some code to collect metrics on running accessibility services that we can analyze later. Manually verified that TalkBack, Select-to-Speak, and LastPass all result in very different sets of metrics being collected. BUG=428494 ==========
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
Don't we need metrics people to review new histograms?
Yes, I'll loop them in for review next, if this looks reasonable to you. Looks like I need to rebase.
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1230: static bool stats_collected = false; "static" has a bad code smell and I've found even seemingly harmless ones like this have a way of blocking refactorings. If you truly care about collecting the stat only once per run, this collection could be triggered at a higher level like Activity creation instead, since the only dependency is on the Context. But I'd suggest just removing this and having one stat collection per RenderFrameHost, that's similar to how a lot of stats are collected and the usage bias isn't necessarily wrong. It looks like you'd need to get rid of the transient, incompletely initialized one that's created in AXTreeSnapshotCallback(), though (which sooner or later will probably cause problems anyway). https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1243: if (event_type_mask & ACCESSIBILITYEVENT_TYPE_ANNOUNCEMENT) This type of mapping is prone to clerical errors not caught by compiler; since you're using a #define already, how about feeding in "ANNOUNCEMENT" string into it and generating the two lines? https://codereview.chromium.org/2903583006/diff/20001/tools/metrics/histogram... File tools/metrics/histograms/enums.xml (right): https://codereview.chromium.org/2903583006/diff/20001/tools/metrics/histogram... tools/metrics/histograms/enums.xml:56: +<enum name="AccessibilityAndroidServiceInfoEnum" type="int"> This non-mutually exclusive enum histogram is an unusual pattern and I worry it may be confusing when we come to analyze it. How about if (in addition to this) we UMA log the masks directly into sparse histograms. This would give us a better sense of what combinations the states typically come in (informing how best to break down our subsystems), and also may be useful as fingerprints for individual accessibility services.
Maybe I just don't understand because I've never designed any histograms before, but how are we going to separate out the different use-cases in the data we get back? Are we going to be able to look at individual logs and try to cluster them together, or are we just going to look at the one histogram with all the logs in it? If the latter, how do we differentiate the use-cases?
changwan@chromium.org changed reviewers: + changwan@chromium.org
Do you care to collect service.getId() as well in one session? Usually the ID looks like this: com.lastpass.lpandroid/.service.LPAccessibilityService That may help understand different app scenarios.
https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1230: static bool stats_collected = false; On 2017/05/24 20:19:54, aelias wrote: > "static" has a bad code smell and I've found even seemingly harmless ones like > this have a way of blocking refactorings. If you truly care about collecting > the stat only once per run, this collection could be triggered at a higher level > like Activity creation instead, since the only dependency is on the Context. > > But I'd suggest just removing this and having one stat collection per > RenderFrameHost, that's similar to how a lot of stats are collected and the > usage bias isn't necessarily wrong. It looks like you'd need to get rid of the > transient, incompletely initialized one that's created in > AXTreeSnapshotCallback(), though (which sooner or later will probably cause > problems anyway). There's one BrowserAccessibilityManager per RenderFrameHost, so I could just get rid of the check and always call it. I don't think the transient one from AXTreeSnapshotCallback will cause problems, right? Should be harmless. https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1243: if (event_type_mask & ACCESSIBILITYEVENT_TYPE_ANNOUNCEMENT) On 2017/05/24 20:19:54, aelias wrote: > This type of mapping is prone to clerical errors not caught by compiler; since > you're using a #define already, how about feeding in "ANNOUNCEMENT" string into > it and generating the two lines? Done.
https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1230: static bool stats_collected = false; On 2017/05/24 at 21:34:27, dmazzoni wrote: > On 2017/05/24 20:19:54, aelias wrote: > > "static" has a bad code smell and I've found even seemingly harmless ones like > > this have a way of blocking refactorings. If you truly care about collecting > > the stat only once per run, this collection could be triggered at a higher level > > like Activity creation instead, since the only dependency is on the Context. > > > > But I'd suggest just removing this and having one stat collection per > > RenderFrameHost, that's similar to how a lot of stats are collected and the > > usage bias isn't necessarily wrong. It looks like you'd need to get rid of the > > transient, incompletely initialized one that's created in > > AXTreeSnapshotCallback(), though (which sooner or later will probably cause > > problems anyway). > > There's one BrowserAccessibilityManager per RenderFrameHost, so I could just > get rid of the check and always call it. > > I don't think the transient one from AXTreeSnapshotCallback > will cause problems, right? Should be harmless. Sounds good to remove it. AXTreeSnapshotCallback would pollute the stats with another source, maybe minor but I think it's best to keep what we're counting clean. I think it could be avoided for now by not calling CollectStats if content_view_core is null. https://codereview.chromium.org/2903583006/diff/40001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/40001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1256: EVENT_TYPE_HISTOGRAM(event_type_mask, ANNOUNCEMENT); Looks like you're counting this twice by accident.
On 2017/05/24 21:03:21, paulmiller wrote: > Maybe I just don't understand because I've never designed any histograms before, > but how are we going to separate out the different use-cases in the data we get > back? Are we going to be able to look at individual logs and try to cluster them > together, or are we just going to look at the one histogram with all the logs in > it? If the latter, how do we differentiate the use-cases? Check out the metrics we got on Windows: https://uma.googleplex.com/p/chrome/histograms/?endDate=20170523&dayCount=1&h... If you sort them by count, it becomes really clear that there are a few APIs that are used on tons of systems, and then a long tail used on just a few. That allows us to identify a few key APIs that we know screen readers need, but we suspect that most other utilities don't need, and use them as a signal. I'm hoping for the same thing. We can hypothesize now that most "real" accessibility services need certain capabilities, but simple form-fillers and status light blinkers don't. The metrics would validate that hypothesis and tell us that, e.g. 95% of users with one accessibility service don't have one that requires a particular capability.
On 2017/05/24 21:29:48, Changwan Ryu wrote: > Do you care to collect service.getId() as well in one session? Usually the ID > looks like this: > > com.lastpass.lpandroid/.service.LPAccessibilityService > > That may help understand different app scenarios. Do we collect any other information like this? Is it okay from a privacy perspective? I feel slightly better sticking to more generic information than specific package names, but it depends on what precedent we have.
As far as I know, UMA doesn't support logging strings at all. I'm definitely interested in understanding which are the most popular accessibility extensions, but we will have to find a different source for this information, e.g. Play Store installation count. Then we can install them locally on a test devices and printf these mask values when locally debugging a performance issue with them.
On 2017/05/24 22:09:55, aelias wrote: > As far as I know, UMA doesn't support logging strings at all. I'm definitely > interested in understanding which are the most popular accessibility extensions, > but we will have to find a different source for this information, e.g. Play > Store installation count. Then we can install them locally on a test devices > and printf these mask values when locally debugging a performance issue with > them. FWIW, IntentHandler#recordExternalIntentSourceUMA() actually record the values based on rappor service, so we can probably do something similar here. I am not extremely sure about the privacy part, we aren't collecting anything unusual here, no user information is collected and we can get the same information locally once we install the app. The only added information is 'installation count' x 'service enable ratio' x 'chrome use count' (x 'frame launch count') which may arguably not be specific enough anyways... But I don't want to complicate things here, and don't mind starting from collecting collective usage first.
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
On 2017/05/24 21:44:50, aelias wrote: > https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... > File content/browser/accessibility/browser_accessibility_manager_android.cc > (right): > > https://codereview.chromium.org/2903583006/diff/20001/content/browser/accessi... > content/browser/accessibility/browser_accessibility_manager_android.cc:1230: > static bool stats_collected = false; > On 2017/05/24 at 21:34:27, dmazzoni wrote: > > On 2017/05/24 20:19:54, aelias wrote: > > > "static" has a bad code smell and I've found even seemingly harmless ones > like > > > this have a way of blocking refactorings. If you truly care about > collecting > > > the stat only once per run, this collection could be triggered at a higher > level > > > like Activity creation instead, since the only dependency is on the Context. > > > > > > But I'd suggest just removing this and having one stat collection per > > > RenderFrameHost, that's similar to how a lot of stats are collected and the > > > usage bias isn't necessarily wrong. It looks like you'd need to get rid of > the > > > transient, incompletely initialized one that's created in > > > AXTreeSnapshotCallback(), though (which sooner or later will probably cause > > > problems anyway). > > > > There's one BrowserAccessibilityManager per RenderFrameHost, so I could just > > get rid of the check and always call it. > > > > I don't think the transient one from AXTreeSnapshotCallback > > will cause problems, right? Should be harmless. > > Sounds good to remove it. > > AXTreeSnapshotCallback would pollute the stats with another source, maybe minor > but I think it's best to keep what we're counting clean. I think it could be > avoided for now by not calling CollectStats if content_view_core is null. Done, and added a comment.
https://codereview.chromium.org/2903583006/diff/40001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/40001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:1256: EVENT_TYPE_HISTOGRAM(event_type_mask, ANNOUNCEMENT); On 2017/05/24 21:44:50, aelias wrote: > Looks like you're counting this twice by accident. Done.
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
dmazzoni@chromium.org changed reviewers: + mpearson@chromium.org
+mpearson for metrics review
aelias@chromium.org changed reviewers: - mpearson@chromium.org
lgtm
lgtm
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
mpearson@chromium.org changed reviewers: + mpearson@chromium.org
>>> Manually verified that TalkBack, Select-to-Speak, and LastPass all result in very different sets of metrics being collected. >>> And were the individual values in these sets correct? :-P --mark https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:40: UMA_CAPABILITY_CAN_CONTROL_MAGNIFICATION = 0, In each section there, the actual string values of the enums are clearly meaningful and have to correspond exactly with an enum elsewhere (below). Please comment about this, perhaps with a pointer to the other places. You may also want pointers from those other places to here, to remind people to expand this enum and add code to CollectStats() when adding new enum values from those places. I.e., give instructions for your later selves. https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:90: #define EVENT_TYPE_HISTOGRAM(event_type_mask, event_type) \ nit: It might help to comment on the general strategy that these macros use. https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:112: // android.view.accessibility.AccessibilityEvent in Java: nit: It's really hard to check this list because it's in a different order than the order in that file. I know alphabetic order is handy, but I'm not sure it's the best choice in this case. ditto below https://codereview.chromium.org/2903583006/diff/60001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2903583006/diff/60001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:86: + Tracks flags and capabilities of enabled accessibility services. Please state when this is recorded. https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histo... It might also help to give guidance on how to interpret this. For example, it's clear to me as a metric person that the total number of emits to this histogram is effectively meaningless. But that might not be obvious to someone else.
On 2017/05/26 18:22:31, Mark P wrote: > >>> > Manually verified that TalkBack, Select-to-Speak, and LastPass all result in > very different sets of metrics being collected. > >>> > > And were the individual values in these sets correct? :-P Yes, they match what I see in the manifest. :)
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:40: UMA_CAPABILITY_CAN_CONTROL_MAGNIFICATION = 0, On 2017/05/26 18:22:30, Mark P wrote: > In each section there, the actual string values of the enums are clearly > meaningful and have to correspond exactly with an enum elsewhere (below). > Please comment about this, perhaps with a pointer to the other places. > > You may also want pointers from those other places to here, to remind people to > expand this enum and add code to CollectStats() when adding new enum values from > those places. I.e., give instructions for your later selves. Good idea. Added some details to those comments. https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:90: #define EVENT_TYPE_HISTOGRAM(event_type_mask, event_type) \ On 2017/05/26 18:22:31, Mark P wrote: > nit: It might help to comment on the general strategy that these macros use. Done. https://codereview.chromium.org/2903583006/diff/60001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:112: // android.view.accessibility.AccessibilityEvent in Java: On 2017/05/26 18:22:31, Mark P wrote: > nit: It's really hard to check this list because it's in a different order than > the order in that file. I know alphabetic order is handy, but I'm not sure it's > the best choice in this case. > > ditto below Switched to match the order in the file. The others were already in the same order as the java source, which is in order by flag value.
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...) android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...) cast_shell_android on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
https://codereview.chromium.org/2903583006/diff/60001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2903583006/diff/60001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:86: + Tracks flags and capabilities of enabled accessibility services. On 2017/05/26 18:22:31, Mark P wrote: > Please state when this is recorded. > https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histo... > > It might also help to give guidance on how to interpret this. For example, it's > clear to me as a metric person that the total number of emits to this histogram > is effectively meaningless. But that might not be obvious to someone else. Forgot to comment, but I addressed this too, take a look.
lgtm modulo some minor comments. thanks for the thorough revisions. --mark https://codereview.chromium.org/2903583006/diff/80001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/80001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:40: // Note: The string names for these enums have been chosen to nit: "have been chosen to" -> "must" https://codereview.chromium.org/2903583006/diff/80001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:99: // If you add a new constant, add a new UMA enum and add a line nit: add "above" before "and" ditto https://codereview.chromium.org/2903583006/diff/80001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2903583006/diff/80001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:94: + need far fewer capabilities. optional nit: remove everything after "because", unless you really do want to call out a particular accessibility service by name.
https://codereview.chromium.org/2903583006/diff/80001/content/browser/accessi... File content/browser/accessibility/browser_accessibility_manager_android.cc (right): https://codereview.chromium.org/2903583006/diff/80001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:40: // Note: The string names for these enums have been chosen to On 2017/05/31 23:35:02, Mark P wrote: > nit: "have been chosen to" -> "must" Done. https://codereview.chromium.org/2903583006/diff/80001/content/browser/accessi... content/browser/accessibility/browser_accessibility_manager_android.cc:99: // If you add a new constant, add a new UMA enum and add a line On 2017/05/31 23:35:02, Mark P wrote: > nit: add "above" before "and" > ditto Done. https://codereview.chromium.org/2903583006/diff/80001/tools/metrics/histogram... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2903583006/diff/80001/tools/metrics/histogram... tools/metrics/histograms/histograms.xml:94: + need far fewer capabilities. On 2017/05/31 23:35:03, Mark P wrote: > optional nit: remove everything after "because", unless you really do want to > call out a particular accessibility service by name. Done.
The CQ bit was checked by dmazzoni@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from paulmiller@chromium.org, aelias@chromium.org, mpearson@chromium.org Link to the patchset: https://codereview.chromium.org/2903583006/#ps100001 (title: "Last feedback from mpearson")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by dmazzoni@chromium.org
The CQ bit was checked by dmazzoni@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from paulmiller@chromium.org, aelias@chromium.org, mpearson@chromium.org Link to the patchset: https://codereview.chromium.org/2903583006/#ps120001 (title: "Remove change to unrelated file")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by dmazzoni@chromium.org
The CQ bit was checked by dmazzoni@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from paulmiller@chromium.org, aelias@chromium.org, mpearson@chromium.org Link to the patchset: https://codereview.chromium.org/2903583006/#ps160001 (title: "Rebase")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 160001, "attempt_start_ts": 1496857173620760,
"parent_rev": "cd8fc10c1957222029a90b230e90f3a0e0952cfb", "commit_rev":
"f33b08933cff6791612633f2e4a191917bb9d567"}
Message was sent while issue was closed.
Description was changed from ========== Collect metrics on running Accessibility services on Android We'd like to optimize accessibility by only enabling the features actually needed by running accessibility services. In order to determine what would be the best signals of what running accessibility services actually need, add some code to collect metrics on running accessibility services that we can analyze later. Manually verified that TalkBack, Select-to-Speak, and LastPass all result in very different sets of metrics being collected. BUG=428494 ========== to ========== Collect metrics on running Accessibility services on Android We'd like to optimize accessibility by only enabling the features actually needed by running accessibility services. In order to determine what would be the best signals of what running accessibility services actually need, add some code to collect metrics on running accessibility services that we can analyze later. Manually verified that TalkBack, Select-to-Speak, and LastPass all result in very different sets of metrics being collected. BUG=428494 Review-Url: https://codereview.chromium.org/2903583006 Cr-Commit-Position: refs/heads/master@{#477721} Committed: https://chromium.googlesource.com/chromium/src/+/f33b08933cff6791612633f2e4a1... ==========
Message was sent while issue was closed.
Committed patchset #9 (id:160001) as https://chromium.googlesource.com/chromium/src/+/f33b08933cff6791612633f2e4a1... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
