gauravjj@google.com skavuluru@google.com clank-large-form-factors@google.com Captures the number of regular and incognito tabs used. Used tabs are calculated by identifying the number of tabs that were selected between ChromeTabbedActivity onResumeWithNative() and onStopWithNative(). This is recorded when onStopWithNative() is called by backgrounding the app or by opening another activity like SettingsActivity. If multiple instances are running, each instance will only track and record usage of tabs that it contains. gauravjj@google.com skavuluru@google.com clank-large-form-factors@google.com Captures the percentage of regular and incognito tabs used. This is calculated by finding the ratio of the number of tabs used to the total number of tabs available between ChromeTabbedActivity onResumedWithNative and onStopWithNative. Total number of tabs available is the sum of the tab count when CTA is resumed and any new tabs that are opened before CTA is stopped. This is recorded when ChromeTabbedActivity#onStopWithNative() is called by backgrounding the app or by opening another activity like SettingsActivity. If multiple instances are running, each instance will only track and record usage of tabs that it contains. bttk@chromium.org chrome-segmentation-platform@google.com Reports the variant of the optional toolbar button that was clicked. Reports only when the feature AdaptiveButtonInTopToolbar is active. bttk@chromium.org chrome-segmentation-platform@google.com Reports the variant of the optional toolbar button used during the session. Reports only when the feature AdaptiveButtonInTopToolbar is active, the button is placed in the toolbar, and is clickable. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records the newly selected radio button option for the adaptive toolbar button on the toolbar shortcut settings page. Recorded only when the selected radio button state is changed. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records the currently selected radio button option for the adaptive toolbar button on the toolbar shortcut settings page. Recorded on startup, only if AdaptiveButtonInTopToolbarCustomization feature is enabled. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records whether the toolbar settings toggle button is on or off on the toolbar shortcut settings page after the user manually changes it. Recorded after the user explicitly taps on the toggle button. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records whether the toolbar settings toggle button is on or off on the toolbar shortcut settings page. Recorded on startup. shaktisahu@chromium.org chrome-segmentation-platform@google.com Reports the variant of the optional toolbar button that was shown after a page load. Reports only when a page is loaded or a tab is switched. Reports only when the contextual page actions feature is enabled and after all the action providers have responded or the request has timed out. Only reported for pages in the regular profile. shaktisahu@chromium.org chrome-segmentation-platform@google.com Reports the variant of the optional toolbar button being shown during the start of a new navigation. Reports whenever TabObserver.onDidStartNavigationInPrimaryMainFrame() is called which then records the button variant currently being shown on the toolbar. Recorded for both regular and incognito profiles. roagarwal@chromium.org chrome-incognito@google.com Records the time (ms) we blocked the draw of the Incognito tab (if any) during the app restore phase to be sure the Incognito re-auth screen is shown. This gets recorded only when both native and tab state have been initialized as by then we would show the re-auth screen. Blocking draw on Incognito re-auth screen prevents accidental leakage of the Incognito tab contents. Note that, the Incognito re-auth screen is an opt-in feature controlled behind the Chrome Setting "Lock Incognito tabs when you leave Chrome" under "Privacy and Security" So, if the feature is turned off, we wouldn't block draw for this use-case and won't record this metric. lizeb@google.com clank-performance-team@google.com Record the time the application spent in the background in-between two foregrounded periods, meaning that when the application is started in background, then foregrounded, no data points are recorded. This is recorded at the end of each such background interval. Saturates at 1h. dtrainor@chromium.org peter@chromium.org Records whether notifications are enabled for Chrome, as the Android app, every time metrics are logged. rsesek@chromium.org clank-security@google.com Reports information about the ARM CPU of a device. This composes the 8-bit ARM implementer identifier and the 12-bit part number into a single 20-bit CPU identifier, ranging from [0x00000,0xFFFFF]. Depending on the CPU package, processor configuration, and/or kernel version, this may only report information about the processor on which the metric was collected. This can happen on heterogeneous-processor SoCs. The metric is logged once every startup. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records whether user has enabled background restriction for chrome. Recorded after native initialization in browser process. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records the standby bucket (UsageStatsManager.getAppStandbyBucket) in which chrome is currently placed by android. Recorded after native initialization in browser process. shaktisahu@chromium.org chrome-segmentation-platform@google.com Records the standby bucket (UsageStatsManager.getAppStandbyBucket) in which chrome is currently placed by android, when user has explicitly enabled background restrictions. Recorded after native initialization in browser process. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that an exact task has been created. Recorded when the task is scheduled. nyquist@chromium.org shaktisahu@chromium.org Measures the time starting from the instant the task was started till a notification was set on the background task job service for a task of type {TaskType}. Recorded when the notification was set as long as the task isn't finished. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been canceled. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that a specific task has been created with an expiration deadline. Recorded when the task is scheduled. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that a specific task has been created without the expiration feature activated. Recorded when the task is scheduled. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that a specific background task has expired. Recorded before the task is to be started. nyquist@chromium.org shaktisahu@chromium.org Records the time (uptimeMillis) taken by a background task of type {TaskType}. Recorded when the task finished callback is invoked. nyquist@chromium.org shaktisahu@chromium.org Records that a task extending a NativeBackgroundTask started loading the native portion of Chrome. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has failed to be scheduled. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been successfully scheduled. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been started. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been stopped by Background Task Scheduler before it was able to complete itself. lazzzis@chromium.org src/chrome/browser/back_press/android/OWNERS Recorded when the user invokes a back navigation only if the handler failed to operate as expected, (e.g. it does nothing). May be recorded multiple times for a single back press event if there are multiple failed handlers. Android only. lazzzis@chromium.org src/chrome/browser/back_press/android/OWNERS Records that a specific feature intercepted the system's back press gesture. lazzzis@chromium.org src/chrome/browser/back_press/android/OWNERS Records the time interval between the occurrence of two consecutive back press events. Emits when a back press event is intercepted. lazzzis@chromium.org src/chrome/browser/back_press/android/OWNERS Records that the back press causes the app to be minimized or the current tab to be closed. lazzzis@chromium.org src/chrome/browser/back_press/android/OWNERS Records the secondary activity which intercepts the back press when the user does the Backpress gesture and it's not handled by the system. ckitagawa@chromium.org yfriedman@chromium.org Records the total number of BindingManager bindings to ChildProcessConnections that were dropped due to the BindingManager reaching the connection limit. This value accumulates while the app is running and is emitted upong the app being backgrounded at which time the counter is reset. Replaced by Android.ChildMismatch.AppInfoError2; the previous implementation did not record the metric correctly in all cases. torne@chromium.org boliu@chromium.org Records what error (if any) was encountered verifying the child process's app info each time a child process is started via ChildProcessConnection. torne@chromium.org boliu@chromium.org Records what error (if any) was encountered verifying the child process's app info each time a child process is started via ChildProcessConnection. Replaced by Android.ChildMismatch.BrowserVersionChanged2; the previous implementation did not record the metric correctly in all cases. torne@chromium.org boliu@chromium.org Records if the installed browser version appears to have changed since the browser process was launched. Recorded each time a child process is started via ChildProcessConnection, but only if the child's ApplicationInfo did not match (i.e. when Android.ChildMismatch.AppInfoError is recorded as something other than no error). torne@chromium.org boliu@chromium.org Records if the installed browser version appears to have changed since the browser process was launched. Recorded each time a child process is started via ChildProcessConnection, but only if the child's ApplicationInfo did not match (i.e. when Android.ChildMismatch.AppInfoError is recorded as something other than no error). ckitagawa@chromium.org yfriedman@chromium.org Records the total number of sandboxed ChildProcessConnections in existence. This is emitted even if there are no live connections. Emitted at a Poisson distributed period with a mean of 5 minutes on Chrome on Android while in the foreground. ckitagawa@chromium.org yfriedman@chromium.org Records the number of sandboxed ChildProcessConnections with a {ChildProcessConnectionMetricsBindingState}. This is emitted even if there are no live connections. Emitted at a Poisson distributed period with a mean of 5 minutes on Chrome on Android while in the foreground. cduvall@chromium.org boliu@chromium.org Measures time from {type} child process starts to right before main. Only recorded on Android N+. Zygote measurements are recorded on Q+. Zygote measurements capture the CPU time (thread time) spent to create the app zygote process, before the zygote preload starts. For other processes it measures the time (uptimeMillis) to create the child process service. peconn@chromium.org src/base/metrics/OWNERS Recorded at the same time as "CustomTabs.Visible", this metric should eventually replace that one. This additionally distinguishes between Trusted Web Activities, WebAPKs and Webapps. As of M87, this histogram is logged on a log start, rather than log end to tag more logs. gangwu@chromium.org twellington@chromium.org Records the failure reason for ChromeStartupDelegate requests. Recorded at most once on application startup. gangwu@chromium.org twellington@chromium.org Records the result for ChromeStartupDelegate. Recorded on application startup. finnur@chromium.org twellington@chromium.org Measures the total number of contacts shown in the contacts picker. Measured once when the Contacts Picker dialog is dismissed. finnur@chromium.org twellington@chromium.org Records which action the user takes in the ContactsPickerDialog. Measured once when the Contacts Picker dialog is dismissed. finnur@chromium.org twellington@chromium.org The contact properties requested by the website (names, emails, telephone numbers). Measured once when the Contacts Picker dialog is dismissed. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org The contact properties requested by the website but rejected by the user. Measured once when the Contacts Picker dialog is dismissed. finnur@chromium.org twellington@chromium.org Measures the total number of contacts selected in the contacts picker. Measured once when the Contacts Picker dialog is dismissed. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the percentage of contacts selected in the contacts picker. Measured once when the Contacts Picker dialog is dismissed. Note: This metric was not logged in June 2023. bartekn@chromium.org lizeb@chromium.org Whether 64-bit and/or 32-bit apps can be installed on this device/OS. This is recorded every time a metrics log is created. nemco@google.com wenyufu@chromium.org clank-app-team@google.com Source that changed the auto dark web content settings. This includes both changes to global theme settings as well as individual site exceptions. This histogram does not take into account whether the browser UI theme is dark or not (e.g. browser theme could be "light" and user could still change auto dark mode state in site settings). Recorded when the auto dark web content settings changes including {NewState} twellington@chromium.org clank-app-team@google.com Records the reason why dark theme is enabled when dark theme is visible to user. twellington@chromium.org clank-app-team@google.com Records whether dark theme is enabled or not on cold start and when the enabled state changes. twellington@chromium.org clank-app-team@google.com Records user theme preference of system default, light or dark theme on cold start and when the theme preference changes. nemco@google.com wenyufu@chromium.org clank-app-team@google.com Entry that navigate the user into the Theme Settings. Recorded when the Theme settings is opened. ioanap@chromium.org fhorschig@chromium.org theocristea@google.com clhager@google.com Recorded when a UI surface/flow in Chrome on Android chooses to re-auth the user. It records where the request comes from (Password Manager, Autofill, Incognito or Device Lock Page). Removed May 2022. twellington@chromium.org tedchoc@chromium.org clank-app-team@google.com Records the largest display dimension in dp during deferred startup. The display size is not affected by Android N multi-window mode. Clamped at 200dp to 1200dp. twellington@chromium.org shuyng@google.com clank-app-team@google.com Records the largest display dimension in dp during deferred startup. The display size is not affected by Android N multi-window mode. Clamped at 200dp to 2000dp. 20dp granularity. twellington@chromium.org aishwaryarj@google.com clank-app-team@google.com Records the primary display (screen) size in tens of inches with 0.2 inches (2 units) granularity, during deferred startup. The display size is not affected by Android N multi-window mode. Removed May 2022. twellington@chromium.org tedchoc@chromium.org clank-app-team@google.com Records the smallest display dimension in dp during deferred startup. The display size is not affected by Android N multi-window mode. Clamped at 0 to 1000dp. twellington@chromium.org shuyng@google.com clank-app-team@google.com Records the smallest display dimension in dp during deferred startup. The display size is not affected by Android N multi-window mode. Clamped at 100 to 1000dp. 10dp granularity. Removed Feb 2020. agrieve@chromium.org cduvall@chromium.org Records the number of times Chrome runs "cmd package compile" to fix dexopt issues, and for what reason. arbesser@google.com autofill_assistant@google.com Counts calls to Activity.onPerformDirectAction made by the system on behalf of the assist app and which action was performed, if any. Available starting with Android Q. Removed in April 2023. hesen@chromium.org clank-downloads@google.com Records various actions taken by the user on the rename dialog in download home. qinmin@chromium.org clank-downloads@google.com Records instances where the foreground undergoes a lifecycle change (when the foreground starts, changes pinned notification, or stops). dtrainor@chromium.org clank-downloads@google.com Recorded when a download fails to open. dtrainor@chromium.org clank-downloads@google.com Recorded when a download is opened. Removed in April 2023. dtrainor@chromium.org clank-downloads@google.com The number of items selected when performing a multi-delete action. Removed in April 2023. dtrainor@chromium.org clank-downloads@google.com The number of items selected when performing a multi-share action. qinmin@chromium.org clank-downloads@google.com Records instances where a user interacts with a download notification (ie. clicks on, pauses, resumes, cancels). shaktisahu@chromium.org clank-downloads@google.com Records how users open audio download files on Android. shaktisahu@chromium.org clank-downloads@google.com Records the entry point for users opening downloaded files on Android, that are not audio nor video. shaktisahu@chromium.org clank-downloads@google.com Records how users open video download files on Android. qinmin@chromium.org clank-downloads@google.com Records instances of DownloadForegroundService stops. The number of expected stops (stopped) and unexpected stops (task removed, low memory, etc) can be compared to get a sense of how often the service crashes to see how it handles restarts. For example, the number of times the service is stopped because of low memory can be compared to the number of times the service has been destroyed to see how frequently it occurs. Or, the number of start sticky's will indicate how often the service is able to restart due to an unexpected stop. Removed in April 2023. twellington@chromium.org clank-downloads@google.com The number of downloads shared at the same time. Removed in April 2023. twellington@chromium.org clank-downloads@google.com Recorded when downloads are shared through the download manager. A recorded value of "All" indicates that multiple types of downloads were shared. twellington@chromium.org clank-downloads@google.com The percentage of total storage downloads consume. shaktisahu@chromium.org clank-downloads@google.com Records the required stretch of the smaller dimension before displaying an image on download home. Measured in percentage. {AndroidDownloadTypes} qinmin@chromium.org clank-downloads@google.com Records the entry point for users opening the download page on Android. wenyufu@chromium.org clank-large-form-factors@google.com Records the distance of the drag end position from the initial drag start position when dragging starts and ends within ContentView containing web contents. Note that the distance only counts the distance of drag event happend on the screen; scrolling for the web content will be disabled during drag. Used to assist in setting proper threshold to dismiss context menu during drag. Android only. wenyufu@chromium.org clank-large-form-factors@google.com Records the duration in ms of drag process when drop happend inside ContentView containing web contents, regardless DragEvent#getResult. Does not capture drag events that end outside the ContentView (Use Android.DragDrop.FromWebContent.Duration instead). Android only. wenyufu@chromium.org clank-large-form-factors@google.com Records the duration in ms of drag process when {DropResult}. Recorded for the drag process starts from the web content, and drop happens outside of the web content. Does not capture drag events that end inside the ContentView containing web contents. Recorded when such a drag event ends. Android only. For more information regarding drag results, see: https://developer.android.com/reference/android/view/DragEvent#getResult() wenyufu@chromium.org clank-large-form-factors@google.com Records the type of object being dragged, for the drag process starts from the web content, and drop happens outside of the web content. Does not capture drag events that end inside the ContentView containing web contents. Recorded when such a drag event ends. Android only. shuyng@google.com clank-large-form-factors@google.com Records the duration between the URI being cleared and ContentProvider#openFile attempts with that expired URI. This is used to evaluate how long we should keep the image data. Because drop target app could request data multiple times with the same URI, this metric could record multiple times per URI, which gives us the holistic view about the timing when the image data associated with the URI is needed. Another metric Android.DragDrop.Image.OpenFileTime.FirstExpired only records at most once per URI, to avoid counting in retries from drop target app when Chrome rejects the expired URI. This metric is recorded when Chrome receives an expired URI to retrieve data. If the URI is not the latest expired one, the metric will not be recorded because we do not calculate the elapsed time for older URIs. Android only. shuyng@google.com clank-large-form-factors@google.com Records the duration between receiving Android Drag End event and the first ContentProvider#openFile attempted by the drop target app. The duration is calculated during the first ContentProvider#openFile for each URI. Another metric Android.DragDrop.Image.OpenFileTime.LastAttempt is recorded for the last ContentProvider#openFile. Record 0 if the duration is negative (e.g. ContentProvider#openFile is accessed before drag ends). Android only. shuyng@google.com clank-large-form-factors@google.com Records the duration between the URI being cleared and the first ContentProvider#openFile attempt with that expired URI. This is used to evaluate how long we should keep the image data. Because drop target app may retry after Chrome rejects the expired URI; and the retries are not helpful to evaluate how long the data is needed; this metric records at most once per URI. Another metric Android.DragDrop.Image.OpenFileTime.AllExpired records multiple times per URI, to gives us the holistic view about the timing when the image data associated with the URI is needed. This metric is recorded when Chrome receives an expired URI to retrieve data. If the URI is not the latest expired one, the metric will not be recorded because we do not calculate the elapsed time for older URIs. Android only. shuyng@google.com clank-large-form-factors@google.com Records the duration between receiving Android Drag End event and the last ContentProvider#openFile attempted by the drop target app. The duration is calculated when the image data expired at the designated time limit. It is not recorded if the image data is replaced before the time limit due to the start of the next image drag. Another metric Android.DragDrop.Image.OpenFileTime.FirstAttempt is recorded for the first ContentProvider#openFile. Record 0 if the duration is negative (e.g. ContentProvider#openFile is accessed before drag ends). Android only. shuyng@google.com clank-large-form-factors@google.com Records the image size being dragged from Chrome. Recorded when start dragging an image from Chrome's web content, regardless of whether drop is handled successfully. Used to evaluate the memory consumption. Android only. shuyng@google.com clank-large-form-factors@google.com Records the interval between two back-to-back image drags. This is used to evaluate the duration to preserve the image data. Android only. wenyufu@chromium.org clank-large-form-factors@google.com Records the type of object dropped on the Omnibox, as well as whether it originated from Chrome. This metric could be used to determine the total number of uses for drag and drop to Omnibox, and specifics on how much each data type is being dropped. Android only. skym@chromium.org clank-sbui-team@google.com Recorded during ChromeBaseAppCompatActivity initialization if third_party dynamic colors logic thinks dynamic colors are available. This is often based on Android version and OEM. This metric is not related to whether dynamic colors are desired by features/experiments. mvanouwerkerk@chromium.org src/android_webview/OWNERS src/chrome/android/OWNERS Records the input device source for the action down touch event. anthie@google.com ljjlee@google.com chrome-kids-eng@google.com cros-families-eng@google.com The different GMS error status codes that a user may encounter during the parent authentication step in the local web approval flow. Recorded on Android only. See go/chrome-local-web-approval-parent-auth-error-codes (Googlers only) for the error code definitions. Warning: this histogram was expired from 2023-06-13 to 2023-07-28; data may be missing. agrieve@chromium.org fredmello@chromium.org tiborg@chromium.org wnwen@chromium.org Availability status for each dynamic feature module. Reported once per Chrome start. This metric's purpose is to measure a feature module's install penetration over time. agrieve@chromium.org fredmello@chromium.org tiborg@chromium.org wnwen@chromium.org Duration of successful installs for each dynamic feature module. Only contains install durations for modules first requested *before* Chrome started last and may therefore be installed from cache. Omits deep sleep time. agrieve@chromium.org fredmello@chromium.org tiborg@chromium.org wnwen@chromium.org Install status counter for each dynamic feature module. Recorded during on-demand and deferred installs. agrieve@chromium.org fredmello@chromium.org tiborg@chromium.org wnwen@chromium.org Install status for each dynamic feature module. Recorded after the installation has finished. agrieve@chromium.org fredmello@chromium.org tiborg@chromium.org wnwen@chromium.org Length of time during startup used by module framework code. This is our metric to improve and used to guard against regressions. agrieve@chromium.org fredmello@chromium.org tiborg@chromium.org wnwen@chromium.org Duration of successful installs for each dynamic feature module. Only contains install durations of modules first requested *after* Chrome started last and are therefore unlikely to be installed from cache. Omits deep sleep time. drott@chromium.org layout-dev@chromium.org Records the latency of looking up a local font from Android downloadable fonts at the time of instantiating the font in the fonts backend in the renderer. Includes time for error checking and attempting to create the font from the retrieved blob, if there is one. Only records timings for situations in which a font could not be instantiated. This is recorded only on devices that support high resolution timers. drott@chromium.org layout-dev@chromium.org Records the latency of looking up a local font from Android downloadable fonts at the time of instantiating the font in the fonts backend in the renderer. Includes time for error checking and attempting to create the font from the retrieved blob, if there is one. Only records timings for situations in which a font was successfully instantiated and returned. This is recorded only on devices that support high resolution timers. drott@chromium.org cduvall@chromium.org layout-dev@chromium.org Records the latency of fetching the font name lookup table from the browser. The table is cached by the renderer so will usually only be fetched once per renderer startup. This is recorded when an attempt is made to fetch the table, typically once per renderer on the first font lookup for that process. If the original fetch fails, this will be recorded the next time a font lookup is requested. twellington@chromium.org clank-app-team@google.com Records the time taken to fetch all available font files from the GMS Core Android downloadable font provider. Removed 09/2022. No longer needed. twellington@chromium.org clank-app-team@google.com Records font fetch requests by font name. These results may be used to determine whether it remains worthwhile to preload fonts that are available for renderer font match requests. Removed 09/2022. No longer needed. twellington@chromium.org clank-app-team@google.com Records the result of font fetch requests made to the GMS Core Android downloadable font provider. The result may be success, or failure with a reason. In the case of multiple failures, only the first one encountered is reported. See implementation at AndroidFontLookupImpl. twellington@chromium.org clank-app-team@google.com Records the time taken to make a fetchFonts font request to GMS Core via the Android downloadable font provider API. This metric may be used to determine whether it's reasonable to execute this task on the IO thread rather than posting to a background thread. twellington@chromium.org clank-app-team@google.com Records the time taken to respond to a request from the renderer to fetch a specific font file from the GMS Core Android downloadable font provider. sinansahin@google.com twellington@chromium.org Time it took to retrieve the downloadable fonts after the first draw of {ActivityType}'s content view. Mutually exclusive with *BeforeFirstDraw. Recorded when all downloadable fonts are retrieved. sinansahin@google.com twellington@chromium.org Time it took to retrieve the downloadable fonts after post-inflation startup. Mutually exclusive with *BeforePostInflationStartup. Recorded when all downloadable fonts are retrieved. {ActivityType} sinansahin@google.com twellington@chromium.org Amount of time the downloadable fonts were retrieved before the first draw. Mutually exclusive with *AfterFirstDraw. Recorded when the first #onDraw call happens for the {ActivityType}'s content view. sinansahin@google.com twellington@chromium.org Amount of time the downloadable fonts were retrieved before post-inflation startup. Mutually exclusive with *AfterPostInflationStartup. Recorded after AsyncInitializationActivity#performPostInflationStartup. {ActivityType} sinansahin@google.com twellington@chromium.org Time it took to retrieve the downloadable fonts after Application#OnCreate. Recorded when all downloadable fonts are retrieved. {ActivityType} oksamyt@chromium.org woa-performance@google.com Amount of time it takes to draw Android UI frames as measured by Android's FrameMetrics API. Each frame's draw duration is stored individually. The samples for this metric (along with Android.FrameTimelineJank.JankyFrames) are manually passed from Java to C++ to be recorded. This is done instead of recording in real time from Java due to the large number of generated samples (potentially ~60 per second). Recording them directly from Java would result in a JNI call for each sample which could cause performance issues. FrameMetrics only reports frames with Android UI updates. An idle input field would report only 2 frames per second due to the cursor blink animation. Scrolling through a web page may record no frames if no Android UI (like the address bar) updates. kartarsingh@chromium.org woa-performance@google.com Note: This metric doesn't capture web contents scrolling quality on chrome, it is only emitted on Webview. For scroll jank metrics in chrome please check Event.ScrollJank.DelayedFramesPercentage* and Event.ScrollJank.MissedVsyncs* histograms. This metric measures jankiness of frames during scrolls according to the Android's FrameMetrics API. Samples are recorded into the Janky bucket for frames for which their total duration exceeded the given deadline and into the NonJanky bucket for all other frames. This metric is recorded at the same time as Android.Jank.FrameDuration histogram. Known caveats of this metric: 1) During a staggered scroll where finger could be stationary for some time, any janks during the period when finger was stationary would still be marked as scroll janks even when we wouldn't have been producing frames during that time. ckitagawa@chromium.org clank-isochron-team@google.com This histogram records the time taken between the tab and tab switcher layout. Timing starts when the layout transition begins and ends on the first frame. This is recorded each time the layout transition animation occurs. ckitagawa@chromium.org clank-isochron-team@google.com This histogram records the time taken between the tab and tab switcher layout. Timing starts when the layout transition begins and ends on the last frame. This is recorded each time the layout transition animation occurs. ckitagawa@chromium.org clank-isochron-team@google.com This histogram records the result of thumbnail fetching in the Grid Tab Switcher on Android. This is recorded once per thumbnail fetch when a Tab card with a thumbnail is shown onscreen. roagarwal@chromium.org chrome-incognito@google.com Records the clicks on Clear Browsing Data button at history page for each profile type in Android. roagarwal@chromium.org chrome-incognito@google.com Records the clicks on Home button in Android toolbar for each profile type. roagarwal@chromium.org chrome-incognito@google.com Records the count of any cases when clicking on the "Close all Incognito tabs" notification may not delete any files which were opened in the Incognito session. True value denotes file was not deleted and false otherwise. roagarwal@chromium.org chrome-incognito@google.com Records the result of the attempt to re-auth the user via biometrics or device lock for the Incognito re-auth screen. roagarwal@chromium.org chrome-incognito@google.com Records the count when the Incognito lock setting was either turned "on" or "off" from the Chrome Settings > Privacy and Security > Lock Incognito tabs when you leave Chrome, option. This setting can be in disabled state if the Android screen lock is not set-up, in which case we don't record this metric. This is recorded only when the toggle is not in disabled state and if the re-authentication checks succeeds which follows after the user changes the toggle. This covers only the interactions done from the above mentioned Incognito lock Setting page. See also the metric "Android.IncognitoReauth.PromoActionType" which records the opt-in made exclusively from promo card. roagarwal@chromium.org chrome-incognito@google.com Records the action type the user makes on the Incognito re-auth promo card which is shown inside the Incognito tab grid view. There's only two possible interactions possible which is either to turn on the Incognito lock or dismiss the promo. A "Promo accepted" entry is emitted when user clicks on "Turn on Incognito lock" (gated on successful re-authentication) and a "No thanks" value is emitted when the user clicks on "No thanks". arabm@google.com chrome-incognito@google.com Records the number of impressions of the Incognito re-auth promo card when user clicks accept or dismiss or when the promo expires after the max number of impressions. roagarwal@chromium.org chrome-incognito@google.com Records the Incognito lock setting state (if available to clients) exactly once during the browser startup, after the native code is initialized. Note, for multi-windows this histogram would be emitted as many times as the users enter multi-window(s). mthiesse@chromium.org yfriedman@chromium.org When a navigation to an external protocol is blocked due to a missing gesture on the redirect chain, records the time in milliseconds since the last time the user touched the screen before the navigation. Note that this notion is decoupled from the last user activation in blink due to quirks around how the RedirectHandler works. mthiesse@chromium.org yfriedman@chromium.org Recorded when a navigation to an Intent URI occurs. Records the results of the navigation. mthiesse@chromium.org yfriedman@chromium.org Recorded when an external app is launched as the result of a navigation. Records the source and scheme of the navigation. twellington@chromium.org mthiesse@chromium.org When a user attempts to navigate a file: URI, records the mime type of the file. mthiesse@chromium.org tedchoc@google.com Number of URLs present in Text Share intents (ACTION_SEND) received by Chrome. tedchoc@chromium.org clank-team@google.com Signifies whether the last shared app information is retrieved successfully or not. This is logged when configuring the direct sharing menu item. cduvall@chromium.org agrieve@chromium.org Whether a split Context has had its ClassLoader replaced due to b/172602571. This is recorded every time a split Context is created. cduvall@chromium.org agrieve@chromium.org Amount of time it takes to create a new Context for a split. This will only be recorded if isolated splits are enabled. cduvall@chromium.org agrieve@chromium.org Amount of time spent waiting for a split preload task to finish. This will only be recorded if isolated splits are enabled. smaier@chromium.org agrieve@chromium.org The status of an AsyncTask when get() is called on the UI thread. This is only recorded if the AsyncTask isn't immediately available. Seeing the distribution of PENDING vs RUNNING tasks will give us a better idea for how to approach these hangs. rsesek@chromium.org Reports the kernel major and minor version from the utsname.release field. The low 16 bits of each version are combined into a 32-bit integer. The range is from [0x00020006,0x0004000a] to track kernel versions 2.6 through 4.10. finnur@chromium.org peter@chromium.org Recorded once per batch of files uploaded, when Chrome has made the determination of what media picker to show to the user. Removed 09/2022. Expired and not needed anymore. ssid@chromium.org The duration of each failed ActivityManager.getMyMemoryState() call made by MemoryPressureMonitor. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. ssid@chromium.org Memory pressure notifications sent by Android through ComponentCallbacks2. This metric was added 04/2018; for prior data for the browser process see MemoryAndroid.NotificationBackground and MemoryAndroid.NotificationForeground. {AndroidProcessType} lazzzis@chromium.org src/components/messages/OWNERS Recorded once per message when the message is dismissed to capture the dismissal reason (e.g. primary button tap, timeout). The histogram can be used for measuring user engagement with messages of different types. lazzzis@chromium.org src/components/messages/OWNERS Records the message identifier each time a message is enqueued through MessageDispatcher (the entry point to Chrome for Android's messages system). This histogram can be used for getting a count of messages broken down by message identifier. lazzzis@chromium.org src/components/messages/OWNERS Records the message identifier when an enqueued message is not immediately displayed either because there is another message on the secreen or because message scope (e.g. tab) is not active. This metric is recorded along with Android.Messages.Enqueued.Hiding, which records identifier of currently visible message. lazzzis@chromium.org src/components/messages/OWNERS Recorded when an enqueued message is not immediately displayed. This metric records message identifier of a message currently displayed on the screen (that prevented the enqueued message from getting displayed immediately). INVALID_MESSAGE is recorded when the message isn't displayed because message scope (e.g. tab) isn't active or when message queue is suspended. lazzzis@chromium.org src/components/messages/OWNERS Records the message identifier when a message is displayed immediately when it is enqueued. This includes cases when there are no other messages on the screen as well as cases when the new message is high priority and causes some other message to hide. lazzzis@chromium.org src/components/messages/OWNERS Records the type of stacking animation when it is triggered. The type indicates the relation between current displayed messages and incoming messages. lazzzis@chromium.org src/components/messages/OWNERS Records the message identifier of the back message which is hidden by the foreground message. Emits when the stacking animation is about to start. lazzzis@chromium.org src/components/messages/OWNERS Records the message identifier of the front message which is hiding the background message. Emits when the stacking animation is about to start. lazzzis@chromium.org src/components/messages/OWNERS Records the scenario when 3 message stacking could be possible. lazzzis@chromium.org src/components/messages/OWNERS Records the message identifier when {Action} during a stacking animation. lazzzis@chromium.org src/components/messages/OWNERS Records the time interval the message was displayed on the screen before the user dismissed it with a gesture. The metric is NOT recorded when the user presses primary or secondary button or when the message is auto-dismissed based on timer. The interval includes both enter and exit animation. The metric can be used to analyze the time threshold for the user to give up waiting for autodismiss timer and dismiss the message explicitly. lazzzis@chromium.org src/components/messages/OWNERS Records the time interval the message was displayed on the screen before the user explicitly dismissed it. The metric is recorded when the user presses primary or secondary button, or dismisses the message with a gesture. It is not recorded when the message is auto-dismissed based on timer. The interval includes both enter and exit animation. The metric can be used to analyze the amount of time it takes for the user to understand the message and take an action (e.g. click a button, dismiss the message, etc.). twellington@chromium.org clank-app-team@google.com Records the action taken on a security sensitive touch event in modal dialog. As of M84 it is used for site premission dialogs. Expired in M77. See Android.ChildProcessBinding.* tedchoc@chromium.org clank-team@google.com The number of moderate bindings which were kept while Chrome process is in the foreground. This is logged right before Chrome process goes into the background. jinsukkim@chromium.org twellington@chromium.org clank-app-team@google.com The maximum number of Chrome instances that ran at the same time in a 24-hour period. Checked whenever there is an activity state change to log the stats once in 24 hours. ranjithkagathi@google.com twellington@chromium.org Records the exceeded status when attempted to open a new chrome window. The value is set to true when attempted to exceed the maximum number of allowed chrome windows, the value is set to false otherwise. See also related metrics "Android.MultiInstance.NumActivities" and "Android.MultiInstance.NumInstances" which record the count of windows. jinsukkim@chromium.org twellington@chromium.org clank-app-team@google.com Records the number of running ChromeTabbedActivity's on every ChromeTabbedActivity startup. This includes activities that may not be visible on screen (i.e. it includes ChromeTabbedActivity's in the "stopped" state). This does not include ChromeTabbedActivity's that have been destroyed regardless of whether their owning Android Task may be retrieved in Android Recents. Applicable to Android S+ only. jinsukkim@chromium.org twellington@chromium.org clank-app-team@google.com The number of allocated instance IDs which corresponds to the number of retrievable Chrome instances (aka windows). An instance is considered retrievable if it has tab state data on disk irrespective of whether that data is currently assigned to a running ChromeTabbedActivity. These instances may be retrieved from Chrome's in-app window manager from Android Recents if they are associated with a live ChromeTabbedActivity or Android Task. Recorded on every ChromeTabbedActivity start-up. Applicable to Android S+ only. ckitagawa@chromium.org yfriedman@chromium.org bartekn@chromium.org chrome-metrics-team@google.com Records whether multiple user profiles are present in Android. This is recorded every time a metrics log is created. twellington@chromium.org tedchoc@chromium.org clank-app-team@google.com Records on every metrics upload whether the activity is running in Android N multi-window mode or not. skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com Total time spent in Android N+ multi-window (aka split-screen) mode. Recorded when multi-window mode is exited. finkm@chromium.org Counts impressions of the NTP on Android. It also counts potential impressions. A potential impression is a place where it would make sense to open the NTP instead of the current view. E.g. the no-tab view is counted as a potential impression since this view could be replaced with the NTP. For better comparison regular impressions are also counted. The no-tab view counting happens right after the user closed the last tab and the regular impression counting happens at construction time of the NTP (=whenever a new tab is opened). ender@google.com chrome-mobile-search@google.com Records the outcome of the User's interaction with ActionInSuggest chips, breaking down the cases where the intent could not be created or started. Recorded every time the user interacts with the ActionInSuggest, for the Action that the user interacted with. Not recorded if the user does not interact with ActionInSuggest. spelchat@chromium.org chrome-brapp-loading@google.com Records time between the user input that triggered an Omnibox navigation on Android to the time the Omnibox code calls into the shared C++ navigation code (NavigationController). ender@chromium.org chrome-mobile-search@google.com Recorded every time AutocompleteController.java interacts with autocomplete_controller_android.cc. Indicates how often matches referenced by Java are different from the matches referenced by C++ at any position. Note: starting Chrome 118, this is recorded every time we detect a non-cached match, when Native and Java AutocompleteResult objects differ. ender@google.com chrome-mobile-search@google.com Tracks the usage of Omnibox actions displayed in the Omnibox when the user completed interaction with the Omnibox, if at least one action was shown to the user at that time. Value "Used" indicates that at least one OmniboxAction was shown to the user and it was used. Conversely, value "Not Used" signifies that although actions were displayed, none were employed. The histogram is not recorded if no actions were visible. The histogram is recorded once per Omnibox interaction, where at least one Omnibox Action was shown to the user at the time the user completed interaction with the Omnibox. ender@google.com chrome-mobile-search@google.com Tracks the validity of Omnibox actions displayed in the Omnibox when the user completed interaction with the Omnibox, if at least one action was shown to the user at that time. Omnibox Actions can appear at any point, but the histogram only captures the ultimate state, disregarding any preceding events. An OmniboxAction is "Valid" if both Java and Native objects exist and are linked. "Not Valid" indicates a broken relationship, often due to Native AutocompleteResult becoming invalid. The histogram should ideally show values close to 100% validity. The histogram captures one value for every Omnibox Action displayed in the Suggestions list when the user completes the interaction with the Omnibox. ender@chromium.org jdonnelly@chromium.org Records interactions with the Search Refine button, differentiating by context (zero-prefix vs non-zero-prefix), including the cases where the User did not interact with the Refine button placed beside the Search suggestion at all. Recorded once per interaction with the Omnibox and Sugestions, when the Omnibox loses focus. This includes cases where the User chooses to navigate somewhere (both by using a suggestion or pressing Go button on keyboard), or abandons the Omnibox. spelchat@chromium.org chrome-brapp-loading@google.com Records time spent setting geolocation headers when the user navigates via the Omnibox. This time blocks the start of the navigation and is included in InputToNavigationStart metrics, but not in NavigationTo* metrics. Retired with M103. Please refer to .CreateTime2 ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records time spent on positioning all suggestions on screen. This histogram is recorded every time a new suggestion list is received. Values recorded here should generally aim to be small, likely below 2ms range. Higher values are an indicator of a performance problem. Layout operation should take place just once when suggestion view is shown for the first time. This metric is reported for all users and uses 100microsecond granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are laid out and how the overall time spent performing layout operation changed. This histogram is related to Android.Omnibox.SuggestionView.Reused, Android.Omnibox.SuggestionList.MeasureTime, Android.Omnibox.SuggestionView.CreateTime. ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records thread time spent on positioning all suggestions on screen. This histogram is recorded every time a new suggestion list is received. Smaller values are indicative of better performance, but the time taken varies considerably based on, e.g. whether new views need to be inflated and the number of suggestions being rendered. This metric is reported for all users and uses 100microsecond granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are laid out and how the overall time spent performing layout operation changed. This histogram is related to Android.Omnibox.SuggestionView.Reused, Android.Omnibox.SuggestionList.MeasureTime2, Android.Omnibox.SuggestionView.CreateTime2. ender@chromium.org pnoland@chromium.org gangwu@chromium.org Replacement for Android.Omnibox.SuggestionList.LayoutTime2 that uses wall time instead of thread time. Records wall time spent positioning suggestion view onto the screen. This histogram is recorded every time a new suggestion list is received, which is typically multiple times per keystroke. This metric is reported for all users and uses 1ms granularity. When comparing durations measured here, also compare Total Counts for a correct indication of how frequently views are laid out and how the overall time spent performing layout operation changed. This histogram is related to Android.Omnibox.SuggestionList.LayoutTime2, Android.Omnibox.SuggestionView.CreateTime3, and Android.Omnibox.SuggestionList.MeasureTime3 Retired with M103. Please refer to .MeasureTime2 ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records time spent on measuring all suggestions ahead of positioning them on screen. This histogram is recorded every time a new suggestion list is received. Values recorded here should generally aim to be small, likely below 2ms range. Higher values are an indicator of a performance problem. Measure operation should take place just once when suggestion view is shown for the first time. This metric is reported for all users and uses 100microsecond granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are measured and how the overall time spent measuring views changed. This histogram is related to Android.Omnibox.SuggestionView.Reused, Android.Omnibox.SuggestionList.LayoutTime, Android.Omnibox.SuggestionView.CreateTime. ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records time spent on measuring all suggestions ahead of positioning them on screen. This histogram is recorded every time a new suggestion list is received. Values recorded here should generally aim to be small, likely below 2ms range. Higher values are an indicator of a performance problem. Measure operation should take place just once when suggestion view is shown for the first time. This metric is reported for all users and uses 100microsecond granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are measured and how the overall time spent measuring views changed. This histogram is related to Android.Omnibox.SuggestionView.Reused, Android.Omnibox.SuggestionList.LayoutTime2, Android.Omnibox.SuggestionView.CreateTime2. ender@chromium.org pnoland@chromium.org gangwu@chromium.org Replacement for Android.Omnibox.SuggestionList.MeasureTime2 that uses wall time instead of thread time. Records wall time spent on measuring all suggestions ahead of positioning them on screen. This histogram is recorded every time a new suggestion list is received, which is typically multiple times per keystroke. This metric is reported for all users and uses 1ms granularity. When comparing durations measured here, also compare Total Counts for a correct indication of how frequently views are laid out and how the overall time spent performing layout operation changed. This histogram is related to Android.Omnibox.SuggestionList.MeasureTime2, Android.Omnibox.SuggestionView.CreateTime3, and Android.Omnibox.SuggestionList.LayoutTime3 ender@google.com pnoland@chromium.org gangwu@chromium.org Records time elapsed between requesting the suggestions and converting the first (synchronous) set of received suggestions to the UI model. For the complete, asynchronous iteration see the Android.Omnibox.SuggestionList.RequestToUiModel.Last metric. This metric is recorded exactly once per request, including the zero-prefix suggestions request. ender@google.com pnoland@chromium.org gangwu@chromium.org Records time elapsed between requesting the suggestions and converting the final (asynchronous) set of received suggestions to the UI model. For the short, synchronous iteration see the Android.Omnibox.SuggestionList.RequestToUiModel.First metric. This metric is recorded at most once per request, including the zero-prefix suggestions request. The metric will not be emitted if the current Autocomplete cycle was canceled by the user - either by refining the input in the omnibox, or by ending the interaction with the Omnibox. ender@chromium.org jdonnelly@chromium.org For every interaction with the Omnibox, this metric records whether the user scrolled the omnibox while exploring suggestions on {PageClass}. This is recorded once per Omnibox interaction, regardless of whether the User chooses to navigate somewhere or abandons the interaction. ender@google.com gangwu@chromium.org rongtan@chromium.org Records the type of suggestion that was reused with the help of RecyclerView. This histogram drives OmniboxSuggestionsDropdown optimization, helping us find the balance between the volume of suggestions and amount of memory we delegate to re-use the pre-constructed suggestion views. Along with the Android.Omnibox.SuggestionView.ReusedType, the two histograms paint the picture of which suggestions need to be created more often than others vs which suggestions have more capacity than is actually needed. Higher reuse means lower latency at the expense of slight increase of memory consumption. This histogram is related to Android.Omnibox.SuggestionView.ReusedType. Retired with M103. Please refer to .CreateTime2 ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records time spent creating a single suggestion. Values recorded here should generally aim to be small, below 1ms range. Higher values may be an indicator of a performance problem. This metric is reported for all users and uses 100microsecond granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are created and how the overall time spent creating views changed. This histogram is related to Android.Omnibox.SuggestionList.LayoutTime, Android.Omnibox.SuggestionList.MeasureTime, Android.Omnibox.SuggestionView.Reused. ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records time spent creating a single suggestion. Values recorded here should generally aim to be small, below 1ms range. Higher values may be an indicator of a performance problem. This metric is reported for all users and uses 100microsecond granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are created and how the overall time spent creating views changed. This histogram is related to Android.Omnibox.SuggestionList.LayoutTime2, Android.Omnibox.SuggestionList.MeasureTime2, Android.Omnibox.SuggestionView.Reused. ender@chromium.org pnoland@chromium.org gangwu@chromium.org Replacement for Android.Omnibox.SuggestionList.CreateTime2 that uses wall time instead of thread time. Records wall time spent on creating a single suggestion view. This histogram is recorded every time a new view is created, but not when a view is recycled. This metric is reported for all users and uses 1ms granularity. When comparing Durations measured here, also compare Total Counts for a correct indication of how frequently views are created and how the overall time spent creating views changed. This histogram is related to Android.Omnibox.SuggestionView.CreateTime2, Android.Omnibox.SuggestionList.LayoutTime3, and Android.Omnibox.SuggestionList.MeasureTime3 Replaced with Android.Omnibox.SessionViewsCreated and Android.Omnibox.SessionViewsReused since M110 ender@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records number of times a suggestion was successfully reused. Values recorded here tell how efficiently View reuse algorithms operate and how frequently these algorithms have managed to prevent unnecessary view creation. Higher Reuse counts indicate better performance. When analysing this metric, consider checking also the Total Counts of Android.Omnibox.SuggestionView.CreateTime metric for a better information regarding how view creations and re-uses have changed: * If this metric increased while the Total Count of the CreateTime decreased, the change has positive effect. * If this metric increased (or decreased) and there is a similar change in Total Counts of CreateTime, then the effect is neutral. * If this metric decreased, while the Total Count increased, then the change has a negative effect (fewer reuses, more time spent creating views) Obsolete: Please use Android.Omnibox.SessionViewsCreated and Android.Omnibox.SessionViewsReused. This histogram is related to Android.Omnibox.SuggestionList.LayoutTime2, Android.Omnibox.SuggestionList.MeasureTime2, Android.Omnibox.SuggestionView.CreateTime2. ender@google.com gangwu@chromium.org rongtan@chromium.org Records the type of suggestion that was reused with the help of RecyclerView. This histogram drives OmniboxSuggestionsDropdown optimization, helping us find the balance between the volume of suggestions and amount of memory we delegate to re-use the pre-constructed suggestion views. Along with the Android.Omnibox.SuggestionView.CreatedType, the two histograms paint the picture of which suggestions need to be created more often than others vs which suggestions have more capacity than is actually needed. Higher reuse means lower latency at the expense of slight increase of memory consumption. This histogram is related to Android.Omnibox.SuggestionView.CreatedType. ender@google.com rongtan@google.com Records number of views created from the moment the Omnibox was focused, until the interaction was completed, whether the user navigated somewhere or canceled the interaction. Values recorded here tell how efficiently the view creation and re-use works, highlighting possible issues related to unusually frequent view creation; the number of views created should be low and not exceed the sum of all the views recycled by HistogramRecordingRecycledViewPool component. Any deviation from this are a signal that the RecycledViewPool limits are not optimal. When observing a higher than expected number of created views, consult the Android.Omnibox.SuggestionView.CreatedType to identify view type that is not correctly captured and update the limits of the HistogramRecordingRecycledViewPool. This histogram is related to Android.Omnibox.SuggestionView.CreatedType, Android.Omnibox.SuggestionView.SessionViewsReused. ender@google.com rongtan@google.com Captures the efficiency of the view re-use from the moment the Omnibox was focused, until the interaction was completed, whether the user navigated somewhere or canceled the interaction. Values captured here directly reflect the efficiency of recycled view pool tuning, with the following caveats: * short sessions (omnibox focused and defocused, with no inputs) will report efficiency of 0% (because all the views had to be created and no views were available for re-use). * this metric will never truly capture 100% effectiveness, because during every input session some views will have to be created. The captured value should be at or above 90% re-use. Lower re-use rates may be an indication of a possible issue. This histogram is related to Android.Omnibox.SuggestionView.SessionViewsCreated. ender@chromium.org chrome-mobile-search@google.com Records whether users interacted with suggestion originating from Java cache. Android presents the Cached suggestions for a brief time before the Native libraries become available, replacing these with a fresh content as soon as Autocomplete subsystem serves them. This histogram records all the events where the cached suggestions were shown for an extended period of time - long enough for the User to identify and interact with a suggestion of their choice. Recorded every time the User initiates navigation using the Omnibox or the Suggestions list, regardless of context. Note: starting Chrome 118 this is recorded for every Autocomplete action requiring native AutocompleteMatch instance. ryansturm@chromium.org curranmax@chromium.org chrome-search@google.com {AndroidSearchPrefetch} The amount of time it takes to get the Geo Location header for a prefetch request. {AndroidNavigationOrSuggestionPrefetch} ryansturm@chromium.org curranmax@chromium.org chrome-search@google.com {AndroidSearchPrefetch} The number of prefetches that were successfully started from touch down events. This is recorded once per omnibox session. {AndroidNavigationPrefetchOnly} ryansturm@chromium.org curranmax@chromium.org chrome-search@google.com {AndroidSearchPrefetch} Whether or not the last prefetch started from the touch down trigger was used for a navigation. This is recorded once per omnibox session. {AndroidNavigationPrefetchOnly} ryansturm@chromium.org curranmax@chromium.org chrome-search@google.com {AndroidSearchPrefetch} The amount of time it takes to process a touch down event for Search Prefetch. This includes cases where: 1) the event is filtered out in the Java code (native is not initialized, the limit for preetches in an omnibox session is reached, etc.), 2) the event is sent to native but the prefetch is not started, and 3) the event is sent to native and the prefetch request is started. {AndroidNavigationPrefetchOnly} mdjones@chromium.org twellington@chromium.org amaralp@chromium.org mpearson@chromium.org jdonnelly@chromium.org Records how the omnibox was focused. roagarwal@chromium.org chrome-incognito@google.com Records the clicks on History menu item separately for each profile type in Android. nyquist@chromium.org yfriedman@chromium.org Records the size of the user's cache at startup on Android O and above. nyquist@chromium.org yfriedman@chromium.org At startup, records the space on disk taken by Chrome application including APK resources, compiled libraries, and extracted native code. Only recorded for Android O and above. nyquist@chromium.org yfriedman@chromium.org Records the size of the user's data directory at startup on Android O and above. Does not include cache size. wenyufu@chromium.org twellington@chromium.org Records the total duration of initializing PartnerBrowserCustomization in the background. Noting that and the initialization has a 10-second timeout, and this histogram does not count the duration for all associated callback. Recorded when the initialization is completed or canceled. wenyufu@chromium.org twellington@chromium.org Records the total duration of initializing PartnerBrowserCustomization in the background and running all of the associated callbacks. Recorded when the initialization is completed or canceled, and all the associated async callbacks are run. donnd@chromium.org wenyufu@chromium.org Records whether we were not able to create the initial tab at startup because Chrome is finishing or being destroyed. This is recorded in order to ensure that this is really an edge case. Recorded when Chrome tries to create any initial Tab at startup. donnd@chromium.org wenyufu@chromium.org Records a reason that a delegate could not be used for partner customization. Multiple records can be written when more than one delegate is tried and fails during a single initialization session. Recorded when a partner customization delegate tries to initialize but fails. Delegates may lazily initialize, so having one succeed may cause another to be skipped and the skipped one's potential failure would not be recorded. Trying to use the PreloadApk delegate is only done when actually needed so these numbers should reflect actual usage attempts. donnd@chromium.org wenyufu@chromium.org Records the amount of extra time that would be needed for the initial tab to be created before the delegate completes. Note that this metric undercounts the rare case where two ChromeTabbedActivity initial tabs are being created before the async customization completes (only the first is recorded). Recorded when the delegate completes customization successfully during startup, but too late to determine what kind of initial Tab to create. donnd@chromium.org wenyufu@chromium.org Records the amount of extra time that would be needed for the initial tab to be created before the delegate completes for the delegate "{CustomizationDelegate}". Note that this metric undercounts the rare case where two ChromeTabbedActivity initial tabs are being created before the async customization completes (only the first is recorded). Recorded when the delegate "{CustomizationDelegate}" completes customization successfully during startup, but too late to determine what kind of initial Tab to create. donnd@chromium.org wenyufu@chromium.org Records the amount of extra time that would be needed for the initial tab to be created before the delegate completes. Note that this metric undercounts the rare case where two ChromeTabbedActivity initial tabs are being created before the async customization completes (only the first is recorded). Recorded when there is no cached Partner Homepage and the delegate completes customization successfully during startup, but too late to determine what kind of initial Tab to create. donnd@chromium.org wenyufu@chromium.org Records the amount of extra time that would be needed for the initial tab to be created before the delegate completes. Note that this metric undercounts the rare case where two ChromeTabbedActivity initial tabs are being created before the async customization completes (only the first is recorded). Recorded when there is no cached Partner Homepage and the delegate "{CustomizationDelegate}" completes customization successfully during startup, but too late to determine what kind of initial Tab to create. donnd@chromium.org wenyufu@chromium.org Records the outcome of initial Tab creation relative to Homepage customization. The outcome characterizes the initial Tab focusing on an NTP and whether it was created correctly. When a custom Homepage was created we only record whether it was a Partner Homepage or some other Homepage. At this time we don't differentiate between User and Policy Homepages or record whether any Homepage was correctly created when customization changes. Recorded at the end of customization or initial Tab creation, whichever is last. donnd@chromium.org wenyufu@chromium.org Records the outcome of initial Tab creation relative to Homepage customization using delegate "{CustomizationDelegate}". The outcome characterizes the initial Tab focusing on an NTP and whether it was created correctly. When a custom Homepage was created we only record whether it was a Partner Homepage or some other Homepage. At this time we don't differentiate between User and Policy Homepages or record whether any Homepage was correctly created when customization changes. Recorded at the end of customization or initial Tab creation, whichever is last. donnd@chromium.org wenyufu@chromium.org Records the outcome of initial Tab creation relative to Homepage customization using delegate "{CustomizationDelegate}" when the Homepage was not previously cached. The outcome characterizes the initial Tab focusing on an NTP and whether it was created correctly. When a custom Homepage was created we only record whether it was a Partner Homepage or some other Homepage. At this time we don't differentiate between User and Policy Homepages or record whether any Homepage was correctly created when customization changes. Recorded at the end of customization or initial Tab creation, whichever is last. donnd@chromium.org wenyufu@chromium.org Records the amount of time it took for the {CustomizationDelegate} delegate to initialize. Recorded when the delegate is loaded successfully during startup and ready to produce custom data. donnd@chromium.org wenyufu@chromium.org Records the outcome of the async initialization task for the partner browser customization. This tells us how often the delegate is able to provide correct data, is canceled due to timeout, and whether exceptions were thrown, etc. Note that the correct data may actually arrive too late to be used because Chrome waits only 1/2 second before creating an initial tab, but it will be recorded here regardless. This logging of Completed-too-late is only done by the Chrome App, but all other values are logged for CCT as well. Recorded when the async task is completed or canceled during Chrome's start up. donnd@chromium.org wenyufu@chromium.org Records the outcome of the async initialization task for the partner browser customization. This tells us how often the delegate "{CustomizationDelegate}" is able to provide correct data, is canceled due to timeout, and whether exceptions were thrown, for this delegate. Note that the correct data may actually arrive too late to be used because Chrome waits only 1/2 second before creating an initial tab, but it will be recorded here regardless. This logging of Completed-too-late is only done by the Chrome App, but all other values are logged for CCT as well. Recorded when the async task is completed or canceled during Chrome's start up. donnd@chromium.org wenyufu@chromium.org Records the outcome of the async initialization task for the partner browser customization, when there is not yet any cached Homepage (likely Chrome's first launch). This tells us how often the delegate "{CustomizationDelegate}" is able to provide correct data, is canceled due to timeout, and whether exceptions were thrown, for this delegate. Note that the correct data may actually arrive too late to be used because Chrome waits only 1/2 second before creating an initial tab, but it will be recorded here regardless. This logging of Completed-too-late is only done by the Chrome App, but all other values are logged for CCT as well. Recorded when the async task is completed or canceled during Chrome's start up when no homepage is already cached. donnd@chromium.org wenyufu@chromium.org Records the amount of time it took for the delegate "{CustomizationDelegate}" to run in the async task that does partner customization. Recorded when the task completes but was unable to use the delegate for some reason - see DelegateUnusedReason histogram for some possible reasons. Trying to use the PreloadApk delegate is only done when actually needed so these numbers should reflect actual usage attempts. donnd@chromium.org wenyufu@chromium.org Records the amount of time it took for the delegate "{CustomizationDelegate}" to run in the async task that does partner customization. Recorded when the task completes successfully and a delegate providing customizations is found. Trying to use the PreloadApk delegate is only done when actually needed so these numbers should reflect actual usage attempts. donnd@chromium.org wenyufu@chromium.org Records which customization usage is being invoked, at the time it is requested. The possible usages include a custom Homepage URL, suppressing incognito, etc. wenyufu@chromium.org twellington@chromium.org Records whether partner customization is initialized before the first tab is created. A value of false means the first tab might be using a different homepage than the one customized by the partner. Recorded during Chrome start up when the very first tab is created. donnd@chromium.org twellington@chromium.org wenyufu@chromium.org Records which delegate will be used to provide the home page URL that is needed for a custom provider's customization. Recorded at startup on Android. finnur@chromium.org twellington@chromium.org Measures the amount of time the BitmapScaler spent scaling a bitmap. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the total number of images served from the high-res cache during the lifetime of the dialog. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the total number of images sent for decoding during the lifetime of the dialog. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org The percentage of out-of-memory decoding failures, per batch of photos (not videos) decoded. Intended to help identify if there are devices where decoding fails 100% of the time. Be wary at looking at other numbers in the histogram, as a value emitted at, say, 50% may represent one failure in a two-item decoding or 50 failures in a hundred-item decoding. These are qualitatively different experiences for a user. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org The percentage of file error decoding failures, per batch of videos (not photos) decoded. Intended to help identify if there are devices where decoding fails 100% of the time. Be wary at looking at other numbers in the histogram, as a value emitted at, say, 50% may represent one failure in a two-item decoding or 50 failures in a hundred-item decoding. These are qualitatively different experiences for a user. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org The percentage of IO error decoding failures, per batch of videos (not photos) decoded. Intended to help identify if there are devices where decoding fails 100% of the time. Be wary at looking at other numbers in the histogram, as a value emitted at, say, 50% may represent one failure in a two-item decoding or 50 failures in a hundred-item decoding. These are qualitatively different experiences for a user. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org The percentage of runtime error decoding failures, per batch of videos (not photos) decoded. Intended to help identify if there are devices where decoding fails 100% of the time. Be wary at looking at other numbers in the histogram, as a value emitted at, say, 50% may represent one failure in a two-item decoding or 50 failures in a hundred-item decoding. These are qualitatively different experiences for a user. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org The percentage of unknown decoding error failures, per batch of videos (not photos) decoded. Intended to help identify if there are devices where decoding fails 100% of the time. Be wary at looking at other numbers in the histogram, as a value emitted at, say, 50% may represent one failure in a two-item decoding or 50 failures in a hundred-item decoding. These are qualitatively different experiences for a user. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Records which action the user takes in the PhotoPickerDialog. finnur@chromium.org twellington@chromium.org Measures the total number of files returned from the enumeration operation. Measured once at the end of the enumeration operation. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the enumeration rate (files per tenths of a second). Measured once at the end of the enumeration operation. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time the BitmapScaler spent enumerating files on disk. Measured once at the end of the enumeration operation. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Records whether the EXIF orientation directive is present and what it is set to. Collected once per decoded image, but only on Android N and above (and when no IO error occurs). Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the byte count of a decoded image. Only recorded on successful decodes. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes the decoder to decode one image. Only recorded on successful decodes. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes to process one image decode request (not video) end to end (RPC and actual decoding of the bits by utility process). Recorded whether or not the RPC/decode request was successful. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes to decode all the frames needed to show the animation -- end to end (RPC and actual decoding of the bits by utility process). Recorded whether or not the RPC/decode request was successful. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes to process one video frame request end to end (RPC and actual decoding of the bits by utility process). Recorded whether or not the RPC/decode request was successful. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes to upscale a bitmap from the low-res cache. Recorded only when there a cache miss from the high-res bitmap but a cache hit from the low-res (placeholder) bitmap. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the byte count of the first video thumbnail. Only recorded on successful decodes. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes the decoder to decode all the frames needed to display an animated thumbnail. Only recorded on successful decodes. Note: This metric was not logged in June 2023. finnur@chromium.org twellington@chromium.org Measures the amount of time it takes the decoder to decode the first frame of a video. Only recorded on successful decodes. Note: This metric was not logged in June 2023. twellington@chromium.org tedchoc@chromium.org The version code for Google Play Services if it is installed on the device, or 0 if it is not. Recorded during deferred startup. hartmanng@chromium.org src/chrome/android/webapk/OWNERS Measures the amount of time spent querying for whether a WebAPK is already installed. shuyng@google.com twellington@chromium.org Records the changes of request desktop site content settings. This is recorded when a user manually switches the global setting between mobile/desktop. shuyng@google.com twellington@chromium.org Records the new domain level Request Desktop Setting when changed. False means Mobile site while true means Desktop site. This is recorded when a user manually edits a domain level Request Desktop Setting from the site settings exception list. aishwaryarj@google.com shuyng@google.com Records if a user opened the app menu as a consequence of showing the per-site IPH, emitted when the IPH is dismissed. shuyng@google.com twellington@chromium.org Records the new subdomain level Request Desktop Setting when changed. False means Mobile site while true means Desktop site. This is recorded when a user manually edits a subdomain level Request Desktop Setting from the site settings exception list. Deprecated in December 2022. This is no longer recorded as we cleanup feature flag RequestDesktopSiteForTablets. gangwu@chromium.org fgorski@chromium.org Records if Chrome width is eligible for requesting desktop sites. Recorded only when navigating to google or google search. This is recorded when chrome adds X-Eligible-Tablet to the http header per request. gangwu@chromium.org fgorski@chromium.org Records if Chrome uses the desktop site user agent to request websites. This is recorded when each tab loads a new url or reloads a url. gangwu@chromium.org fgorski@chromium.org Records if a user switched to request desktop site from the app menu. This is recorded when a user manually switches sites between the desktop/mobile. shuyng@google.com twellington@chromium.org Records the new domain level Request Desktop Setting when added. False means Mobile site while true means Desktop site. This is recorded when a user manually adds a domain level Request Desktop Setting from the Add site dialog in Site settings. shuyng@google.com twellington@chromium.org Records the new subdomain level Request Desktop Setting when added. False means Mobile site while true means Desktop site. This is recorded when a user manually adds a subdomain level Request Desktop Setting from the Add site dialog in Site settings. triploblastic@chromium.org chrome-signin-team@google.com Whether Chrome tried to restore its settings from a previous device or installation, and what happened when it did. Only recorded on first run. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org Whether the user restored tabs from the non default selected device. Recorded only if the user has multiple synced devices, and once per user interaction with the entire workflow on restore. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The total count of tabs eligible to be restored from the selected device. Recorded once per user attempt to restore tabs from the selected device. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The outcome of the promo show attempt from the RestoreTabsFeatureHelper. Recorded once per user attempt to show the promo after first run experience. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The portion of tabs the user ended up restoring out of the maximum possible amount. Recorded once per user attempt to restore tabs from the selected device. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The result of the workflow action taken on the RestoreTabs promo. Recorded once per user interaction with the promo when shown the first time. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The result of the workflow action taken on the RestoreTabs promo. Recorded once per user interaction with the promo when shown the second time. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The total count of synced devices on the user logged in account. Recorded once per user interaction with the entire workflow. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The total count of tabs that were actually restored from the selected device. Recorded once per user attempt to restore tabs from the selected device. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The ratio between the number of tabs that the user is eligible to restore and the number of tabs that were actually restored, from the currently selected device calculated as a percentage. Recorded once per user attempt to restore tabs from the selected device. jonross@chromium.org graphics-dev@chromium.org Measures the amount of time from when Android begins notifying the Browser process of a rotation, to when the Renderer successfully submits and activates a frame in the new orientation. fgorski@chromium.org wylieb@chromium.org The type of the search engine chosen by the user in Search Engine Choice flow. wylieb@chromium.org fgorski@chromium.org Counts occurences of various events related to Search Engine Choice feature. wylieb@chromium.org pavely@chromium.org fgorski@chromium.org Counts occurences of various events related to Search Engine Choice V2 feature. wylieb@chromium.org fgorski@chromium.org The type of the search engine used before Search Engine Choice flow was presented. rsesek@chromium.org Reports the status of the seccomp-bpf sandbox in renderer processes. Anything other than "Sandbox Engaged" indicates the sandbox is not turned on. See https://crbug.com/477049. finnur@chromium.org peter@chromium.org Records the types of content selected for upload, focusing mostly on image and video types and how they were determined (asking ContentResolver for the MIME type or going by extension). Recorded when user uploads files to a website (once per item uploaded). finnur@chromium.org peter@chromium.org Records the number of images selected in either the new Photo Picker or the standard Android file picker. Note: Only recorded in situations determined to warrant the new Photo Picker (not, for example, if mixed content, like images and text files, was requested). peter@chromium.org finnur@chromium.org Records the scope of accepted content for a select file dialog when shown by a Web developer. finnur@chromium.org peter@chromium.org Records the method of upload for files uploaded from Chrome via the SelectFileDialog, focusing mostly on image and video types. Recorded when user uploads files to a website (once per item uploaded). mvanouwerkerk@chromium.org wbjacksonjr@chromium.org Records the menu source type when a selection menu is shown. Android only. sreejakshetty@chromium.org chrome-brapp-loading@google.com Records the final status of the spare tab, for example, if the spare tab is used, destroyed, crashed, etc. This is recorded when the spare tab is used for navigation or destroyed. It is only recorded when a spare tab is created, and it is only recorded once per spare tab. yfriedman@chromium.org wnwen@chromium.org Measures the amount of time due to a StrictMode violation from calling out to Android activity manager. wnwen@chromium.org yfriedman@chromium.org Measures the amount of time due to a StrictMode violation from fetching for the thumbnail cache directory. Removed from code in Sep 2023. skym@chromium.org wenyufu@chromium.org clank-app-team@google.com The number of survey download request attempts that have been made before the survey is accepted. Note: 1) The download attempt might not result in a survey download due to different reasons (e.g. download request failed or network failure). 2) Chrome may have also successfully downloaded the survey several times in previous sessions, but the surveys were not able to be shown for min amount of times. In such scenarios, the total number of attempts across all sessions will be recorded. 3) If the number of allowed download attempts has been saturated before the survey is accepted, nothing will be recorded. Recorded when a survey prompt is accepted. Android Only. twellington@chromium.org wenyufu@chromium.org clank-app-team@google.com Recorded when a survey download is requested. If the download has been attemped, but the download request is not sent (e.g. user is not signed-in), 'not requested' will be recorded. skym@chromium.org wenyufu@chromium.org clank-app-team@google.com The result of the completed survey download request. A survey download is initiated on ChromeTabbedActivity cold start iff the user passes a series of eligibility checks. Recorded when a valid survey response is received. Android only. aishwaryarj@google.com twellington@chromium.org wenyufu@chromium.org clank-app-team@google.com The result of the request to show the survey after it has been downloaded. This request is initiated when the user accepts to take the survey on the survey prompt. This histogram is agnostic to the content of the survey, which is configured server side, and will be recorded for all surveys shown in Chrome. Android only. skym@chromium.org wenyufu@chromium.org clank-app-team@google.com Whether a user completed the survey after it was presented. This histogram is agnostic to the content of the survey, which is configured server side, and will be recorded for all surveys shown in Chrome. Android only. twellington@chromium.org wenyufu@chromium.org clank-app-team@google.com The result of the survey filtering process. Each enum represents a different filter that caught the user. This is recorded on cold starts when we check if a user qualifies for a survey. bjfong@google.com ckitagawa@chromium.org Records the percentage of sync-eligible tabs that are in local sync storage. This is recorded after session restore is completed and local data is reconciled. sreejakshetty@chromium.org spelchat@chromium.org chrome-brapp-loading@google.com Records the duration of new tab creation for {TabLaunchType}. Emitted everytime a new tab is finished being created. Take into account that low-end devices create tabs more slowly, so adjust your analysis accordingly. sreejakshetty@chromium.org spelchat@chromium.org chrome-brapp-loading@google.com Records the duration of the creation of a new tab from an existing WebContents for {TabLaunchType}. A record is made each time a tab is created using an existing WebContents. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org Reports the number of tabs that are bookmarked using the TabSelectionEditor bookmark action. Recorded once per user attempt to bookmark tabs in the Tab Selection Editor. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The result of the share action taken from the TabSelectionEditor. Record once per user attempt to share tabs in the Tab Selection Editor. ckitagawa@chromium.org fredmello@chromium.org Measures the time between opening the TabSelectionEditor in milliseconds within a given browser activity lifespan. This is recorded when the TabSelectionEditor is shown with the exception of the first time it is shown within an activity lifespan. rbyers@chromium.org mthiesse@chromium.org When a navigation is intercepted, the scheme of the URL being intercepted. blundell@chromium.org mthiesse@chromium.org tedchoc@chromium.org The distribution of results when running ExternalNavigationHandler for navigations that have an {ProtocolType}. This shows how often we send intents to be handled by other applications. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com We show a temporary tab strip on tablet startup until the real tab strip is able to be drawn. The experiment DelayTempStripRemoval delays this until either 1) the tab state finishes initializing or 2) a timeout is reached. This delay mitigates jank on startup as tabs are restored and the real tab strip appears to quickly scroll/flicker as a result. This histogram is recorded on tablets on startup and captures whether the temporary tab strip was removed before the tab state was initialized, which should give a rough estimate for how many startups are janky. This should, hopefully, go down when the aforementioned experiment is enabled and should help us tune its default timeout of 1000ms. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com We show empty placeholder tabs on the tablet tab strip during startup. The placeholders will be replaced by real tabs once they are restored, preventing a visual flicker/scroll jank as the restored tabs are rapidly populated to the strip. The number of placeholders and positioning of the active tab is calculated based on tab metadata saved to disk, and thus does not account for tabs created by other means during startup (e.g. user interaction). This histogram records the number of placeholder tabs, if any that are leftover when all tabs have been restored. This is captured when all tabs are finished restoring. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com We show empty placeholder tabs on the tablet tab strip during startup. The placeholders will be replaced by real tabs once they are restored, preventing a visual flicker/scroll jank as the restored tabs are rapidly populated to the strip. The number of placeholders and positioning of the active tab is calculated based on tab metadata saved to disk, and thus does not account for tabs created by other means during startup (e.g. user interaction). This histogram records the number of tabs created in this way (and thus are not accounted for in the placeholder strip). This is captured when all tabs are finished restoring. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com We show empty placeholder tabs on the tablet tab strip during startup. The placeholders will be replaced by real tabs once they are restored, preventing a visual flicker/scroll jank as the restored tabs are rapidly populated to the strip. The number of placeholders and positioning of the active tab is calculated based on tab metadata saved to disk, and thus does not account for tabs created by other means during startup (e.g. user interaction). This histogram records the number of restored tabs, if any, that we unexpectedly did not allocate a placeholder for. This is captured when all tabs are finished restoring. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com We show empty placeholder tabs on the tablet tab strip during startup. The placeholders will be replaced by real tabs once they are restored, preventing a visual flicker/scroll jank as the restored tabs are rapidly populated to the strip. The number of placeholders and positioning of the active tab is calculated based on tab metadata saved to disk, and thus does not account for tabs created by other means during startup (e.g. user interaction). This histogram records the amount of time for which the placeholders are ready to be shown before the tab state is initialized. This will roughly measure the amount of time that we could have been seeing the flicker/scroll jank without this feature. This is captured when all tabs are finished restoring. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com This captures the time until the buffer swaps (and the real tab strip can be drawn) after the tab state is initialized. This is the counterpart to the Android.TabStrip.TimeToInitializeTabStateAfterBufferSwap histogram and effectively marks how much leeway we had on a startup, before we'd need to delay the removal of the temp tab strip to mitigate jank. nemco@google.com skavuluru@google.com twellington@chromium.org clank-large-form-factors@google.com This captures the time until the the tab state is initialized after the buffer swaps. This is the counterpart to the Android.TabStrip.TimeToBufferSwapAfterInitializeTabState histogram and effectively marks how much additional time we would have needed to delay the removal of the temp tab strip on startup to mitigate jank. gauravjj@google.com twellington@chromium.org clank-large-form-factors@google.com This captures the time taken for a user to select a tab after scrolling the tab strip as one measure of tab strip switching efficiency. This is recorded only when a tab switch event occurs within 60 seconds of the most recent tab strip scroll. In the event of multiple back-to-back scrolls, this metric is recorded so long as the sequence of scrolls occur within 60 seconds of each other and is capped at 3 minutes. skavuluru@chromium.org twellington@chromium.org clank-large-form-factors@google.com Records the time taken to create the StartSurfaceCoordinator and grid tab switcher views. Only recorded for tablets. roagarwal@chromium.org chrome-incognito@google.com Emitted every time a user uses Incognito button on Tab Switcher. Records whether or not there is any Incognito tab when Incognito button is clicked. skavuluru@chromium.org twellington@chromium.org clank-large-form-factors@google.com Records the time taken to create TabListCoordinator, which inflates the RecyclerView for the grid tab switcher, and bind views. ckitagawa@chromium.org clank-isochron-team@google.com This histogram records whether the foreground tab was hidden after the tab switcher was shown. This operation is recorded when the foreground tab is attempted to be hidden after its use in animation and thumbnail capture is finished. A value of true indicates the tab was hidden and a value of false indicates the operation was cancelled. ckitagawa@chromium.org dtrainor@chromium.com Records the number of entries for the in-memory approximation bitmap thumbnail cache. Recorded on a Poisson distributed frequency with a mean of 5 minutes starting 1 minute after TabContentManager native initialization. ckitagawa@chromium.org dtrainor@chromium.com Records the in-memory approximation bitmap thumbnail cache size in KiB. Recorded on a Poisson distributed frequency with a mean of 5 minutes starting 1 minute after TabContentManager native initialization. Note that this memory may be distributed across the GPU process and Browser process. ckitagawa@chromium.org dtrainor@chromium.com Records the number of entries for the in-memory ETC1 and bitmap thumbnail cache. Recorded on a Poisson distributed frequency with a mean of 5 minutes starting 1 minute after TabContentManager native initialization. ckitagawa@chromium.org dtrainor@chromium.com Records the in-memory ETC1 and bitmap thumbnail cache size in KiB. Recorded on a Poisson distributed frequency with a mean of 5 minutes starting 1 minute after TabContentManager native initialization. Note that this memory may be distributed across the GPU process and Browser process. shaktisahu@chromium.org clank-downloads@google.com Measures the size of the bitmap cache used. Recorded whenever a bitmap is added to the cache. {ThumbnailProvider_ClientType} shaktisahu@chromium.org clank-downloads@google.com Records the status of a thumbnail query from the thumbnail provider in-memory cache. {ThumbnailProvider_ClientType} skym@chromium.org seacow@google.com Recorded when a toolbar view draws itself to a bitmap such that it can be passed to the compositor and drawn by native. Performing a bitmap capture is somewhat expensive opperation that must be done on the UI thread. It is possible that high capture counts are correlated with scroll jank. skym@chromium.org seacow@google.com Recorded on #isDirty calls that return true. Because #isDirty() is used to control when bitmap captures happen, this histogram holds the reason that the capture was allowed. Note that there there's an assert that calls into #isDirty() from #getBitmap(), which can cause these to be double counted. If Canary starts running assert code, this will cause this metric to double in report volume. skym@chromium.org seacow@google.com Recorded on #isDirty calls that return false. Because #isDirty() is used to control when bitmap captures happen, this histogram holds the reason that the capture was not allowed. skym@chromium.org seacow@google.com Captures the stages reached in the Toolbar's in motion handling. Recorded every time the in motion state of the compositor changes, before the event is routed to the renderer process. Motion states include: flinging, swiping, and any gesture that the CompositorViewHolder is processing. This metric shows how often the in motion handling had to request the toolbar's capture readiness state, which is a computationally expensive operation, and could slow down input handling. skym@chromium.org seacow@google.com When the allow reason for a bitmap capture was that the snapshots were different, then this histogram is recorded with the reason that the snapshots were different. Often there may be multiple differences but one is arbitrarily and consistently picked. amanvr@google.com woa-performance@google.com Records the time taken by chrome to display the first frame presented after unfolding(folding) a foldable device. This histogram aims to capture the unfold latency in devices which switch to tablet mode(phone mode) when unfolded(folded), and is recorded every time the device is unfolded(folded). The begin timestamp of the metric is the timestamp from the start of the first OnPause activity lifecycle callback before the activity recreates. The end timestamp is the timestamp when Chrome displays the first frame on the new screen. amanvr@google.com woa-performance@google.com Records the time taken by chrome to display the first frame presented after unfolding a foldable device. This histogram aims to capture the unfold latency in devices which switch to tablet mode when unfolded, and is recorded every time the device is unfolded. The begin timestamp of the metric is the timestamp from the start of the first OnPause activity lifecycle callback before the activity recreates. The end timestamp is the timestamp when Chrome displays the first frame on the new screen. amanvr@google.com woa-performance@google.com Records the time taken by chrome to display the first frame presented after unfolding a foldable device when Chrome is on top. This histogram aims to capture the unfold latency in devices which switch to tablet mode when unfolded, and is recorded every time the device is unfolded. The begin timestamp of the metric is the timestamp from the start of the first OnPause activity lifecycle callback before the activity recreates. The end timestamp is the timestamp when Chrome displays the first frame on the new screen. bartekn@chromium.org lizeb@chromium.org Version code identifies which bundle is used. It's effectively a version from the Play Store point of view. There can be multiple version codes for a given Chrome version. See go/chrome-android-version-codes. This is recorded every time a metrics log is created. nuskos@chromium.org chrometto-team@google.com Keeps a counter of each onDraw invoked on the root view and emits the count once every 30 seconds. Thus this is the amount of times android attempted to draw/update a java view in the last 30 seconds. NOTE: 30 second intervals with 0 draws are not reported. ntfschr@chromium.org src/android_webview/OWNERS Records calls to WebView APIs from AndroidX. Some AndroidX-originating calls may plumb through the corresponding platform (framework) API if the device OS version supports the platform API. In this case the API call will be logged by the "Android.WebView.ApiCall" histogram instead. This is logged each time an AndroidX API is called through the "boundary interface" code path (see //android_webview/support_library/README.md for more details). ntfschr@chromium.org src/android_webview/OWNERS Records calls to WebView APIs through the platform (framework) APIs. This may include AndroidX API calls on OS versions where the AndroidX library just calls through the platform API (see "Android.WebView.AndroidX.ApiCall" for details). This is logged each time an API is called. For historical data (before M99), see "WebView.ApiCall". ntfschr@chromium.org woa-performance@google.com src/android_webview/OWNERS Records calls to static WebView APIs through the platform (framework) APIs. This may include AndroidX API calls on OS versions where the AndroidX library just calls through the platform API (see "Android.WebView.AndroidX.ApiCall" for details). This is logged each time an API is called. Recorded in M118+. ntfschr@chromium.org woa-performance@google.com src/android_webview/OWNERS Records calls to WebView APIs made by the system through the platform (framework) APIs. This is logged each time an API is called. Recorded in M118+. xiaq@chromium.org src/android_webview/OWNERS Size on disk taken by the embedding app's data directory, recorded once per WebView startup after a small delay. xiaq@chromium.org src/android_webview/OWNERS Time to compute the size on disk taken by the embedding app's data directory, recorded once per WebView startup after a small delay. ntfschr@chromium.org src/android_webview/OWNERS Records the invocation count of WebView callbacks. Starting with M117, records shouldInterceptRequest counts. hazems@chromium.org src/android_webview/OWNERS Size on disk taken by the ComponentsProviderService serving directory. This is logged once per run of the update job in AwComponentUpdateService. hazems@chromium.org src/android_webview/OWNERS Size on disk taken by the AwComponentUpdateService directory. This is logged once per update job in AwComponentUpdateService. hazems@chromium.org src/android_webview/OWNERS Duration of ComponentsProviderService getFilesForComponent request. This method retrieves FileDescriptors for an installed component. This is logged at the end of every request the service receives. hazems@chromium.org src/android_webview/OWNERS Logs the result of ComponentsProviderService getFilesForComponent request. This method retrieves FileDescriptors for an installed component. This is logged once for every request the service receives. hazems@chromium.org src/android_webview/OWNERS Whether a SafeMode action was executed by Component Updater services. This is logged whenever a nonembedded Component Updater service checks whether SafeMode is enabled. hazems@chromium.org src/android_webview/OWNERS Whether AwComponentUpdateService quit unexpectedly on the previous run. This might indicate a crash occurred during the previous job. This is logged once per run of AwComponentUpdateService. hazems@chromium.org src/android_webview/OWNERS Duration of AwComponentUpdateService update job. This job is responsible for updating and installing components. This is logged once per run of the job. hazems@chromium.org src/android_webview/OWNERS How many components were updated by AwComponentUpdateService update job. This is logged once per run of the job, and is capped at 1000. michaelbai@chromium.org src/android_webview/OWNERS Records WebView force dark behavior settings on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records WebView force dark mode settings on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if WebView applies the algorithmic darkening on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if the application has light theme and if WebView applies the algorithmic darkening on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if the application is in the night mode and if WebView applies the algorithmic darkening on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if the application has light theme on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records application's night mode bit related to android.content.res.Configuration.UI_MODE_NIGHT_MASK on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if application is in night mode and if it has light theme on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records WebView is darkened or not when the prefers-color-scheme is set to dark according to the app theme not FORCE_DARK_AUTO setting. This histogram is recorded on main frame's color scheme inferred for every committed navigation. michaelbai@chromium.org src/android_webview/OWNERS Records if WebView shall set prefers-color-scheme to dark according to app's theme after FORCE_DARK_AUTO fails. It is recorded on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if the application has light theme and if its theme's textColorPrimary attribute is light on each main frame navigation entry committed. michaelbai@chromium.org src/android_webview/OWNERS Records if the application is in night mode and if its theme's textColorPrimary attribute is light on each main frame navigation entry committed. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the number of times the developer UI app was launched. This only ever logs the value "true" because we only care about the total count. This is logged in the developer UI app during Activity#onCreate. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the state of crash collection, as seen by the developer UI. This is recorded when launching the crash UI, but only if the UI is not already showing an error message for another problem (ex. WebView package error). This only logs the first state we detect: ex. if the user has enabled crash reporting by opting in and also with the flag UI, this only logs the flag UI case. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the user's interaction with crashes in the developer UI's crash list. Specifically, this tracks how the user interacts with the "hide crash", "upload this crash report" or the "file bug report" buttons and possible subsequent dialogs. Since the latter two buttons are connected (the user must upload a crash before they can file a bug report), we track interaction with both in the same histogram. This is recorded for each button press in the crash list and is not recorded if the user does not interact with any crashes. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the number of crashes shown in the developer UI. This is logged each time the crash UI is launched and each time its list is refreshed. The UI currently limits the number of crashes at 20, so clients logging the maximum may have more logs sitting on disk. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the time spent blocking WebView startup to check for developer mode (see "Android.WebView.DevUi.DeveloperModeEnabled"). This is recorded once during WebView startup, regardless of whether developer mode is enabled. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records whether or not WebView is starting up in "developer mode." This is a mode where the user has enabled debugging features through the WebView developer UI. This is recorded once during startup. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the time spent blocking WebView startup to load flags from the developer UI. This is recorded only once during WebView startup, and only if we've already detected developer mode is enabled (see "Android.WebView.DevUi.DeveloperModeEnabled"). ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS This is recorded each time a user toggles a flag in the developer UI (changing a flag's state), and logs whether the user found this flag with the search bar ("true" means there was a non-empty search query). This is only recorded when the user toggles an individual flag through the Spinner dialog, not when they press the "reset all flags" button. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the user's navigation to a Fragment. "FromIntent" tracks navigations triggered by an Intent (ex. navigating to HomeFragment on launch) and "NavBar" tracks user interaction with the bottom navigation bar. "AnyMethod" should be the sum of the other two. {Android_WebView_DevUi_NavType} ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the user's selection in the developer UI overflow menu or action bar, recorded after each selection. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records how the developer UI launcher icon for Monochrome was toggled: was it enabled or disabled? This can be recorded either from WebView's non-embedded processes or Chrome's browser process whenever either changes the icon state (nothing is logged if we don't need to change the icon state). This is only recorded in Monochrome (Android Nougat, Oreo, and Pie), since this logic is only relevant in that case. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the time spent using a specific tool, from creation to destruction. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the number of flags we will toggle for this run of WebView. This is recorded only once during WebView startup, and only if we've already detected developer mode is enabled (see "Android.WebView.DevUi.DeveloperModeEnabled"). If developer mode is disabled, we will not toggle any flags through this mechanism. peter@chromium.org src/android_webview/OWNERS Records strategy to be used by force dark in WebView when setForceDarkBehavior API is called by the embedding application. peter@chromium.org src/android_webview/OWNERS Records WebView's force dark setting and the UI's night mode when setForceDark API is called by the embedding application. blundell@chromium.org vasilyt@chromium.org syoussefi@chromium.org Tracks the amount of time that it took for ANGLE in WebView to sync from the external context. Recorded once per saving of HWUI state when drawing with GL. This is recorded only on devices that support high resolution timers. blundell@chromium.org vasilyt@chromium.org For each draw in GL that WebView does on request from HWUI, records whether the draw was done into the FBO or not. vasilyt@chromium.org boliu@chromium.org Tracks invalidate and frame submission status for WebView hardware draw. Result is enum that represent three flags: did we called invalidate this frame, did renderer submitted compositor frame and whether DrawParams from Android HWUI changed. This is logged once per WebView draw functor call. blundell@chromium.org vasilyt@chromium.org syoussefi@chromium.org Tracks the amount of time that it took for ANGLE in WebView to sync back to the external context. Recorded once per saving of HWUI state when drawing with GL. This is recorded only on devices that support high resolution timers. blundell@chromium.org vasilyt@chromium.org Tracks the amount of time that it took for WebView to save HWUI's GL state when not using ANGLE (when using ANGLE, the corresponding interval is recorded within ANGLE as GPU.ANGLE.SyncFromNativeContextMicroseconds; the method of recording is not quite identical, but the two metrics should be comparable at a high level). Recorded once per saving of HWUI state when drawing with GL. This is recorded only on devices that support high resolution timers. avvall@chromium.org src/android_webview/OWNERS Enumerates over the historical list of ApplicationExitInfo and their exit reasons for an application. Records the latest exit reason for the embedding application. avvall@chromium.org src/android_webview/OWNERS Enumerates over the historical list of ApplicationExitInfo and their exit reasons for an application. Records the latest exit reason for the embedding application, specifically when WebView's last recorded state before exiting was the background state. avvall@chromium.org src/android_webview/OWNERS Enumerates over the historical list of ApplicationExitInfo and their exit reasons for an application. Records the latest exit reason for the embedding application, specifically when WebView's last recorded state before exiting was the destroyed state. avvall@chromium.org src/android_webview/OWNERS Enumerates over the historical list of ApplicationExitInfo and their exit reasons for an application. Records the latest exit reason for the embedding application, specifically when WebView's last recorded state before exiting was the foreground state. avvall@chromium.org src/android_webview/OWNERS Enumerates over the historical list of ApplicationExitInfo and their exit reasons for an application. Records the latest exit reason for the embedding application, specifically when WebView's last recorded state before exiting was the detached state. avvall@chromium.org src/android_webview/OWNERS Tracks the deltas (in ms) between the current time of recording and the last time of recording historical application exit info data. Only recorded if the last time at recording was non-zero and there was some exit reason recorded. jam@chromium.org cduvall@chromium.org Measures how long InputStreams take from creation to completion. This is emitted for all streams whether they succeed or fail. peter@chromium.org src/android_webview/OWNERS Records whether an invocation of a JavaScript method exposed through WebView's Java Bridge happened on a page's main frame or one of its sub frames. Recorded for each invocation of such methods. ntfschr@chromium.org oksamyt@chromium.org torne@chromium.org src/android_webview/OWNERS Records the scheme for the URL loaded by a browser-initiated navigation. Specifically, this is the scheme of the URL passed to loadUrl() (and its overloads), postUrl(), and loadData() (this is implicitly "data:"). also records if this value is "empty", which means either null or "about:blank". This intentionally excludes loadDataWithBaseURL(). lizeb@chromium.org chrome-gpu-memory@google.com Reports the app's "other private dirty" memory usage after some time in background. Collects the same data as Memory.Experimental.Gpu2.OtherPss, with the same caveats. Due to these, this should not be relied on to get accurate estimates of memory usage or deltas, but mostly used as a signal in Finch experiments. This is intended to evaluate the impact of draw functor reclaim. lizeb@chromium.org chrome-gpu-memory@google.com Reports the app's "other PSS" memory usage after some time in background. Collects the same data as Memory.Experimental.Gpu2.OtherPss, with the same caveats. Due to these, this should not be relied on to get accurate estimates of memory usage or deltas, but mostly used as a signal in Finch experiments. This is intended to evaluate the impact of draw functor reclaim. ntfschr@chromium.org carlosil@chromium.org src/android_webview/OWNERS Records the mixed content mode set when an app uses the WebSettings.setMixedContentMode API. We collected the data we need about this, these histograms are no longer needed, see https://crbug.com/1266439#c8. Removed in December 2022. hazems@chromium.org src/android_webview/OWNERS Records the first nonembedded WebView Service to run in the nonembedded ":webview_service" process. This excludes ContentProviders because they are always created during the process startup. This is recorded when the service is created (when `onCreate` is called). Also see "Android.WebView.Nonembedded.IsFreshServiceProcessLaunched". We collected the data we need about this, these histograms are no longer needed, see https://crbug.com/1266439#c8. Removed in December 2022. hazems@chromium.org src/android_webview/OWNERS Captures if the service is the first service to be created in the process or not. It helps to see how often the nonembedded ":webview_service" process is reused for multiple services. This excludes ContentProviders because they are always created during the process startup. This is recorded when any nonembedded service is created (when `onCreate` is called). Also see "Android.WebView.Nonembedded.FirstServiceInProcess". hazems@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records the time interval between when a histogram is recorded in a non-embedded WebView process and when it's actually sent to the UMA API in an embedded WebView. This is recorded during WebView startup for each histogram retrieved and replayed successfully from WebView non-embedded metrics service. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records the number of histograms received from WebView's non-embedded histogram service. This is recorded once during WebView startup, after retrieving histograms from the service (if the proto can be parsed). avvall@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records whether metrics parsing from file in non-embedded histogram service was successful. It's recorded during service startup by adding it to records list. It captures the most recent file parsing result for the last service launch before the client connects to the service. avvall@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Recorded by the non-embedded histogram service if it's unable to return histograms. This is always recorded when a client connects to retrieve histograms. ntfschr@chromium.org hazems@chromium.org src/android_webview/OWNERS Records whether metrics transmission from the non-embedded histogram service was successful. This is recorded once during WebView startup, after retrieving histograms from the service. Deprecated in April 2022 (milestone M103). ntfschr@chromium.org src/android_webview/OWNERS The WebViewClient error code as returned by the onReceivedError callback This is recorded regardless of whether the network service is enabled or disabled. ntfschr@chromium.org src/android_webview/OWNERS This captures two pieces of information about renderer crashes: did the app developer handle the renderer crash to recover and what type of crash was this? This is recorded once each time the renderer process dies unexpectedly, and is logged after we have notified the app via the onRenderProcessGone() callback. Prior to M99, this histogram did not distinguish between crashes vs. kills if the renderer crash was handled by the app. ntfschr@chromium.org carlosil@chromium.org src/android_webview/OWNERS Records the mixed content mode set when an app loads optionally blockable mixed content (images, audio, or video). This histogram is logged on page load, once per subresource (i.e. a single page load can cause multiple records if the page contains multiple mixed content subresources). mvanouwerkerk@chromium.org src/android_webview/OWNERS Measures the count of distinct http and https origins visited per day in WebView. The purpose of this metric is to slice it by package name to help characterize the usage of that package. Deprecated in March 2022. mvanouwerkerk@chromium.org src/android_webview/OWNERS Time spent on a page with a {Scheme} scheme. This is measured from navigation commit to the start of the next navigation. For http and https schemes it is additionally recorded whether it is a first or third party page. This uses an optional key, in this case the value is "{Party}". bartekn@chromium.org lizeb@chromium.org Primary bitness of the bundle. This may be different from bitness of Browser. On WebView, Browser always follows bitness of the app, whereas Renderer follows bitness of the bundle (provided that such bitness is supported, so look at it in combination with CpuAbiBitnessSupport). This is recorded every time a metrics log is created. pbirk@chromium.org src/android_webview/OWNERS Records the type of X-Requested-With HTTP header that is set on request from WebView. This enum is recorded by |InterceptedRequest::InterceptResponseReceived| for all requests. It may differ from the user settings, as it also captures if the header has been set explicitly on the request by other means, such as javascript or embedding code. pbirk@chromium.org src/android_webview/OWNERS Records whether a suitable WebContents was available for use to look up the partition origin for the XRequestedWith deprecation origin trial. This histogram is recorded when the AwProxyingUrlLoader attemps to get the last committed origin of the top frame for partitioning use, which is on all requests that are not top frame navigation requests. If the WebContents is not available, an opaque origin will be used for partitioning, which will result in a failed lookup. Replaced before launch by Android.WebView.RequestedWithHeader.OnNavigationRequestedWithHeaderAllowListSize pbirk@chromium.org src/android_webview/OWNERS Records the XRequestedWithHeaderMode that was configured to be used on page navigation to decide how to set the X-Requested-With HTTP header. This is recorded on navigation committed, and records the configured setting. It may be the case that javascript or the embedder has overwritten the header, which will not be reflected by this histogram. pbirk@chromium.org src/android_webview/OWNERS Records the size of the XRequestedWithHeaderAllowList that was used on page navigation. This is recorded to gain insight into the distribution of size when used, which will give an idea of the impact to the ecosystem. pbirk@chromium.org src/android_webview/OWNERS Records if the WebViewXRequestedWithDeprecation Origin Trial was enabled on a resource request. This histogram is recorded on every request sent by WebView if Persistent Origin Trials are enabled. pbirk@chromium.org src/android_webview/OWNERS Records if the WebViewXRequestedWithDeprecation Origin Trial was enabled on a resource request with a scheme that uses cryptography, i.e. HTTPS or WSS. This histogram is recorded on every request sent by WebView if the WebViewXRequestedWithDeprecation trial is enabled and the scheme is either HTTP/HTTPS or WS/WSS. Replaced before launch by Android.WebView.RequestedWithHeader.SetRequestedWithHeaderModeAllowListSize pbirk@chromium.org src/android_webview/OWNERS Records the parameter passed to WebSettingsCompat#setRequestedWithHeaderMode when called by the embedding app. This reflects explict configuration of the X-Requested-With HTTP header by the app for WebViews. pbirk@chromium.org src/android_webview/OWNERS Records the size of the allow-list passed to WebSettingsCompat#setRequestedWithHeaderOriginAllowList when called by the embedding app. Replaced before launch by Android.WebView.RequestedWithHeader.SetServiceWorkerRequestedWithHeaderModeAllowListSize pbirk@chromium.org src/android_webview/OWNERS Records the parameter passed to ServiceWorkerWebSettingsCompat#setRequestedWithHeaderMode when called by the embedding app. This reflects explict configuration of the X-Requested-With HTTP header by the app for WebView service workers. pbirk@chromium.org src/android_webview/OWNERS Records the size of the allow-list passed to ServiceWorkerWebSettingsCompat#setRequestedWithHeaderOriginAllowList when called by the embedding app. ntfschr@chromium.org src/android_webview/OWNERS Records whether SafeMode was able to execute all the specified SafeMode actions or if it encountered an error. This is recorded once during WebView startup and only if SafeMode is enabled (see "Android.WebView.SafeMode.SafeModeEnabled"). If multiple fixes have different statuses, then this will log a single status in the following precedence: a. Unknown error b. Action failed c. Unrecognized action d. Success (If all actions were successful). ntfschr@chromium.org src/android_webview/OWNERS Records the time spent blocking WebView startup to both retrieve the list of SafeMode actions from the SafeModeService and to execute those actions. This is recorded once during startup only if SafeMode is enabled (see "Android.WebView.SafeMode.SafeModeEnabled"). This can be interpreted as the additional startup cost caused by enabling SafeMode. avvall@chromium.org src/android_webview/OWNERS Records whether or not the WebView nonembedded service receives a SafeMode fix configuration. This is recorded once for each SafeMode config the WebView receives. This only ever logs true since WebView won't need to log anything when safemode is not activated. This is only relevant for the app recovery activation pathway. ntfschr@chromium.org src/android_webview/OWNERS Records whether or not WebView is starting up in SafeMode. This is a mode where WebView takes extra steps during startup to reduce the risk of starting in a bad state. This is recorded once during WebView startup, regardless of whether SafeMode is enabled. ntfschr@chromium.org src/android_webview/OWNERS Records the action WebView took (if any) to "fix up" secure cookies for backwards compatibility. jdeabreu@chromium.org pbirk@chromium.org src/android_webview/OWNERS Records whether third party cookies are being accepted following every Android API call, initiated by the hosting Android app, to CookieManager.setAcceptThirdPartyCookies(). ntfschr@chromium.org src/android_webview/OWNERS Whether the network request was intercepted by the embedder of Android WebView. Intercepted requests are requests for which the shouldInterceptRequest() callback returned a non-null response. This is logged each time the shouldInterceptRequest() callback API is invoked by WebView, which corresponds to every network request. This histogram was added in M116. Prior milestones logged "Android.WebView.ShouldInterceptRequest.InterceptionType2", however that histogram further broke down the "intercepted == true" case by which URL scheme was used for the URL. alexmitra@chromium.org nator@chromium.org src/android_webview/OWNERS Records whether WebView is being run in a single process or multi-process. This is recorded each time logs are uploaded. This is used as a dashboard filter. mvanouwerkerk@chromium.org src/android_webview/OWNERS Measures the count of distinct sites visited per week in WebView. This is recorded at the time of a navigation when stored hashed site navigations are older than a week. The purpose of this metric is to slice it by package name to help characterize the usage of that package. This histogram uses eTLD+1 as the definition of a site. torne@chromium.org src/android_webview/OWNERS How long it takes to initialize a WebViewChromiumFactoryProvider. This is the first major phase of the WebViewChromium construction. torne@chromium.org src/android_webview/OWNERS How long it takes to initialize a WebViewProvider, the first time that one is initialized. WebViewProvider initialization is the second major phase of WebViewChromium construction. The first initialization is recorded separately because it is usually much slower than subsequent ones. torne@chromium.org src/android_webview/OWNERS How long it takes to initialize a WebViewProvider, the first time that one is initialized. WebViewProvider initialization is the second major phase of WebViewChromium construction. When it is not the first time, it is faster and thus recorded separately. torne@chromium.org src/android_webview/OWNERS How long it takes to run startChromiumLocked. torne@chromium.org src/android_webview/OWNERS The total time to initialize WebViewChromiumFactoryProvider. Reported on S+. This measurement is different from Stage1.FactoryInit as it takes into account time spent in framework. Does not overlap with Android.WebView.Startup.CreationTime.Stage2.* measurements. hazems@chromium.org src/android_webview/OWNERS Records the delay between calling Context#bindService until the ServiceConnection#onServiceConnected is called. This should give an idea of how long it takes for nonembedded service connections to be established and capture any regressions in this. In the case when a service connection is dropped and then reconnected by the system, the histogram is only recorded for the first connection. jdeabreu@chromium.org src/android_webview/OWNERS Records whether a given URL is allowed to be loaded by the current device user. This is based on a combination of a call to GMS Core, which checks if the url is allowed, and the setting AwFeatures.WEBVIEW_SUPERVISED_USER_SITE_BLOCK, which determines if we actually block urls or only log the results. jdeabreu@chromium.org src/android_webview/OWNERS Records the time taken to return from the call to GMS Core that checks if a given URL is allowed to be loaded by the current device user. pbirk@chromium.org src/android_webview/OWNERS Records whether the WebViewClient provided by the app is an instance of WebViewClientCompat (and therefore exposes AndroidX callbacks). This is recorded each time the app sets a new WebViewClient via WebView#setWebViewClient(). ntfschr@chromium.org src/android_webview/OWNERS The version of the target SDK of the app WebView is running in. This is recorded once during startup. torne@chromium.org src/android_webview/OWNERS Records when we allow a cross origin push state from a file URL solely because AllowUniversalAccessFromFileURLs is enabled. This is logged from the implementation of history. torne@chromium.org src/android_webview/OWNERS Records when we allow a cross origin push state from a file URL solely because AllowUniversalAccessFromFileURLs is enabled. This is logged from the implementation of the frame renderer. This metric was expired between June 4-23, 2023 and may be missing data. victortan@chromium.org torne@chromium.org src/android_webview/OWNERS Records when we propagate user-agent client hints metadata in different cases. This give us an idea to understand better how the user-agent metadata overrides and user-agent overrides work. This is recorded every time webview updates the user-agent or user-agent medatadata for the request. cduvall@chromium.org src/android_webview/OWNERS Records the length of the WebView variations header. Recorded every time WebViewCompat.getVariationsHeader() is called. mvanouwerkerk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records the global visibility state of WebView in seconds, updated with every Metrics upload. The Visible bucket counts total seconds that any WebView was visible (the view itself was visible, and was attached to the view hierarchy of a visible window). The NotVisible bucket counts time since WebView initialization for which no WebView was considered visible, or no WebView existed. The total of these two buckets reflects the amount of time covered by metrics collection. mvanouwerkerk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records per-WebView visibility duration in seconds, updated with every Metrics upload. The Visible bucket counts the total time in seconds that each WebView was considered visible (the view itself was visible, and was attached to the view hierarchy of a visible window). If more than one WebView is considered visible, then each WebView contributes independently. The NotVisible bucket counts the duration that each WebView exists but not in a visible state. As with the Visible bucket, each WebView contributes independently, and thus this bucket is not incremented when no WebViews exist. mvanouwerkerk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records the number of seconds any WebView was visible (the view itself was visible, and was attached to the view hierarchy of a visible window) with a particular URL scheme in the primary main frame. Updated with every Metrics upload. Note that the seconds are logged as the count for the scheme enum values. mvanouwerkerk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records the number of seconds each WebView was visible (the view itself was visible, and was attached to the view hierarchy of a visible window) with a particular URL scheme in the primary main frame. Updated with every Metrics upload. Note that the seconds are logged as the count for the scheme enum values. mvanouwerkerk@google.com ntfschr@chromium.org src/android_webview/OWNERS Records the number of seconds any WebView was visible (the view itself was visible, and was attached to the view hierarchy of a visible window) by screen coverage percentage. The screen coverage of all WebViews is merged so overlaps do not count more than once and do not increase the percentage. Updated with every Metrics upload. Not recorded when there is no visible WebView. Fractional percentages are rounded down. Note that the seconds are logged as the count for the percentages. mvanouwerkerk@google.com ntfschr@chromium.org src/android_webview/OWNERS Records the number of seconds each WebView was visible (the view itself was visible, and was attached to the view hierarchy of a visible window) by screen coverage percentage. The screen coverage of these WebViews is not merged. Updated with every Metrics upload. Not recorded when there is no visible WebView. Fractional percentages are rounded down. Note that the seconds are logged as the count for the percentages. mvanouwerkerk@google.com ntfschr@chromium.org src/android_webview/OWNERS Records the number of seconds each WebView was visible (the view itself was visible, and was attached to the view hierarchy of a visible window) with a {scheme} scheme in the primary main frame by screen coverage percentage. The screen coverage of these WebViews is not merged. Updated with every Metrics upload. Not recorded when there is no visible WebView. Fractional percentages are rounded down. Note that the seconds are logged as the count for the percentages. Deprecated in March 2022. idries@google.com ntfschr@chromium.org peconn@chromium.org src/android_webview/OWNERS Records the number of seconds that WebView is displaying Open Web Content for each bucket of screen proportion, updated with every Metrics upload. For the purposes of bucketing this is rounded down. A separate bucket is used when the screen coverage is exactly zero. wylieb@chromium.org fgorski@chromium.org Counts occurences of various events related to the Search Engine Logo feature. When enabled, the feature will show the logo of the default search engine in the omnibox. These events record the performance of fetching non-Google logos. peconn@chromium.org peter@chromium.org Logs which way had the user navigated into settings screens when they press "Clear and Reset" button in settings of a single website.