madhavpruthi@google.com ckitagawa@google.com clank-tab-dev@google.com Captures the number of regular and incognito pinned tabs used. Pinned tabs used are calculated by identifying the number of pinned tabs that were selected between ChromeTabbedActivity onResumeWithNative() and onStopWithNative(). This is recorded when onStopWithNative() is called. 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. madhavpruthi@google.com ckitagawa@google.com clank-tab-dev@google.com Captures the percentage of regular and incognito pinned tabs used. This is calculated by finding the ratio of the number of pinned tabs used to the total number of pinned tabs available between ChromeTabbedActivity onResumedWithNative and onStopWithNative. Total number of pinned tabs available is the sum of the pinned tab count when CTA is resumed and any new tabs that are pinned before CTA is stopped. This is recorded when ChromeTabbedActivity#onStopWithNative() is called. 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. bttk@chromium.org chrome-segmentation-platform@google.com Reports the variant of the optional toolbar button used during the session. 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. mfiaz@google.com clank-tab-dev@google.com Records the time taken for ActiveTabAvailable() to be called after the app is launched. 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. agazal@google.com jhimawan@google.com twellington@google.com The duration a user spends in the Play Store In-App Review flow. Measured from the moment the review UI is launched until the flow finishes, excluding the initial silent API request latency. Used to proxy user engagement (dismissal vs. rating vs. review). Recorded only when the Play Store API returns a success status. agazal@google.com jhimawan@google.com twellington@google.com Records that Chrome attempted to launch the App Rating Prompt using the Play Store In-App Review API. This acts as the denominator for funnel analysis, ensuring we can track silent failures where the Play Store API never returns a callback. Recorded immediately before invoking the Play Store API. agazal@google.com jhimawan@google.com twellington@google.com Records the outcome of attempting to show the App Rating Prompt using the Play Store In-App Review API. This indicates whether the flow was successfully requested or failed due to a technical error (e.g. Play Store not found, internal error). Recorded on every API callback. salg@google.com ssid@google.com Records whether the current web page URI was attached to an AssistContent object when assistant was invoked while ChromeActivity was in the foreground. salg@google.com ssid@google.com Records whether enterprise info was cached while trying to populate an AssistContent when assistant was invoked while ChromeActivity was in the foreground. If false we don't populate AssistContent. Only recorded when the "PageContentProvider" feature is enabled and assistant is invoked while viewing a web page. Warning: this histogram was expired from 2025-06-01 to 2025-11-25; data may be missing. salg@google.com ssid@google.com Records whether PDF structured data was successfully attached to an AssistContent object when assistant was invoked while ChromeActivity was in the foreground. Only recorded when the "AndroidPdfAssistContent" feature is enabled and assistant is invoked while viewing a PDF. salg@google.com ssid@google.com Records whether web page structured data was successfully attached to an AssistContent object when assistant was invoked while ChromeActivity was in the foreground. Only recorded when the "PageContentProvider" feature is enabled and assistant is invoked while viewing a web page. Warning: this histogram was expired from 2025-06-01 to 2025-11-25; data may be missing. salg@google.com ssid@google.com Records whether a JSON string with ContentProvider URIs was attached to an AssistContent object when assistant was invoked while ChromeActivity was in the foreground. Recorded when an assistant is invoked while viewing a non-incognito http/s web page. salg@google.com ssid@google.com tivi@google.com Records events related to WebPageContentProvider as it generates a URI for {Consumer} and as it handles queries from said external app. Recorded when {Consumer} requests {Format} with a {RequestType}. salg@google.com ssid@google.com tivi@google.com Records events related to WebPageContentProvider as it generates a URI for {Consumer} and as it handles queries from said external app. salg@google.com ssid@google.com Records whether we were able to get the package name of the default assistant app from Android's settings. Recorded when AssistContent is requested for web pages. Warning: this histogram was expired from 2025-09-07 to 2025-11-25; data may be missing. salg@google.com ssid@google.com tivi@google.com Records the amount of time passed between sending a web page content provider URI to {Consumer} and receiving a query from {Consumer} with the same URI (this starts a content extraction task). salg@google.com ssid@google.com tivi@google.com Records the amount of time passed while extracting a web page's contents for {Consumer}. salg@google.com ssid@google.com tivi@google.com Records the total amount of time passed between sending a web page content provider URI to {Consumer} and it receiving the web page's contents. salg@google.com tivi@google.com Records whether the targetPackage argument is non-null when AssistContent is requested for web pages. A false value means the default assistant package will be used. clhager@google.com twellington@chromium.org Records action user took when presented with the device lock explainer dialog (ex: button clicked) during a {Source} flow. Other actions such as clicking back on the automotive toolbar or clicking outside of the dialog to escape it can be calculated by subtracting button clicks from number of times the dialog was shown. twellington@chromium.org clhager@google.com Records whether the user successfully passed the device lock challenge after having seen the automotive device lock explainer dialog. twellington@chromium.org clhager@google.com Records an event whenever the missing device lock dialog is shown to the user or the user takes an action on the dialog. twellington@chromium.org clhager@google.com Records whether the automotive device has a device lock set when Chrome is resumed. twellington@chromium.org clhager@google.com Records the scaling factor applied to the UI on an automotive device. This value is recorded once per activity start as a percentage, with 134% being the default scale-up. 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. Cached when the task is scheduled. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been canceled. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that a specific task has been created with an expiration deadline. Cached when the task is scheduled. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that a specific task has been created without the expiration feature activated. Cached when the task is scheduled. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nator@chromium.org knollr@chromium.org shaktisahu@chromium.org Records that a specific background task has expired. Cached before the task is to be started. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. 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. Differs from other Android.BackgroundTaskScheduler histograms in that it is recorded immediately in background, instead of in the next time Chrome is run in foreground, so cannot be directly compared. hnakashima@chromium.org smaier@chromium.org Records that a specific background task has finished. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. Differs from "TaskFinished" in that it is recorded in the same session as "TaskStarted", making them comparable for success rate calculations and ensuring they are in the same experiment group (which is not the case for "TaskFinished"). nyquist@chromium.org shaktisahu@chromium.org Records that a task extending a NativeBackgroundTask started loading the native portion of Chrome. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has failed to be scheduled. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been successfully scheduled. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. nyquist@chromium.org shaktisahu@chromium.org Records that a specific background task has been started. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. 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. Cached to SharedPreferences to be recorded in the next ChromeActivity start instead of recorded immediately on background. eleanorlee@google.com clank-app-team@google.com Recorded when a user navigates to a URL by a navigation gesture or a navigation button and then a backfalsing event happens. Recorded for both swipes and clicks in both 3-button mode and gesture navigation mode. adelm@google.com mschillaci@google.com twellington@google.com 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. eleanorlee@google.com clank-app-team@google.com Records any incorrect edge swipes the user tries to perform. Recorded in 3-button mode when the user tries to swipe from the forward edge and the page is not navigable, such as when the forward stack is empty. Android only. eleanorlee@google.com clank-app-team@google.com Records the consecutive number of incorrect edge swipes the user tries to perform if the number of incorrect edge swipes are greater than zero. Recorded in 3-button mode when the user makes a correct edge swipe, which is when the user swipes from either the right edge or the left edge and the page is navigable. Android only. mschillaci@google.com adelm@google.com src/chrome/browser/back_press/android/OWNERS Recorded when a specific feature intercepted the system's back press gesture{Direction}. mschillaci@google.com adelm@google.com 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. mschillaci@google.com adelm@google.com src/chrome/browser/back_press/android/OWNERS Records that the custom tabs back press causes the app to be minimized or the current tab to be closed {Task}. eleanorlee@google.com clank-app-team@google.com Another version of Android.BackPress.Backfalsing2 with strict definition of "Backfalsing". Recorded when a user navigates to a URL by a navigation gesture or a navigation button and then a backfalsing event happens within **3 seconds**. Recorded for both swipes and clicks in both 3-button mode and gesture navigation mode. mschillaci@google.com adelm@google.com src/chrome/browser/back_press/android/OWNERS Record the edge from which the gesture is swiped from {Type}. mschillaci@google.com adelm@google.com src/chrome/browser/back_press/android/OWNERS Record the type of tab closure caused by back press. Record when tab is about to be closed. 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. mklw@google.com clank-large-form-factors@google.com Records the result of the 'Bookmark all tabs' action from either the tab strip context menu or keyboard shortcut. Recorded when the user activates the action. We track this to monitor the failure rate of this action and the reason of failure (null tab model, empty tab list). madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the reason why AI Mode was evaluated and determined to be ineligible or not shown in the Android Bottom Bar. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the result of attempting to launch AI Mode when the AI Mode button is pressed in the Android Bottom Bar. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the time taken to evaluate and decide the candidate extra action (GLIC or AI Mode) in the bottom bar. This includes the time spent in GlicEnabling and geofencing checks. Recorded when the candidate extra action resolution is evaluated. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the candidate action resolved for the Android Bottom Bar's extra button container slot (None, Glic, or Aim). Recorded when the candidate resolution is computed. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the visual state of the Glic button in the bottom bar at the moment the user clicks it. Recorded only for the bottom bar entry point. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Recorded when the Glic button is clicked in the bottom bar and toggles the panel. Tracks whether the panel was opened or closed. Recorded only for the bottom bar entry point. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the reason why Glic was evaluated and determined to be ineligible or not shown in the Android Bottom Bar. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Records the time elapsed from when the bottom bar becomes visible to when the GLIC button actually appears (transitions from hidden to visible). Recorded when the GLIC button becomes visible if the bottom bar was already shown. Recorded only the first time it appears after the bottom bar is shown. madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Recorded when the {IPHType} In-Product Help (IPH) in the Android Bottom Bar triggers (is shown or dismissed). madhavpruthi@google.com ckitagawa@chromium.org polardz@google.com Recorded when the introductory promo dialog for the Android Bottom Bar is shown, accepted, or dismissed. pnoland@chromium.org wenyufu@chromium.org ender@google.com Records the number of visible bottom controls layers. Recorded when a navigation finishes in the main frame of the active tab. Note: There is a recording gap between: 2026.01-2026.08. pnoland@chromium.org wenyufu@chromium.org ender@google.com Records the percentage of the window's total height used by the bottom controls stack at full height. This is the maximum % the window is obscured by the bottom controls, which can ordinarily be scrolled off. Recorded when a navigation finishes in the main frame of the active tab. pnoland@chromium.org wenyufu@chromium.org ender@google.com Records the percentage of the window's total height used by the bottom controls stack at its minimum height. This is the minimum % the window is obscured by the bottom controls, which cannot ordinarily be scrolled off. Recorded when a navigation finishes in the main frame of the active tab. hitarthkothari@google.com mfiaz@google.com ckitagawa@chromium.org Recorded every time a Bottom Sheet is closed or collapsed back to the peeking state. Records the specific reason for closure (e.g. swipe, back press, tap scrim, close button). hitarthkothari@google.com mfiaz@google.com ckitagawa@chromium.org Recorded every time any Bottom Sheet is opened and expanded beyond the peeking state. This includes all types of bottom sheet content without differentiation. wenyufu@chromium.org clank-app-team@google.com Records whether browser controls is forced to be visible by the tab state when controls visibility is updated. Recorded at TabStateBrowserControlsVisibilityDelegate.enableHidingBrowserControls(). skym@chromium.org pnoland@chromium.org ender@google.com Records if the outstanding navigations set changed when a navigation is finished. This means the navigation id was not previously tracked, either because it never started or it already finished once. When things are working correctly, this should always be true. There are known tests and likely some real scenarios that currently violate this. skym@chromium.org pnoland@chromium.org ender@google.com Records if the outstanding navigations set changed when a navigation is started. This means the navigation id was previously tracked and then the same id was claimed to be started again. If things are working correctly, this metric should always be true. No existing violations of this are currently known. Note: There is a recording gap between: 2026.07-2026.08. skym@chromium.org pnoland@chromium.org ender@google.com Records the number of outstanding navigations that are blocking the browser controls from being scrollable. Recorded when a navigation completes. Typically the value should be 0 or maybe 1 for a very short amount of time. Large numbers here indicate there's a bug that's keeping the controls visible. wenyufu@chromium.org clank-app-team@google.com Records when browser controls constraint is set to "SHOWN", whether the render is capable to drive the browser controls show animation. The record is used for crbug.com/449011189. Recorded after native is fully initialized and when feature BrowserControlsRenderDrivenShowConstraint is enabled. peilinwang@chromium.org clank-app-team@google.com Only recorded when BrowserControlsScrollSnapAnimation is enabled, and when the layer tree instance isn't in viz. Records whether an existing animation was running when either a new browser controls snap/height animation was initiated, or when we attempt to reset an animation. alimariam@google.com dullweber@chromium.org chrome-browser-privacy-team@google.com This histogram records the time taken to destroy the android browsing data model wrapper with its contents. This is recorded each time the model is destroyed on the Java side when the destroy method is called. smaier@chromium.org Records when a child process (specifically a renderer) is started via the javaless code path on Android. kawasin@google.com yfriedman@chromium.org Records the delay from the first request in a batch to when the batch is flushed. This is recorded when the queue in BindingRequestQueue is flushed with at least one request. kawasin@google.com yfriedman@chromium.org Records the number of binding requests in a batch when the batch is flushed. This is recorded when the queue in BindingRequestQueue is flushed with at least one request. kawasin@google.com yfriedman@chromium.org Measures the duration of the ScopedServiceBindingBatch batching scope on the main thread. This metric is recorded when the batching scope is closed. This is recorded regardless of whether the service binding batching feature is enabled. ScopedServiceBindingBatch can be nested. This metrics measures the duration of the outermost batching scope. kawasin@google.com yfriedman@chromium.org Records the number of BindService.doBindService() calls. This is emitted every 5 minutes on Chrome on Android while in the foreground. kawasin@google.com yfriedman@chromium.org Records the number of {Type} calls. This is emitted every 5 minutes on Chrome on Android while in the foreground. kawasin@google.com yfriedman@chromium.org Records the latency from posting SetRenderProcessPriorityOnLauncherThread on the main thread to its execution complete on the launcher thread. It is recorded when SetRenderProcessPriorityOnLauncherThread is executed. This metrics is recorded on all Android clients. kawasin@google.com yfriedman@chromium.org Records the total number of service bindings for 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 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. kawasin@google.com yfriedman@chromium.org Records the number of {ChildProcessConnectionMetricsBindingState} service bindings for sandboxed ChildProcessConnections. 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. boliu@chromium.org yfriedman@chromium.org Record events in ChildProcessConnection. Recorded when the specific events happen. Note individual counts may or may not be independent or mutually exclusive; thus total count is meaningless. Counts can be compared with each other, or need to be normalized with something else (eg number of child process launches). boliu@chromium.org smaier@chromium.org Records the name of the fallback service that is used in ChildProcessConnection. This is recorded when a fallback to a different service happens. boliu@chromium.org kawasin@chromium.org yfriedman@chromium.org Record the accumulated count of ChildServiceConnectionDelegate.onServiceConnected. This is recorded every time the callback is triggered. The metric with number more than 1 indicates that the child process is restarted after the service process connected. Note that the lower buckets double-counts the higher buckets since this is recorded at each restart (e.g. when 4 is recorded, 1,2,3 are also recorded). kawasin@google.com clank-performance-team@google.com Records the number of child process connections that are classified as {RankType}. Whether the process is high rank or low rank is determined by ChildProcessRanking.shouldBeInLowRankGroup() This is recorded when the application is sent to the background. 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. twellington@chromium.org ender@google.com Records the failure reason for ChromeStartupDelegate requests. Recorded at most once on application startup. (Expired in 2022-12-25. Revived in 2025-01-07.) Note: There is a recording gap between: 2026.02-2026.08. twellington@chromium.org ender@google.com Records the result for ChromeStartupDelegate. Recorded on application startup. (Expired in 2022-10-16. Revived in 2025-01-07.) Note: There is a recording gap between: 2026.02-2026.08. ckitagawa@chromium.org clank-tab-dev@google.com Records the duration between requesting and starting the upload of a tab's context in the ComposeboxQueryController. Recorded whenever a tab with cached context is added as an attachment to a query. Only recorded when the retrieval from the cache is successful. ckitagawa@chromium.org clank-tab-dev@google.com Records the duration between requesting and starting the upload of a tab's context in the ComposeboxQueryController. Recorded whenever a tab without a cached context is added as an attachment to a query and the context must be extracted on-demand. Only recorded when the context extraction is successful. skym@chromium.org chrome-mobile-search@google.com Records the duration to construct the Java InputState object and dispatch onInputStateChanged from the C++ ComposeboxQueryControllerBridge. Recorded whenever the input state changes and is pushed to Java. wenyufu@chromium.org clank-app-team@google.com Records whether CopmositorSurfaceManager.requestSurface a surface with PixelFormat.OPAQUE when the method is called. Used to idicate how often an opaque SurfaceView is used. acondor@chromium.org clank-performance-team@google.com Records the duration of CompositorView::UpdateLayerTreeHost on Android, which updates the layer tree when a frame is requested. Subsampled to 1/100. 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. Warning: this histogram was expired from 2024-08-04 to 2026-02-17; data may be missing. finnur@chromium.org twellington@chromium.org Records which action the user takes in the ContactsPickerDialog. Measured once when the Contacts Picker dialog is dismissed. Warning: this histogram was expired from 2024-08-04 to 2026-02-17; data may be missing. 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. Warning: this histogram was expired from 2024-08-04 to 2026-02-17; data may be missing. 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. Warning: this histogram was expired from 2024-10-06 to 2026-02-17; data may be missing. 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. Warning: this histogram was expired from 2024-08-04 to 2026-02-17; data may be missing. 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. Warning: this histogram was expired from 2024-08-04 to 2026-02-17; data may be missing. tasak@google.com 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. 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. 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. xinyiji@chromium.org hanxi@chromium.org Records the total count of clicks on the default browser promo. Includes clicks on message banners, the Settings page promo card, and the Magic Stack (Educational Tip) module. For Message Banners, the metric triggers when the user clicks the "Settings" button. For Settings Page Promo Card, the metric triggers when the user clicks the "Open Settings" button. For Magic Stack (Educational Tip), the metric triggers when the user clicks the "Show me how" button. Android-only. eleanorlee@google.com twellington@chromium.org Records the default browser state of the user at the moment they click a Default Browser Promo entry point. This also records the volume of clicks (Engagement) for the {Source}. Recorded when the user clicks the AppMenu or Settings Menu item. twellington@chromium.org src/chrome/browser/ui/android/default_browser_promo/OWNERS The final default browser state (outcome) after the user has been prompted to set Chrome as the default when {CurrentState} is set as the default initially. Recorded when the system UI prompting the user to change their default is dismissed. twellington@chromium.org src/chrome/browser/ui/android/default_browser_promo/OWNERS The final default browser state (outcome) after the user has been prompted to set Chrome as the default when {CurrentState} is set as the default initially and the total promo count is {PromoCount}. Recorded when the system UI prompting the user to change their default is dismissed. eleanorlee@google.com twellington@chromium.org The final default browser state (outcome) after the user has been prompted to set Chrome as the default via the {Source}. twellington@chromium.org src/chrome/browser/ui/android/default_browser_promo/OWNERS Records the default browser state when the Android Q+ role manager dialog is shown. aishwaryarj@google.com clank-large-form-factors@google.com Records the result of the heuristics used to determine whether the app is in a desktop window. The histogram will be emitted only if the result changed since the last time it was emitted. This is to avoid emitting noisy data, since we believe that most of the conditions in these heuristics are unlikely to change for a given OS/OEM across these checks that may be relatively significantly larger in number. ioanap@chromium.org friedrichh@chromium.org 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). 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. renkens@google.com boliu@chromium.org Reports whether usage of the Display Topology Android API on this device is allowed (when AndroidUseDisplayTopology feature flag is enabled and the Android version provides the Display Topology API) or blocked. Recorded once in DisplayAndroidManager.initialize() every time Chrome on Android or Android WebView starts up. renkens@google.com boliu@chromium.org Emitted when DisplayListenerBackend.onDisplayAdded() reports a new sdkDisplayId whose Display descriptor is unexpectedly null. The value records whether that same sdkDisplayId is removed within the next 1 second: * true - DisplayListenerBackend.onDisplayRemoved() was invoked for the invalid sdkDisplayId within 1 s. * false — No removal occurred, or it happened after 1 s. Logged once for every onDisplayAdded() call in which the Display descriptor associated with the sdkDisplayId is null. jhimawan@google.com clank-downloads@google.com Records the target application used when a user opens a download on Android. Logged when a download open request is handled in the downloads UI or from notifications. 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). 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. This histogram was previously expired on 2023-07-09, and was re-enabled on 2024-02-12. shaktisahu@chromium.org clank-downloads@google.com Records the entry point for users opening downloaded files on Android, that are not audio nor video. Records how users open audio download files on Android. This histogram was previously expired on 2023-06-25, and was re-enabled on 2024-02-12. shaktisahu@chromium.org clank-downloads@google.com Records how users open video download files on Android. This histogram was previously expired on 2023-06-25, and was re-enabled on 2024-02-12. 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. qinmin@chromium.org clank-downloads@google.com Records the entry point for users opening the download page on Android. This histogram was previously expired on 2023-04-23, and was re-enabled on 2024-02-12. joelhockey@chromium.org clank-large-form-factors@google.com Records the number of files included in a drag-drop in chrome. It is recorded on the drop event for a web contents. Android only. 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 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. 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. aishwaryarj@google.com wenyufu@chromium.org clank-large-form-factors@google.com The number of times tab or group tearing failed for a user, because the maximum number of Chrome instances were open, in a 24-hour period. Recorded when the max-instance toast is shown when a dragged tab or group drop is unhandled at the max instance limit. shuyng@google.com zheliooo@google.com clank-large-form-factors@google.com Records the {TabObjectType} drag and drop results, including successful drops and failed drops with varied reasons. For failed drops, it is recorded during ACTION_DROP. For successful drops, it is recorded during ACTION_DRAG_ENDED. Note that the successful drops count can be recorded more often than Android.DragDrop.Tab.Type or Android.DragDrop.TabGroup.Type such as reorder within strip or tabs being consumed as text by EditText in native pages. shuyng@google.com zheliooo@google.com clank-large-form-factors@google.com Records {TabObjectType} drops into source strip with or without leaving the strip. True means the drag has left the source strip; while false means it does not. Recorded when drop into source strip. Used to determine the amount of accidental drag out of the strip. aishwaryarj@google.com wenyufu@chromium.org zheliooo@google.com clank-large-form-factors@google.com Records true when a {TabObjectType} drag/drop results in closing the source Chrome window because it was the last {TabObjectType} in the window, false when the drop does not close the source window. Only recorded when drag/drop is handled. shuyng@google.com zheliooo@google.com clank-large-form-factors@google.com Records the drag source and drop target when a {TabObjectType} is dropped successfully. mschillaci@google.com clank-large-form-factors@google.com On tablets, when the width of the tab strip passes a certain threshold, the tab strip will start a transition to show / hide it from the top toolbar. This records true when tab strip transition finishes successfully, or false when a new transition starts before an ongoing transition dispatched the finished signal. aishwaryarj@google.com wenyufu@chromium.org clank-large-form-factors@google.com Records the desktop windowing mode state when the Chrome window is resized on tablet or foldable devices. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records the source, if applicable, used to provide back-up navbar insets to the EdgeToEdgeController. The EdgeToEdgeController will request back-up insets once every time it receives a window inset update, if the navigation bar insets are 0. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records when the EdgeToEdgeControllerImpl notices a change when edge-to-edge is changed from a supported configuration into unsupported. Record the outcome combination of the original window insets, new window insets, and paddings applied to the content view. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records when the EdgeToEdgeControllerImpl handles insets and observes that the configuration seems to support edge-to-edge, but other inset signals (other than the supported configuration check) seem to disagree. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records when EdgeToEdgeControllerImpl#drawToEdge gets called on a device whose configuration does not support edge-to-edge, with the boolean record indicating whether drawToEdge was called due to a change in window state. clhager@google.com edge-to-edge@chromium.org Records if the current activity is eligible for drawing any content edge to edge based on the device configuration. Recorded on ChromeActivity launch. clhager@google.com edge-to-edge@chromium.org Records if the current activity is eligible for drawing any content edge to edge based on the device configuration. Recorded when the EdgeToEdgeController is created. clhager@google.com edge-to-edge@chromium.org Records the reason of why the current session is not eligibile for drawing any content edge to edge. Multiple reasons might be record for a single session. Recorded on ChromeActivity launch. clhager@google.com edge-to-edge@chromium.org Records the reason of why the current session is not eligibile for drawing any content edge to edge. Multiple reasons might be record for a single session. Recorded when the EdgeToEdgeController is created. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records once during the initialization of the EdgeToEdgeControllerImpl whether there were no navigation bar insets at all, which may indicate an incorrect value from the OS. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records when insets are updated and the mandatory system gestures insets seem to indicate the presence of a navigation bar, but the navigation bar insets (ignoring visibility) are zero. This is recorded up to three times per session: once if there's a mismatch in the first insets received by the app, once on the first time those mismatched insets are corrected (non-zero navbar insets), and once if insets are mismatched after non-zero navbar insets have been seen during the current session. The enum value also tracks the navigation mode (gesture, tappable) indicated by the insets, or if the insets are giving mixed signals on the navigation mode. clhager@google.com wenyufu@chromium.org edge-to-edge@chromium.org Records when the EdgeToEdgeControllerImpl notices a change in whether edge-to-edge is supported by the device configuration when it handles a change in window insets. This is recorded once every time a change is detected. 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 extension or web approval flow. Recorded on Android only. See go/chrome-local-approval-parent-auth-error-codes (Googlers only) for the error code definitions. amanvr@google.com nuskos@chromium.org Records whether the WebContents associated with the RenderWidgetHost responsible for handling input is focused specifically on TouchStart or GestureTap or MouseDown events. This histogram is recorded for each input event sequence on TouchStart/GestureTap/MouseDown input events. This would help us in understanding if focus changes on input events need to be handled by Viz once it starts receiving transferred input events after InputVizard (go/chrome-inputvizard). amanvr@google.com nuskos@chromium.org Tracks if the RenderWidgetHostViewChildFrame requests focus on the root RenderWidgetHostViewAndroid or not during the beginning of a touch interaction. This tracking occurs every time the function RenderWidgetHostViewChildFrame::PreProcessTouchEvent() is called when a touch sequence begins (on TouchStart). This would help us in understanding if focus changes on touch input events need to be handled by Viz once it starts receiving transferred input events after InputVizard (go/chrome-inputvizard). 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 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. ssid@google.com haileywang@google.com Records the user's action taken on the Glic promo bottom sheet. Emitted once each time the bottom sheet is closed, documenting whether the user accepted the promo, rejected it, or dismissed it (via swipe, back press, etc.). 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. {GridTabSwitcherAnimationType} 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. {GridTabSwitcherAnimationType} 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. ckitagawa@chromium.org clank-tab-dev@google.com Records the elapsed realtime in milliseconds between the tab switcher being shown and the tab state being initialized. This is not recorded if the tab state was already initialized. Recorded at most once per session once the tab state is initialized. zheliooo@google.com clank-large-form-factors@google.com Records whether Handoff is enabled for the current activity during {UpdateType}. Handoff is enabled if the user is in a normal tab (not incognito) and there is an active tab. ckitagawa@chromium.org clank-hub-dev@google.com Reports which pane in the Hub becomes focused when a request to change focus occurs. Focus may change either in response to user input on the pane switcher or programmatically as a side-effect of another user action. For example the see all tabs button on the Incognito reauth dialog. See "Android.Hub.PaneFocused.PaneSwitcher" if only interested in user actions on the pane switcher. ckitagawa@chromium.org clank-hub-dev@google.com Reports which pane in the Hub becomes focused when a request to change focus occurs in response to a user input on the pane switcher. This does not count programmatic pane switches triggered as a side effect of other user actions such as the back button, Incognito reauth dialog, etc. See "Android.Hub.PaneFocused" for all pane focus events. madhavpruthi@google.com ckitagawa@chromium.org The pane ID of the current pane when the user swipes {Direction} to navigate to the next pane. skym@chromium.org ckitagawa@chromium.org The shrink/expand animation is supposed to change the color of the toolbar. But there's currently a rare crash where the toolbar is not present. Either it hasn't been created yet or has already been torn down. This metric captures if the toolbar is present or not, which should help us measure the effectiveness of future mitigations. bjfong@google.com wylieb@google.com clank-hub-dev@google.com Reports under which context (incognito or non-incognito) and visual component (search box or loupe) Hub Search is entered through. This includes tablet specific data which only has the loupe icon enabled. arabm@google.com 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". zalmashni@google.com 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). lizeb@google.com clank-performance-team@google.com When a touch event is processed, what is the action associated with it. This is recorded only on Android (including WebView), at a subsampled rate. pasko@chromium.org mthiesse@chromium.org Every time the native message loop yields to the Looper record whether it dispatches some input event referring to touch in the content area before returning back to the native message loop. The latter scenario may mean that the touch event was dispatched to the Android UI views. Alternatively, it can happen when the Looper decided to run the message loop handler first. pasko@chromium.org mthiesse@chromium.org Records the status of the InputHintChecker initialization. This initialization procedure is required to be able to later poll for availability of unhandled input events queued. Recorded immediately after finishing the initialization, which should happen once during early browser process initialization. A failure may be recorded after initialization succeeds (which itself records a sample) if reading the input hint fails. In this case only the first failure is recorded. Note: This metric became randomly subsampled in M136 (136.0.7064.0) to reduce overhead. The low data volume warning on the dashboard for this transition can be ignored. kartarsingh@google.com woa-performance-team@google.com The metric is only recorded when touch sequence is successfully transferred from Browser to Viz(when InputOnViz feature flag is enabled). The histogram is emitted for discrete events seen between inital DOWN on which transfer was requested, and the CANCEL received corresponding to DOWN from Android, excluding both of these events. kartarsingh@google.com woa-performance-team@google.com The metric is recorded when a touch sequence in Browser fails to transfer while while there's a potentially ongoing touch sequence on Viz. The metric records the type of event that was dropped. amanvr@google.com kartarsingh@google.com woa-performance-team@google.com Logged whenever an ACTION_UP event is received on Browser while in kConsumeEventsUntilCancel state. This indicates that the OS transferred a different touch sequence than the one Chrome requested. kartarsingh@google.com woa-performance-team@google.com The metric is recorded when a touch sequence in Browser fails to transfer while while there's a potentially ongoing touch sequence on Viz. The metric records the number of events lost in such cases. kartarsingh@google.com woa-performance-team@google.com Records the reason a touch sequence was dropped on browser process while InputOnViz was enabled. A dropped touch sequence would have not have any affect on web contents, the input events never get transferred over to Renderer for such a sequence. The histogram is emitted every time a touch sequence is dropped on Browser procoess due to various reasons, when InputOnViz feature is enabled. `Android.InputOnViz.Browser.EventTypesInDroppedSequence` and `Android.InputOnViz.Browser.NumEventsInDroppedSequence2` could be used to know what type of events exist in dropped sequences and the number of events in these dropped sequences. kartarsingh@google.com woa-performance-team@google.com The metric is only recorded when touch sequence is successfully transferred from Browser to Viz(when InputOnViz feature flag is enabled). It records the number of touch moves received on Browser before receiving a TOUCH_CANCEL, which would be the last event Browser sees for that sequence after a successful transfer. kartarsingh@google.com amanvr@google.com woa-performance-team@google.com The metric is only recorded when transfer of input sequence from Browser to Viz is supported. It records the result of transferring input sequence from Browser. The sequence can be handled by Browser/Viz based on various factors like if Ime is active, or touch selection is active, etc. V2 adds the kSharedMemoryUnavailable and kPositiveEventAndDownTimeDelta bucket. kartarsingh@google.com woa-performance-team@google.com Records result of InputReceiver creation on Viz. When Android returns null pointer to some of the API calls made, input receiver creation API call cannot be issued. This histogram tracks if input receiver creation was successful or failed due to some reason. kartarsingh@google.com woa-performance-team@google.com Records the type of key event as gotten from `AInputEvent_getType` Android NDK API. Viz is not exepcted to receive key events, but in practice it does due to races in focus handling at startup. All the key events received on Viz are dropped and reported in this histogram. kartarsingh@google.com woa-performance-team@google.com Records the actions of input events that were dropped on Viz due to lack of implementation. Viz expects to only handle touch events which means it doesn't expect to see actions like button down/release. kartarsingh@google.com woa-performance-team@google.com For dropped touch sequences, records the delta between event time and down time for the ACTION_DOWN event. This is recorded when a touch down for a sequence is dropped on Viz. kartarsingh@google.com woa-performance-team@google.com When `InputOnViz` is enabled Browser process sends state on TouchDown to Viz in case touch transfer was successful. In theory, due to hiccups in system we can have multiple pending states on Viz. This metric records the number of pending states on Viz when {CurrentState}. This would help us verify if we have pending states in practice as well. kartarsingh@google.com woa-performance-team@google.com Viz side variant of `Android.InputOnViz.Browser.SequenceDroppedReason3` histogram. The metric records whenever a touch sequence is dropped on Viz side. kartarsingh@google.com woa-performance-team@google.com Records what happened to state received on Viz, upon successful transfer of a touch sequence the Browser process sends over touch transfer state for Viz to handle input sequence. Compared to `Android.InputOnViz.Viz.StateProcessingResult2`, version 3 of histogram further splits some of the `ProcessedSuccessfully` cases into `TransferBackToBrowserSuccessfully` and `DroppedTransferBackToBrowserFailed` buckets. peconn@chromium.org webview-team@google.com Time spent on the final call to getByteArrayRegion when copying data from the InputStream. Recorded when the InputStream is destroyed. peconn@chromium.org webview-team@google.com Time spent on all calls to getByteArrayRegion when copying data from the InputStream. Recorded when the InputStream is destroyed. peconn@chromium.org webview-team@google.com Total wall clock time spent reading from the Java InputStream into the temporary buffer. Recorded when the InputStream is destroyed. peconn@chromium.org webview-team@google.com Records how much data has been transferred through embedder_support::InputStream. Recorded when that object is destroyed. peconn@chromium.org webview-team@google.com Sum total of the wall clock time spent in all InputStream::Read calls. Recorded when that object is destroyed. philyan@chromium.org skavuluru@google.com Records the outcome of attempting to bring a tabbed activity to the front using a multi-window intent. This helps track the success rate and failure reasons of the MoveToFrontInLaunchIntentDispatcher feature. katzz@google.com chrome-connective-tissue@google.com Android only. Boolean histogram denoting whether the package name can be retrieved in a non-spoofable way from the View Intents sent to Chrome. When the histogram returns true, it means we can confirm the package name was passed by the defined host app. Emitted upon launching the tabbed Chrome Activity via View Intent. jinsukkim@google.com chrome-connective-tissue@google.com Android only. Boolean histogram denoting whether the package name is available by the sender sharing its identity using the new API introduced in Android U. This means we can confirm the package name was passed by the defined host app. Emitted upon launching the tabbed Chrome Activity via View Intent. nafisabedin@google.com mthiesse@chromium.org yfriedman@chromium.org Records whether a tab was created due to an external app to launch an intent for an external app. The false counts, and thus the PDF, for this metric is not meaningful. Instead, utilize the true counts with another such as MobileStartup.LaunchCause.EXTERNAL_VIEW_INTENT as the denominator to determine the proportion of redirects. mthiesse@chromium.org yfriedman@chromium.org Records the duration of a deferred navigation due to the InterceptNavigationThrottle, every time a navigation is deferred. At time of writing, this can only be caused by the ExternalNavigationHandler on Android, and should only happen when background/early navigations redirect. philyan@chromium.org skavuluru@google.com Records the reason for early failure when launching an intent into an existing multi-window instance. Recorded only when an early failure occurs. philyan@chromium.org skavuluru@google.com Records the success or failure of attempting to bring a task to the front using the {Api} API path. 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. mthiesse@chromium.org yfriedman@google.com Records whether, and why, we used a trusted referrer on an Intent coming from another app. 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. {AndroidFeatureModuleName} cduvall@chromium.org agrieve@chromium.org smaier@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. Different from ContextCreateTime as only the first load of a split will be counted. {AndroidFeatureModuleName} cduvall@chromium.org agrieve@chromium.org smaier@chromium.org Amount of time it takes to create a new Context and load a class for a split. This is simply ContextCreateTime2 + LoadFirstClassTime. {AndroidFeatureModuleName} cduvall@chromium.org agrieve@chromium.org smaier@chromium.org Amount of time it takes to load the first class in a split. This will only be recorded if there is a hardcoded class to load in SplitChromeApplication. Happens right after the Context is created. {AndroidFeatureModuleName} cduvall@chromium.org agrieve@chromium.org smaier@chromium.org Amount of time spent waiting for a split preload task to finish. This will only be recorded if isolated splits are enabled. This histogram was expired between 2023-11-12 and 2024-08-23. {AndroidFeatureModuleName} 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. shuyng@google.com clank-large-form-factors@google.com Records failures when trying to update dynamic shortcuts in LauncherShortcutActivity. Recorded when setDynamicShortcuts is rate-limited or exceeds the maximum number of shortcuts. ziadyoussef@chromium.org src/android_webview/OWNERS woa-performance@google.com The time for prefetching the native library code to memory. Recorded once per process start when prefetching is used. ashleynewson@chromium.org src/android_webview/OWNERS woa-performance@google.com Time taken to perform the fork() call in the library prefetcher when using the PrefetchWithFork strategy. This measures the duration of the clone syscall from the parent process, not the lifetime of the child process. The whole parent process (not just the calling thread) can be blocked for this duration, so this can represent a delay in startup. This is emitted regardless of whether the fork/prefetch succeeds, though it is extremely rare for the fork itself to fail (see the .Status histogram). Emitted during native library prefetch (normally in renderer process init), only for Android WebView and only when the LibraryPrefetcherMadvise feature is disabled. ashleynewson@chromium.org src/android_webview/OWNERS woa-performance@google.com True iff madvise MADV_WILLNEED is supported (and will be used to prefetch the native library). Does not state whether madvise was successful for the actual prefetch (see Android.LibraryLoader.Prefetch.Status instead.) Emitted during native library prefetch (normally in renderer process init), only for Android WebView and only when the LibraryPrefetcherMadvise feature is enabled. ziadyoussef@chromium.org src/android_webview/OWNERS woa-performance@google.com Reports the result of prefetching native code into memory. Recorded once per process start when prefetching is used. chikamune@chromium.org chrome-loading@google.com clank-app-team@google.com Measures how long the MaybeCopyContentAreaAsBitmap function takes. This is emitted only when a navigation entry screenshot is captured. 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. 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} aishwaryarj@google.com src/components/messages/OWNERS Records the message identifier when the message is dismissed without being fully visible before. This only tracks the case in which message is dismissed by primary action, secondary action, gesture and timer. aishwaryarj@google.com 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. aishwaryarj@google.com 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. aishwaryarj@google.com 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. aishwaryarj@google.com 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. aishwaryarj@google.com src/components/messages/OWNERS Records the message identifier every time it becomes fully visible to users. Can be recorded multiple times during its lifetime. aishwaryarj@google.com 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.). aishwaryarj@google.com src/components/messages/OWNERS Recorded once per message measuring the duration from the moment it is enqueued to the first time it becomes fully shown. Recorded when the message becomes fully shown. rathomas@google.com clank-large-form-factors@google.com The maximum number of active 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. 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. shuyng@google.com skavuluru@google.com mklw@google.com clank-large-form-factors@google.com The maximum number of Chrome Incognito-only 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. zheliooo@google.com aishwaryarj@google.com clank-app-team@google.com The total number of attempts made to migrate multi-instance data from SharedPreferences to Protobuf. Recorded when the migration successfully completes, or when it reaches the terminal attempt limit (3) and gives up. 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. aishwaryarj@google.com wenyufu@chromium.org clank-large-form-factors@google.com Records the number of running ChromeTabbedActivity's on every ChromeTabbedActivity startup in a desktop window. 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 V+ only. shuyng@google.com skavuluru@google.com mklw@google.com clank-large-form-factors@google.com Records the number of running Incognito-only ChromeTabbedActivity's on every ChromeTabbedActivity startup in a desktop window. 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 V+ only. shuyng@google.com skavuluru@google.com mklw@google.com clank-large-form-factors@google.com Records the number of running Incognito-only 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. aishwaryarj@google.com wenyufu@chromium.org clank-large-form-factors@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 in a desktop window. Applicable to Android V+ only. shuyng@google.com skavuluru@google.com mklw@google.com clank-large-form-factors@google.com The number of allocated Incognito-only 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 in a desktop window. Applicable to Android V+ only. shuyng@google.com skavuluru@google.com mklw@google.com clank-large-form-factors@google.com The number of allocated Incognito-only 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. clhager@google.com twellington@google.com clank-app-team@google.com The result of comparing the saved ID of the persistent state received in #onCreate() with the latest ID saved for the persistent state associated with that instance. This verification informs whether the OS has passed the same persistent state to the app after recreation that the app passed to the OS when the original instance was stopping for a device reboot or app update. A mismatch in IDs could indicate an OS bug resulting in the persistent state passed to the app being outdated. Note that only the ID is checked as a proxy for the bundle contents, the contents themselves are not verified. aishwaryarj@google.com wenyufu@chromium.org clank-large-form-factors@google.com Records the desktop windowing mode state when the Chrome window manager is opened from the app menu. ckitagawa@chromium.org yfriedman@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. aishwaryarj@google.com zheliooo@google.com clank-large-form-factors@google.com Records the time it takes to successfully recover all windows from the previous Chrome session after an app crash, when the user opts to restore all windows from the recovery prompt. aishwaryarj@google.com zheliooo@google.com clank-large-form-factors@google.com Records the number of windows that were active at the time of a crash, determined from the crash recovery data. Recorded when the first ChromeTabbedActivity starts up in a new browser process after an unclean app exit is detected. kalutes@google.com clank-large-form-factors@google.com Records the duration of the calculateOcclusion function in WindowOcclusionTracker. Emitted when window position changes or windows are redrawn. kalutes@google.com clank-large-form-factors@google.com Records the result of WindowOcclusionTracker calculateOcclusion operation. Emitted when window position changes or windows are redrawn. kalutes@google.com clank-large-form-factors@google.com Records the number of times WindowOcclusionTracker recalculates occlusion over the preceding 5 minutes. Emitted every 5 minutes while occlusion tracking is active. kalutes@google.com clank-large-form-factors@google.com Records the result of WindowOcclusionTracker track operation. Emitted when a new window is created. False if the root view could not be found, true on success. kalutes@google.com clank-large-form-factors@google.com Records the result of WindowOcclusionTracker untrack operation. Emitted when a window is destroyed. False if the root view could not be found, true on success. kalutes@google.com clank-large-form-factors@google.com Records the number of displays being tracked for WindowZOrderTracker. Recorded every 5 minutes. kalutes@google.com clank-large-form-factors@google.com Records the number of times a window was promoted to the top of the z-order by WindowZOrderTracker over the preceding 5 minutes. Recorded every 5 minutes while occlusion tracking is enabled. kalutes@google.com clank-large-form-factors@google.com Records the number of activity top resumed state transitions handled by WindowZOrderTracker over the preceding 5 minutes. Recorded every 5 minutes while occlusion tracking is enabled. kalutes@google.com clank-large-form-factors@google.com Records the number of windows tracked by WindowZOrderTracker. Recorded every 5 minutes. 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. wenyufu@chromium.org aishwaryarj@google.com clank-large-form-factors@google.com When the TabWindowManager allocates a different tab model index than the window Id selected by MultiInstanceManagerApi31, it means the requested tab model Id was assigned to a different Activity. When this mismatch happened, record whether the activity at the requested index is finishing, whether it is in the same task as the new activity, and if it's still visible in ActivityManager#getAppTasks. Record "Unknown" if the activity cannot be found. Recorded when the mismatched index for the new activity is {ActivityIndexMismatchAssignmentState}. aishwaryarj@google.com clank-large-form-factors@google.com Records the source of instance closure, emitted when permanent instance state deletion is requested. Note that this does not account for Android system-initiated closures or closures due to user actions on system UI. aishwaryarj@google.com clank-large-form-factors@google.com Records the configuration of the window that the app is running in. The histogram will be emitted when a window is created, and when the windowing mode changes. Recorded for tablet form factors only when desktop windowing is supported. aishwaryarj@google.com wenyufu@chromium.org clank-large-form-factors@google.com Recorded when a new Chrome window is created from a dragged tab. The histogram records true when the dragged tab is successfully reparented to the new window, false when the reparenting of the dragged tab is not done. aishwaryarj@google.com clank-large-form-factors@google.com Records the source of inactive instance restoration in a new activity. aishwaryarj@google.com rathomas@google.com clank-large-form-factors@google.com Records trigger source when a new window creation is requested. chominskib@google.com lt-web-apps-team@google.com After a contextual popup is spawned we may adjust its bounds so that size of the website viewport is as requested by the caller in the |window.open()| Javascript call. This records whether the absolute difference in {Axis} between initial popup bounds and adjusted popup bounds was zero pixels. The popup was opened on {CrossDisplay} its originating window. chominskib@google.com lt-web-apps-team@google.com After a contextual popup is spawned we may adjust its bounds so that size of the website viewport is as requested by the caller in the |window.open()| Javascript call. This records the absolute difference in {Axis} between initial popup bounds and adjusted popup bounds. Records only positive differences. The popup was opened on {CrossDisplay} its originating window. chominskib@google.com lt-web-apps-team@google.com Records the outcome of a |window.open()| JavaScript call that should open a new popup window. Recorded only when the |window.open()| call is guaranteed to be executed one way or another (i.e. does not record anything when popup blocker drops the request). If the popup is not opened in a new window, it is most likely opened as a new tab. rathomas@google.com clank-large-form-factors@google.com Total time spent in {WindowingMode} mode in a given 24-hour period. The histogram will be emitted for a previous emission cycle when an activity in any windowing mode is stopped after more than 24 hours have elapsed since the start of this emission cycle. sisidovski@chromium.org chrome-loading@google.com Records the duration of the didFinishNavigationInPrimaryMainFrame event dispatching to Java-side WebContentsObservers. Recorded on the browser main thread when a primary main frame navigation finishes (committed, aborted, or replaced). 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. gjc@google.com chrome-loading@google.com chrome-brapp-loading@google.com Records time between the intent that triggered an Omnibox navigation on Android to the time the Omnibox code calls into the shared C++ navigation code (NavigationController). The UMA is recorded each time a URL is loaded in the NavigationController with a valid intent received timestamp. gjc@google.com chrome-loading@google.com 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). The UMA is recorded each time a URL is loaded in the NavigationController with a valid input start timestamp. spelchat@chromium.org gjc@google.com chrome-loading@google.com 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). The UMA is recorded each time a URL is loaded in the NavigationController with a valid input start timestamp. Compared to InputToNavigationControllerStart2, this metric filters out cases where the input start timestamp is 0, which can happen for some browser-initiated navigations (e.g. opening URL in a new tab). ender@google.com 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 Records the JumpStart feature eligibility and user preference state during cold start. Logged once per cold start. Note: There is a recording gap between: 2026.07-2026.08. skym@chromium.org chrome-mobile-search@google.com Records the duration of reanchorViewsForCompactFusebox in FuseboxViewBinder when updating layout constraints. Recorded each time the binder reanchors views. skym@chromium.org chrome-mobile-search@google.com Records the trigger source when setting the active model (or skipping setting when redundant) on the Composebox query controller in Fusebox. 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. Note: There is a recording gap between: 2026.07-2026.08. 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. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com 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. ender@google.com chrome-mobile-search@google.com Records whether intent is updating an already present activity. For the most part the expected value here is 'false', indicating that the intent was starting a new session. A value of 'true' indicates that the SearchActivity was already focused and running when a new intent was received. Such intent would need to be emitted while SearchActivity is in foreground. Recorded once per intent. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com chrome-mobile-search@google.com Record the origin of an intent (i.e. from where the SearchActivity was called). Recorded once per intent. ender@google.com chrome-mobile-search@google.com Records whether intent used to launch / update SearchActivity carried an (optional) User Query. Recorded once per intent. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com chrome-mobile-search@google.com Records the intended navigation search target type for every navigation initiated from the SearchActivity. Captures the {IntentOrigin} specific SearchActivity metrics. Recorded exactly once per user initiated navigation. Not recorded if the user abandons SearchActivity. ender@google.com chrome-mobile-search@google.com Records whether Intent Referrer field was valid for Searches initiated from SearchActivity. Recorded only when IntentOrigin is "Custom Tab". Recorded once per SearchActivity session. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com chrome-mobile-search@google.com Record the Search type requested from an Intent. Recorded once per intent. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com chrome-mobile-search@google.com Records the reason SearchActivity was closed. Captures the {IntentOrigin} specific SearchActivity metrics. Recorded exactly once per SearchActivity session. ender@google.com chrome-mobile-search@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. NOTE: there's a possible gap in data between 2024-04-28 and 2024-08-16. pnoland@chromium.org ender@google.com chrome-mobile-search@google.com Records the wall time elapsed between focusing the omnibox and invocation of the onPrepare method signalling the start of an IME (soft keyboard) animation. Recorded once per omnibox focus on devices when suggestion list animation is enabled, which requires API level 30+ and "controllable" IME insets (which excludes, e.g. most devices with a hardware keyboard attached). This metric is recorded even if the animation is cancelled due to timeout, but is not recorded if the onPrepare method is never called. Note: There is a recording gap between: 2025.09-2026.08. ender@google.com 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@google.com pnoland@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 ender@google.com 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@google.com pnoland@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 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 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. peterkang@google.com chrome-mobile-search@google.com Records whether the Omnibox suggestions dropdown view was successfully created in the background before the UI thread required it. True indicates the background inflation finished on time. False indicates the background inflation did not finish on time and the dropdown had to be inflated on the UI thread. Recorded at most once per activity start upon the first time the Omnibox is focused and the suggestions container is requested. peterkang@google.com chrome-mobile-search@google.com Records thread time spent inflating the Omnibox suggestions container view hierarchy in a background thread via AsyncViewStub. Recorded at most once per activity start when AsyncViewStub inflates the container. peterkang@google.com chrome-mobile-search@google.com Records wall time spent inflating the Omnibox suggestions container view hierarchy in a background thread via AsyncViewStub. Recorded at most once per activity start when AsyncViewStub inflates the container. peterkang@google.com chrome-mobile-search@google.com Records whether forced synchronous inflation occurred for the suggestions dropdown. True indicates inflation had to be forced synchronously because the UI requested the container before background inflation completed. False indicates background inflation completed successfully on time. Recorded at most once per activity start upon the first time the suggestions container is requested/inflated. peterkang@google.com chrome-mobile-search@google.com Records whether the Omnibox suggestions dropdown inflation thread matches the expected thread (background thread if async inflation is enabled, UI thread otherwise). Recorded once per activity start when inflation is initialized. peterkang@google.com chrome-mobile-search@google.com Records thread time spent on construction of the Omnibox suggestions dropdown. This metric will provide a comparison of the thread time spent inflating the suggestions dropdown on the UI thread vs the background thread. Furthermore, it will also be used to gauge how much time is being moved from the UI thread to the background thread. Recorded once per activity start when AsyncViewInflator inflates the OmniboxSuggestionsDropdown. peterkang@google.com ender@google.com Records wall time spent on construction of the Omnibox suggestions dropdown. This metric will provide a comparison of the wall time spent inflating the suggestions dropdown on the UI thread vs the background thread. Furthermore, it will also be used to gauge how much time is being moved from the UI thread to the background thread. Recorded once per activity start when AsyncViewInflator inflates the OmniboxSuggestionsDropdown. peterkang@google.com chrome-mobile-search@google.com Records the number of ViewHolders successfully created during pre-warming of the OmniboxSuggestionsDropdown RecycledViewPool. Recorded once per activity start when pre-warming finishes. peterkang@google.com chrome-mobile-search@google.com Records whether the OmniboxSuggestionsDropdown pre-warming thread matches the expected thread (background thread if async inflation is enabled, UI thread otherwise). Recorded once per activity start when pre-warming is initialized. peterkang@google.com chrome-mobile-search@google.com Records the cumulative CPU thread time spent actively inflating ViewHolders during pre-warming of the OmniboxSuggestionsDropdown RecycledViewPool. Recorded once per activity start when pre-warming finishes. peterkang@google.com chrome-mobile-search@google.com Records the cumulative wall time spent actively inflating ViewHolders during pre-warming of the OmniboxSuggestionsDropdown RecycledViewPool. Recorded once per activity start when pre-warming finishes. ender@google.com 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 chrome-mobile-search@google.com 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. ender@google.com 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@google.com pnoland@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 Note: There is a recording gap between: 2026.07-2026.08. ender@google.com chrome-mobile-search@google.com 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 chrome-mobile-search@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. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com chrome-mobile-search@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. Note: There is a recording gap between: 2026.07-2026.08. ender@google.com 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. ender@google.com nhiroki@chromium.org ryansturm@chromium.org curranmax@chromium.org chrome-mobile-search@google.com {AndroidSearchPrefetch} The amount of time it takes to get the Geo Location header for a prefetch request. {AndroidNavigationOrSuggestionPrefetch} Note: There is a recording gap between: 2026.07-2026.08. nhiroki@chromium.org 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} thesalsa@google.com chrome-mobile-search@google.com {AndroidSearchPrefetch} Measures the delay from physical touch down to the start of prefetch processing on the Java main thread, i.e. directly before TouchDownProcessTime is recorded. This is used to measure the overhead of Android input event dispatching plus queueing time on the UI thread. Emitted once for each touch down event on a search suggestion that is forwarded to the prefetch handler. Not emitted when the omnibox input session has ended or the per-session prefetch limit has been reached (in those cases the event is dropped before this is recorded). Emitted whether or not the forwarded event ultimately starts a prefetch. {AndroidNavigationPrefetchOnly} nhiroki@chromium.org 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} nhiroki@chromium.org 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. sinansahin@google.com clank-app-team@google.com Recorded when the user clicks the Open in App item in the App Menu. A true value indicates OpenInAppInfo was non-null for the current tab when the item was clicked, and vice versa. sinansahin@google.com clank-app-team@google.com Recorded when the user clicks the Open in App item in the App Menu. Recorded boolean denotes whether the Open in App chip in the omnibox was visible at the time of the click. sinansahin@google.com clank-app-team@google.com Recorded when the user clicks the Open in App chip in the omnibox. Always recorded true. sinansahin@google.com clank-app-team@google.com Recorded when the Open in App option becomes available for a page (either as a chip or in the app menu). It is recorded when the target app package changes (e.g. navigating from a page with no app, or a different app). If multiple apps are available, we compare by domain instead of package. Navigations that resolve to the same package (or same domain if multiple apps) do not emit this histogram again. Always recorded true. wenyufu@chromium.org src/chrome/browser/ui/android/edge_to_edge/OWNERS Records, when user starts a overscroll from the bottom on a tab, whether the overscroll satisfied the start condition (e.g. the browser controls is not already shown). wenyufu@chromium.org src/chrome/browser/ui/android/edge_to_edge/OWNERS Records, when user starts a overscroll from the bottom on a tab, whether the overscroll handler fired the callback to re-show the browser controls. 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. salg@google.com ssid@google.com Records whether the PageContentProtoViewStructureBuilder was successful in getting the page content proto and populating the virtual structure. Recorded when onProvideVirtualStructure is called on ContentView when the AnnotatedPageContentsVirtualStructure feature is enabled. 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 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 Warning, this histogram may have a data gap since it was expired on 2023-12-12 and reenabled around 2024-03-01. 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. 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. 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. shahinmd@google.com ashleynewson@chromium.org Records the time taken to read the password echo setting(s) from the system server during initialization. The {SettingType} token specifies the type of setting read. Only emitted once when the embedding application's instance of PasswordEchoSettingState is created. The metric recorded (either the split or the legacy setting) depends on the state of the Aconfig feature flag for splitting the password echo settings. This is recorded only on Android, where the timer is always high-resolution. shahinmd@google.com ashleynewson@chromium.org Records the total time taken for the PasswordEchoSettingState class to complete its initialization. This time includes operations like reading the Aconfig feature flag state, registering the necessary ContentObserver(s) for monitoring setting changes, and the initial read of the relevant system setting value(s). Only emitted once when the embedding application's instance of PasswordEchoSettingState is created. This is recorded only on Android, where the timer is always high-resolution. salg@google.com clank-large-form-factors@google.com Records whether we were able to get the package name of the default assistant app from Android's settings. Recorded when AssistContent is requested for pdf pages. shuyng@google.com clank-large-form-factors@google.com Records whether the device enterprise info has been cached when getting it synchronously for pdf pages. shuyng@google.com clank-large-form-factors@google.com Records whether we are running in a work profile. Recorded when AssistContent is generated successfully for pdf pages. Used to determine the frequency of AssistContent preparation on pdf pages; and how often the work profile is on while preparing AssistContent for pdf pages. shuyng@google.com clank-large-form-factors@google.com Recorded when the pdf load starts. Used to compare against Android.Pdf.DocumentLoadResult.Detail, which is recorded when the pdf load is complete, to determine how many pdf loads are not complete. shuyng@google.com clank-large-form-factors@google.com Records the elapsed time between two pdf document loads. Recorded when the pdf load starts. Used to evaluate the threshold to keep PdfDocumentService running after the last client unbinds. shuyng@google.com clank-large-form-factors@google.com Records the pdf document load result details. Recorded when the pdf load is completed or aborted. Only record when there is a paired Android.Pdf.DocumentLoad. Only record the first load result for each pdf load. shuyng@google.com clank-large-form-factors@google.com Records the pdf document load time. Recorded when the pdf load is complete. Records the first successful load for each explicit pdf load. Only record when there is a paired Android.Pdf.DocumentLoad. shuyng@google.com clank-large-form-factors@google.com Records the pdf download time for transient downloads, i.e. download pdf to open in Chrome. Recorded when the pdf download is complete and before pdf view is rendered. Used to assess the prioritization of a refined user experience for downloading. shuyng@google.com clank-large-form-factors@google.com Records whether the pdf download url is successfully decoded. This is recorded when re-download is needed for pdf pages (e.g. Chrome restart or navigate back/forward). shuyng@google.com clank-large-form-factors@google.com Records whether the pdf download url is successfully encoded. This is recorded when the pdf download starts. shuyng@google.com clank-large-form-factors@google.com Records find-in-page invocation counts for each pdf page. The count number represents the previous find-in-page invocations on the same pdf page. This can be recorded more than once for each pdf page. Recorded when find-in-page is invoked. rathomas@google.com clank-large-form-factors@google.com Records the outcome when a user clicks on an embedded hyperlink in a PDF. Recorded in PdfCoordinator#onLinkClicked. shuyng@google.com clank-large-form-factors@google.com Records whether the pdf native page is frozen before the tab is displayed, such as being selected from tab switcher or tab strip. Used to determine how often the pdf native page is frozen. rathomas@google.com clank-large-form-factors@google.com Records user interactions with PDF V2 selection menu items. Recorded when a selection menu item (such as Share, Web Search, or Translate) is selected. rathomas@google.com clank-large-form-factors@google.com Records user interactions with the PDF viewer toolbar and overflow (3-dot) menu. Recorded when a toolbar button is clicked or a menu action is triggered. shuyng@google.com clank-large-form-factors@google.com Records whether the PDF file URI is null when attempting to load the file. Recorded in PdfCoordinator#loadPdfFile. finnur@chromium.org twellington@chromium.org Records which action the user takes in the PhotoPickerDialog. twellington@chromium.org tedchoc@chromium.org The short version code for Google Play Services in a format YYWWV, where YY is year, WW is week and V is version (0 for beta releases and 1 for stable release). This metric is logged with every UMA upload. 0 is recorded when GMS Core is not installed, 1 when GMS Core version can't be parsed and 2 when GMS Core version doesn't fit into defined range. 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. jinsukkim@google.com twellington@google.com clank-app-team@google.com Record the phase when a gesture nav is triggered {Transition} by user's gesture and when the predictive back gesture is on. jinsukkim@google.com twellington@google.com clank-app-team@google.com Record the result of capturing a screenshot of a native page view. This screenshot will be saved for back forward transition and used a preview when user navigating back to native page. Record when user navigates away from a native view page. jinsukkim@google.com twellington@google.com clank-app-team@google.com Record whether a navigation is about to start from a chrome native page to another chrome native page. Record right before such navigation starts. jinsukkim@google.com twellington@google.com clank-app-team@google.com Record the duration when the feed stream is restored after being transited to New Tab Page. jinsukkim@google.com twellington@google.com clank-app-team@google.com Record whether animation is triggered because of the timeout fallback. False if it's triggered right after the feed stream is restored. jinsukkim@chromium.org clank-app-team@google.com Tells whether Reader Mode CPA button can be shown i.e. has the space in the toolbar. Recorded when Contextual page action controller chooses Reader Mode for the action to display as CPA. 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. 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. fgorski@chromium.org ender@google.com 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 (browser navigations). fgorski@chromium.org ender@google.com 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. shuyng@google.com skavuluru@google.com Records the new Request Desktop window setting when changed. If the setting is true, Chrome will request mobile view when the window is narrow. This is recorded when a user manually changes the Request Desktop window setting from the 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. salg@google.com ssid@google.com tivi@google.com Records events related to ScreenshotContentProvider as it generates a URI for an external app and as it handles queries/openFile from said external app. salg@google.com ssid@google.com tivi@google.com Records the amount of time passed while capturing a screenshot's contents. salg@google.com ssid@google.com tivi@google.com Records the amount of time passed between sending a screenshot provider URI to an external app and receiving an openFile request from an external app with the same URI (this starts a screenshot capture task). salg@google.com ssid@google.com tivi@google.com Records the total amount of time passed between sending a screenshot content provider URI to an external app and it receiving the screenshot's contents. salg@google.com ssid@google.com tivi@google.com Records events related to ScreenshotUriProvider as it generates, caches, or reuses content URIs for screenshots. skym@chromium.org ckitagawa@chromium.org Scrims are placed into the view heirarchy by walking up from the anchor view looking for the parent. This is supposed to always work, but we're currently seeing failures in the wild. This histogram aims to narrow down which scrim clients are having problems to inform the investigation. skym@chromium.org ckitagawa@chromium.org Emitted when a scrim is actaully triggered. Should help narrow down which clients that have code depedencies on the scrim systme actaully use it. It's possible some are legacy and just dead code. Additionally, will help give a ratio of usages to problems encountered when compared to the other scrim histograms. wylieb@google.com chrome-omnibox-team@google.com The type of the search engine chosen by the user in Search Engine Choice flow. wylieb@google.com chrome-omnibox-team@google.com Counts occurences of various events related to Search Engine Choice feature. wylieb@google.com chrome-omnibox-team@google.com Counts occurences of various events related to Search Engine Choice V2 feature. wylieb@google.com chrome-omnibox-team@google.com 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). jhimawan@google.com clank-app-team@google.com Records the time taken to show the text selection popup menu. Recorded when the menu is shown. This metric is only recorded for the floating (action mode) selection menu. jhimawan@google.com clank-app-team@google.com Records the time taken to show the text selection popup menu. Recorded when the menu is shown. This metric is only recorded for the dropdown selection menu. alexmitra@chromium.org peconn@chromium.org Records whether we were able to reuse the cached selection menu for the text selection popup menu. We keep this object stored in memory for a small latency gain and this histogram will help us determine whether it's worth removing the caching mechanism. This histogram is logged once every time we attempt to show a selection menu (each time text is selected). hidehiko@google.com jinsukkim@google.com Records when the user triggers fragment pop back on SettingsActivity after the fragment manager already saved its state. In the case we delayed the pop back operation. Records the number of such cases to make sure this works enough. This record is used to verify the effectiveness of the fix. 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. 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. 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. wenyufu@chromium.org aishwaryarj@google.com 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. 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. wenyufu@chromium.org twellington@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. clhager@google.com twellington@chromium.org wenyufu@chromium.org Records a change in the background color of a tab resulting in an update to tab observers. This background color change may be due to a change in web content or web content background, a custom view being set, or a native page being shown or hidden. A sharp increase in such updates may have performance implications - measuring an increase in such updates is particularly helpful for the OSNavBarMatchesTab feature, which has observed some performance regressions. clhager@google.com twellington@chromium.org wenyufu@chromium.org Records a potential change in the background color of a tab. This potential change may or may not be communicated to observers, as an optimization will attempt to avoid redundant notifications. To measure the number of notifications that are actually communicated to observers, refer to 'Android.Tab.BackgroundColorChange'. 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. ssid@google.com hitarthkothari@google.com Records the stable state (Peek, Half, Full, or Hidden/Closed) entered by the Tab Bottom Sheet for {ClientType}. Recorded every time a stable state is reached, ignoring transient scrolling or transition states. ssid@google.com hitarthkothari@google.com Records the reason why the Tab Bottom Sheet for {ClientType} was hidden. Recorded every time the bottom sheet settles into the Hidden/Closed state. ssid@google.com hitarthkothari@google.com Records the reason why the Tab Bottom Sheet for {ClientType} entered the Peek state. Recorded every time the bottom sheet settles into the Peek state. ssid@google.com hitarthkothari@google.com Records transitions between open stable states (Peek, Half, Full) for the Tab Bottom Sheet for {ClientType}. Recorded when transitioning between two different open stable states, ignoring transient scrolling states. acondor@chromium.org ckitagawa@chromium.org clank-performance-team@google.com This histogram records the time taken to screenshot the contents of a tab to use as a thumbnail. Recorded once per capture. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org Reports the entrypoint from which a tab group's color icon was changed. Record once per user attempt to change the tab group's color in the TabGridDialog view. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The result of the action taken from the TabGroupCreation dialog. Record once per user attempt to create a new tab group through the TabGroupCreation modal dialog. ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org The result of the group color and title selections made when accepting the TabGroupCreation dialog. Record once per user attempt to create a new tab group through the TabGroupCreation modal dialog. skym@chromium.org clank-tab-dev@google.com When a tab group open from the tab group pane failes because there is no local id, this metric is emitted with the state that the tab is in. This should help narrow down why this is happening. bbetini@google.com ssid@chromium.org Records the number of 'active' (currently loaded in memory/session) tabs that are eligible for the tab picker. Recorded when the Tab Picker UI is preparing its list of displayable tabs. bbetini@google.com ssid@chromium.org Records the number of 'active' (live) tabs actually selected by the user, when the user confirms their selection in the Tab Picker. ckitagawa@chromium.org ssid@chromium.org Records the number of background tabs that are shown for the tab picker. Recorded when the Tab Picker UI is preparing its list of displayable tabs. These tabs will be lazily loaded after being picked. bbetini@google.com ssid@chromium.org Records the number of tabs found in the PageContentExtractionService cache that are eligible for the tab picker. Recorded when the Tab Picker UI is preparing its list of displayable tabs. bbetini@google.com ssid@chromium.org Records the number of 'cached' tabs actually selected by the user, when the user confirms their selection in the Tab Picker. skym@chromium.org clank-tab-dev@google.com Records the number of tabs selected when the user exits the Tab Picker by cancelling (e.g. back press). ckitagawa@chromium.org madhavpruthi@google.com Records the time taken to load a background tab on demand for the tab picker. Recorded when the tab load finishes. ckitagawa@chromium.org madhavpruthi@google.com Records the time taken to fetch a thumbnail after an on-demand tab load finishes. Recorded when the thumbnail is fetched. haileywang@google.com ssid@chromium.org The number of selectable tabs available to the user in the tab item picker. Recorded when the tab picker UI is shown. haileywang@google.com ssid@chromium.org The number of tabs selected by the user in the tab item picker. Recorded when the user confirms their selection. skavuluru@google.com clank-large-form-factors@google.com Records whether the tablet determination logic via resource loading and display properties is different. This is recorded once per activity lifespan during startup (attachBaseContext). ckitagawa@chromium.org bjfong@google.com fredmello@chromium.org Reports the number of tabs that are bookmarked using the TabListEditor 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 TabListEditor. 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 TabListEditor in milliseconds within a given browser activity lifespan. This is recorded when the TabListEditor is shown with the exception of the first time it is shown within an activity lifespan. rbyers@chromium.org mthiesse@chromium.org mamir@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. mamir@chromium.org rbyers@chromium.org The distribution of results when running ExternalNavigationHandler for {Scheme} navigations which are intercepted. This shows how frequently {Scheme} navigations trigger a dialog (that the user may potentially cancel to cancel the external app launch.) bjfong@google.com wylieb@google.com clank-growth@google.com Records the reason the Tab Search overlay was dismissed (e.g. close button, scrim click, back press / ESC, window focus loss, or tab / URL selection). Recorded every time the Tab Search overlay is hidden. bjfong@google.com wylieb@google.com clank-growth@google.com Records the entrypoint used to open the Tab Search overlay (e.g. horizontal tab strip button, vertical tabs button, or app menu / shortcut). Recorded when the Tab Search overlay is invoked. bjfong@google.com wylieb@google.com clank-growth@google.com Records whether the Tab Search overlay displayed an empty search state ("No results found") at least once during a search session because an entered search query returned zero matching suggestions. Recorded once per Tab Search overlay session upon dismissal. renkens@google.com aishwaryarj@google.com Emitted when mTabHoverCardView object is unexpectedly null during a StripLayoutHelper.showTabHoverCardView call. The value is True if the showTabHoverCardView call was delayed, and False if it was immediate. Recorded once per call, if the mLastHoveredTab is not null and mTabHoverCardView is null. 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 Recorded on startup, after a set amount of time. True if we timed out while waiting for the tab strip to be drawn before removing the temp background. False if the tab strip was successfully drawn and we removed the temp background before timing out. 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. peilinwang@google.com The duration of TitleBitmapFactory.getTitleBitmap, recorded once per call. peilinwang@google.com twellington@chromium.org The full (untruncated) length of the title to be converted to a bitmap by TitleBitmapFactory.getTitleBitmap. Recorded once per call, if the title is neither null nor empty. 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. shuyng@google.com clank-large-form-factors@google.com Emitted when the ContextMenuCoordinator is unexpectedly null while attempting to change the context menu's focus state in the Tab Switcher. Records true if the current tab model is Incognito (off-the-record) at the time of the event, and false if it is a regular tab model. 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 dtrainor@chromium.org 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.org 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 fredmello@chromium.org 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. peilinwang@google.com clank-performance-team@google.com Whether or not we have a capture with an out of date url when starting a scroll. This means that we're showing an older url that's different from the url of the current page. This histogram is recorded every time onContentViewScrollingStateChanged(true) gets called with browser controls unlocked. Subsampled to 1% of the time. pnoland@chromium.org ender@google.com Records the user-preferred position for the toolbar at the time ToolbarPositionController is initialized. Initialization occurs once per eligible ChromeTabbedActivity after initial layout inflation completes. A ChromeTabbedActivity is eligible if it is non-CCT, the device is not a tablet, and the bottom toolbar flag is enabled. The value of the pref defaults to TOP until the user deliberately changes it. pnoland@chromium.org ender@google.com Records user-initiated positions change for the toolbar, indicating the newly preferred position. Recorded when the value of the toolbar position preference changes, either via long press or toggling it in the settings page. skym@chromium.org fredmello@chromium.org 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. Warning: this histogram was expired from 2024-01 to 2024-10 and from 2025-12-21 to 2026-08-13; data may be missing. skym@chromium.org fredmello@chromium.org 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. peilinwang@google.com clank-performance-team@google.com Records how long the optional button was animating for when it causes a capture to be blocked. Only recorded when the duration is longer than 10s. peilinwang@google.com clank-performance-team@google.com Records how long the status icon was animating for when it causes a capture to be blocked. Only recorded when the duration is longer than 10s. skym@chromium.org fredmello@chromium.org 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. Was expired from 2024-01 to 2024-10. skym@chromium.org fredmello@chromium.org 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. Warning: this histogram was expired from 2024-01 to 2024-10 and from 2025-12-21 to 2026-08-13; data may be missing. alexmitra@chromium.org src/android_webview/OWNERS Logs when an Android dialog is shown from either Chrome or WebView. Logs the specific type of dialog which is being shown to the user. tasak@google.com 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. agazal@google.com kije@chromium.org Tracks the outcome of a drag-and-drop interaction session in Vertical Tabs. Recorded when the drag interaction ends (finger is lifted). agazal@google.com kije@chromium.org Records the duration (in milliseconds) between when a tab was grouped via drag and drop and when it was subsequently ungrouped (dragged back out) in Vertical Tabs. agazal@google.com jinsukkim@chromium.org Records the duration (wall-clock time) for which Vertical Tabs remained enabled. Recorded when the user toggles Vertical Tabs off (reverting to Horizontal Tabs). agazal@google.com jinsukkim@chromium.org eleanorlee@google.com Records the entry point and direction (enable/disable) when the user toggles Vertical Tabs. agazal@google.com spdonghao@google.com Recorded when the user clicks on the collapse button to collapse or expand the vertical tab strip rail. True if the user is collapsing the rail and false if a user is expanding it. agazal@google.com jinsukkim@chromium.org Recorded when the user clicks on the tab group header to collapse or expand it in Vertical Tabs. True if the user is collapsing a group and false if a user is expanding it. agazal@google.com jinsukkim@chromium.org eleanorlee@google.com spdonghao@google.com Records the window width boundary category when a user toggles Vertical Tabs {Direction}. hanfeng@google.com wallet-1p-integrations@google.com Records detected flight boarding pass barcode images on each page load. It's only enabled on the Chrome Android app. It's only emitted once on page load, either detected or not detected. elabadysayed@chromium.org src/android_webview/OWNERS The name of the process when WebView is loaded by the AGSA app (com.google.android.googlequicksearchbox). This is recorded every time a metrics log is created, but only if the host app is AGSA. 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). Warning: this histogram was expired from 2026-05-03 to 2026-05-15; data may be missing. pbirk@chromium.org src/android_webview/OWNERS This histogram is logged every time a header configured through the AndroidX Profile.setExtraHeaderForOrigins API matches an outgoing request, whether it is the original request or a redirect. The histogram records whether the header was ultimately attached to the request (Used) or skipped because it would have overwritten an existing header on the request (Not Used). The histogram is emitted once for each matching header on each request or redirect. The histogram is intended to provide data on how often headers configured through this API collides with existing headers, as input for potential future changes to the AndroidX API. pbirk@chromium.org src/android_webview/OWNERS This histogram is logged every time a header configured through the AndroidX Profile.setExtraHeaderForOrigins API matches an outgoing CORS preflight request, and is emitted once per request, even if multiple headers match. The histogram is intended to provide data on how often headers configured through this API applies to CORS preflight, to inform if and how to handle preflight request. 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". Warning: this histogram was expired from 2026-04-29 to 2026-05-15; data may be missing. ziadyoussef@chromium.org src/android_webview/OWNERS How long the WebView loadDataWithBaseURL API takes to run. This measures the sync time the API takes to return not the actual time until the page loads. This is logged only when the app calls loadDataWithBaseURL explicitly. ziadyoussef@chromium.org src/android_webview/OWNERS How long the WebView loadUrl API takes to run. This measures the sync time the API takes to return not the actual time until the page loads. This is logged only when the app calls loadUrl explicitly. ziadyoussef@chromium.org src/android_webview/OWNERS How long the WebView loadUrl with addtional headers API takes to run. This measures the sync time the API takes to return not the actual time until the page loads. This is logged only when the app calls loadUrl with addtional headers explicitly. pbirk@chromium.org src/android_webview/OWNERS Records which methods of WebChromeClient the caller has overridden when calling WebView.setWebChromeClient. The goal of this histogram is to determine the popularity of the various callback methods present in WebChromeClient. This histogram is logged every time a WebChromeClient is set. pbirk@chromium.org src/android_webview/OWNERS Records how many methods of WebChromeClient the caller has overridden when calling WebView.setWebChromeClient. The goal of this histogram is to track how many methods apps override to assist the analysis of API usage in WebView. This histogram is logged every time a WebChromeClient is set. pbirk@chromium.org src/android_webview/OWNERS Records which methods of WebViewClient the caller has overridden when calling WebView.setWebViewClient. The goal of this histogram is to determine the popularity of the various callback methods present in WebViewClient. This histogram is logged every time a WebViewClient is set. pbirk@chromium.org src/android_webview/OWNERS Records how many methods of WebViewClient the caller has overridden when calling WebView.setWebViewClient. The goal of this histogram is to track how many methods apps override to assist the analysis of API usage in WebView. This histogram is logged every time a WebViewClient is set. ntfschr@chromium.org src/android_webview/OWNERS woa-performance@google.com 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+. This metric was expired between Aug 2024 and Jan 2025 and may be missing data. Warning: this histogram was expired from 2026-04-29 to 2026-05-15; data may be missing. ntfschr@chromium.org src/android_webview/OWNERS woa-performance@google.com 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+. This metric was expired between Aug 2024 and Jan 2025 and may be missing data. Warning: this histogram was expired from 2026-04-29 to 2026-05-15; data may be missing. etiennep@chromium.org ntfschr@chromium.org Records calls to TracingController WebView APIs through the platform (framework) APIs. This is logged each time an API is called. Warning: this histogram was expired from 2026-04-29 to 2026-05-15; data may be missing. abhijithnair@chromium.org peter@chromium.org src/android_webview/OWNERS Whether a cache directory base path, provided through the process global config, was applied when loading the WebView library. Recorded once per WebView startup. abhijithnair@chromium.org peter@chromium.org src/android_webview/OWNERS Whether a data directory base path, provided through the process global config, was applied when loading the WebView library. Recorded once per WebView startup. alexmitra@chromium.org src/android_webview/OWNERS In some cases, WebView is unable to find the package ID which usually means that the AssetManager for the Context passed to WebView doesn't have WebView loaded in it. We have a rudimentary workaround for this which is to add WebView's asset path to the Context. Since writing this workaround, we believe we've addressed the underlying problem. Therefore the workaround should no longer be needed. This histogram logs whether the asset path workaround was needed during startup so that we can determine if it's safe to remove. This is logged once during WebViewChromiumFactoryProvider#initialize. alexmitra@chromium.org src/android_webview/OWNERS In some cases, WebView is unable to find its own Resources which usually means that the host app is doing something unsupported with the Context passed to WebView (or with the platform Resources class). We have a rudimentary workaround for this which is to add WebView's asset path to the Context. Since writing this workaround, we believe we've addressed the underlying problem. Therefore the workaround should no longer be needed. This histogram logs whether the asset path workaround was needed during startup so that we can determine if it's safe to remove. This is logged once during WebViewChromiumAwInit#startChromium. ashleynewson@chromium.org src/android_webview/OWNERS Records the UI thread blocking time taken to instantiate the default profile, which may or may not already reside on disk. Emitted once per session at Chromium startup after the immediate UI thread blocking work for instantiating the default profile is completed. Note that profile instantiation may trigger additional tasks, threads, or processes to be started, which may not be measured by this histogram. This non-measured work may still block practical usage of a profile. Only emitted for AndroidWebView. elabadysayed@chromium.org src/android_webview/OWNERS Records the synchronous duration of GetDefaultStoragePartition() when invoked during AwBrowserContext profile initialization. Emitted when creating origin trials delegate in the profile constructor. ashleynewson@chromium.org src/android_webview/OWNERS After a (default or non-default) profile is instantiated (freshly created or loaded from disk), records the new total count of instantiated profiles for the current session. Profiles cannot currently be unloaded, so this reflects the number of profiles actively loaded in memory. For example, if 3 profiles are started during a session, this histogram will emit 1, then 2, then 3. Note that this means direct modal or percentile based analysis of this histogram is not meaningful. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS The number of non-default profiles listed on disk at WebView startup. This is counted before any profiles are loaded, created, deleted, or otherwise manipulated. The default profile is not explicitly tracked in the pref_store and as such is not included in the count. Emitted once per session at Chromium startup. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS When a non-default profile is requested and needs to be newly created (it does not previously exist on disk), records the UI thread blocking time taken to create and instantiate the profile. Emitted once per non-default profile after it is created and sufficiently instantiated to be returned to the getter caller. Note that profile instantiation may trigger additional tasks, threads, or processes to be started, which may not be measured by this histogram. This non-measured work may still block practical usage of a profile. A single session will never emit both .Create and .LoadFromDisk for the same profile. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS Records the time taken to delete an on-disk but uninstantiated non-default profile. Requests to delete instantiated or non-existant profiles will not emit to this histogram. Emitted once per deleted non-default profile after its deletion is completed. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS When an existing non-default profile is requested and needs to be loaded from disk, records the UI thread blocking time taken to load and instantiate the profile. Emitted once per non-default profile after it is loaded and sufficiently instantiated to be returned to the getter caller. Note that profile instantiation may trigger additional tasks, threads, or processes to be started, which may not be measured by this histogram. This non-measured work may still block practical usage of a profile. A single session will never emit both .Create and .LoadFromDisk for the same profile. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS When a non-default profile is requested and needs to be newly created (it does not previously exist on disk), records the time between AwBrowserContextStore initialization and this first request for the profile. Emitted once per non-default profile creation, just before its registration to the pref_store. A single session will never emit both .Create and .LoadFromDisk for the same profile. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS When a request to delete an on-disk but uninstantiated non-default profile is made, records the time between AwBrowserContextStore initialization and the deletion request. Requests to delete instantiated or non-existant profiles will not emit to this histogram. Emitted once per deleted non-default profile just before its deletion is started. Only emitted for AndroidWebView. ashleynewson@chromium.org src/android_webview/OWNERS When an existing non-default profile is requested and needs to be loaded from disk, records the time between AwBrowserContextStore initialization and this session's first request for the profile. Emitted once per requested existing non-default profile per session just before the time of its load from disk. A single session will never emit both .Create and .LoadFromDisk for the same profile. Only emitted for AndroidWebView. cduvall@chromium.org src/android_webview/OWNERS Time it takes to run the AwContents constructor. Recorded {IsFirst} time the constructor is run. alexmitra@chromium.org colibie@google.com src/android_webview/OWNERS When we read the cached flags from shared preferences, this histogram records whether we successfully found existing cached flags. The cached flags may not be there if the app/user has cleared the data directory, the app is freshly installed or in some cases when the WebView version changes. This metric does not include the "old manual experiments" referenced in WebViewCachedFlags.java. This metric is recorded once per startup. abhijithnair@chromium.org src/android_webview/OWNERS Records how this session's cache quota was obtained in `AwBrowserProcess::GetHostAppCacheQuota()`. This is emitted once during WebView global initialization if `WebViewCacheSizeLimitDerivedFromAppCacheQuota` flag is enabled. Only emitted for AndroidWebView. abhijithnair@chromium.org src/android_webview/OWNERS Records the result of `StorageManager.getCacheQuotaBytes()` after WebView startup. The value denotes the amount of cache quota that was allocated to the app by the framework. This is logged only once per session in a delayed background task approximately 5 seconds after WebView completes its main startup tasks. The measurement may be expensive, so it is only performed if the WebViewRecordAppCacheHistograms feature is enabled. abhijithnair@chromium.org src/android_webview/OWNERS Records the result of `StorageManager.getCacheSizeBytes()` after WebView startup. The value denotes the amount of cache that the app is currently using. This is logged only once per session in a delayed background task approximately 5 seconds after WebView completes its main startup tasks. The measurement may be expensive, so it is only performed if the WebViewRecordAppCacheHistograms feature is enabled. abhijithnair@chromium.org src/android_webview/OWNERS Records by how much the cache size {ExceedsOrWithin} the cache quota alloted to the app by the framework. This is logged only once per session in a delayed background task approximately 5 seconds after WebView completes its main startup tasks. The measurement may be expensive, so it is only performed if the WebViewRecordAppCacheHistograms feature is enabled. Only recorded in AndroidWebView. ntfschr@chromium.org src/android_webview/OWNERS Records the invocation count of WebView callbacks. Starting with M117, records shouldInterceptRequest counts. pbirk@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. pbirk@chromium.org src/android_webview/OWNERS Size on disk taken by the AwComponentUpdateService directory. This is logged once per update job in AwComponentUpdateService. pbirk@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. pbirk@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. pbirk@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. pbirk@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. pbirk@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. pbirk@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. bewise@chromium.org src/android_webview/OWNERS Records how many levels up in the View hierarchy Jetpack Compose is found when a WebView is attached to the window (e.g. 1 means directly wrapped by AndroidView). Records 0 if no Compose ancestor is found. torne@chromium.org src/android_webview/OWNERS Records whether the two different input fixup strategies being tested in AwCookieManager changed the URL, and whether the change was the same. Logged once for each call to the Java CookieManager.setCookie or CookieManager.getCookie APIs. torne@chromium.org src/android_webview/OWNERS Records whether the two different input fixup strategies being tested in AwCookieManager changed the value, and whether the change was the same. Logged once for each call to the Java CookieManager.setCookie API. ntfschr@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 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 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 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 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 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 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. {NavType} ntfschr@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 thomasbull@chromium.org torne@chromium.org src/android_webview/OWNERS Records the number of times the Net Logs were captured. This only ever logs the value "true" because we only care about the total count. This is logged in the nonembedded AwNetLogService when the net-logs flag is enabled and a webview is launched. ntfschr@chromium.org src/android_webview/OWNERS Records the time spent using a specific tool, from creation to destruction. {AndroidWebViewFragment} ntfschr@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. abhijithnair@chromium.org src/android_webview/OWNERS Records the time taken to measure Android.WebView.CacheQuotaSize using `StorageManager.getCacheQuotaBytes()` in milliseconds. This may be logged even if the measurement for Android.WebView.CacheQuotaSize fails. abhijithnair@chromium.org src/android_webview/OWNERS Records the time taken to measure Android.WebView.CacheSize using `StorageManager.getCacheSizeBytes()` in milliseconds. This may be logged even if the measurement for Android.WebView.CacheSize fails. 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. mvanouwerkerk@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. Logged when the browser process is started. mvanouwerkerk@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. Logged when the browser process is started. mvanouwerkerk@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. Logged when the browser process is started. mvanouwerkerk@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. Logged when the browser process is started. mvanouwerkerk@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 startup state. Logged when the browser process is started. mvanouwerkerk@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. Logged when the browser process is started. mvanouwerkerk@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. Logged when the browser process is started. ashleynewson@chromium.org src/android_webview/OWNERS The absolute HTTP cache quota size supplied to the SetHttpCacheQuota API for {ProfileType}. Recorded on every call to the setter API. This uses the unclamped value provided to the setter. Not emitted when calling UseDefaultHttpCacheQuota. Only emitted if the WebViewHttpCacheQuotaApi feature is enabled. This histogram will only be emitted for the default profile if the WebViewHttpCacheQuotaApiAllowForDefaultProfile feature parameter is true. ashleynewson@chromium.org src/android_webview/OWNERS For each call to the AwBrowserContext::SetHttpCacheQuota or ::UseDefaultHttpCacheQuota APIs for {ProfileType}, records whether it is the first call or a repeated call with or without a change since the previous call. Only emitted if the WebViewHttpCacheQuotaApi feature is enabled. This histogram will only be emitted for the default profile if the WebViewHttpCacheQuotaApiAllowForDefaultProfile feature parameter is true. ashleynewson@chromium.org src/android_webview/OWNERS The HTTP cache quota size supplied to the SetHttpCacheQuota API relative to the default quota size for {ProfileType}. 100% means equal to default. Recorded on every call to the SetHttpCacheQuota API. This uses the unclamped value provided to the setter, but the default it is compared against is a clamped value. Not emitted when calling UseDefaultHttpCacheQuota. Only emitted if the WebViewHttpCacheQuotaApi feature is enabled. This histogram will only be emitted for the default profile if the WebViewHttpCacheQuotaApiAllowForDefaultProfile feature parameter is true. ashleynewson@chromium.org src/android_webview/OWNERS Whether a non-default HTTP cache quota was restored from a previously persisted preference for {ProfileType}. Recorded once per profile during profile initialization. Only emitted if the WebViewHttpCacheQuotaApi feature is enabled. This histogram will only be emitted for the default profile if the WebViewHttpCacheQuotaApiAllowForDefaultProfile feature parameter is true. ashleynewson@chromium.org src/android_webview/OWNERS Recorded when the HTTP cache quota is reset to the default value for {ProfileType}. Recorded on every call to UseDefaultHttpCacheQuota. Only emitted if the WebViewHttpCacheQuotaApi feature is enabled. This histogram will only be emitted for the default profile if the WebViewHttpCacheQuotaApiAllowForDefaultProfile feature parameter is true. abhijithnair@chromium.org src/android_webview/OWNERS Records the default per-profile HTTP cache size limit that will be used throughout this session. This default may be overridden by the Cache Quota API. This is emitted once during WebView global initialization. Only emitted for AndroidWebView. jam@chromium.org cduvall@chromium.org stefanoduo@google.com Measures how long InputStreams take from creation to completion. This is emitted for all streams whether they succeed or fail. This metric was expired between December 2023 and May 2024. Data from that period will be incomplete. ntfschr@chromium.org thomasbull@chromium.org torne@chromium.org src/android_webview/OWNERS Records the number of times the WebView is debuggable or not debuggable, if it is debuggable then also how it has been set set, whether it is from the app or from the OS or from calling setWebContentsDebuggingEnabled(true). This is logged each time the MetricsService uploads metrics. Warning: this histogram was expired from 2025-05-18 to 2025-07-25; data may be missing. peconn@chromium.org webview-team@google.com The time it takes to execute JsCommunicationHost::RenderFrameCreated. Recorded whenever a render frame is created in a WebContents that has a JsCommunicationHost attached (in other words, in Android WebView). peconn@chromium.org src/android_webview/OWNERS The size of the 'data' string passed to loadDataWithBaseURL() when the 'baseUrl' starts with 'data:'. peconn@chromium.org src/android_webview/OWNERS The size of the 'data' string passed to loadDataWithBaseURL() when the 'baseUrl' does not start with 'data:'. peconn@chromium.org src/android_webview/OWNERS Records the scheme for calls to loadUrl that have failed (they will have recorded Android.WebView.LoadUrl.Success == false). Logged once per call to loadUrl. pbirk@chromium.org src/android_webview/OWNERS This histogram records the number of HTTP headers that are silently rejected by the WebView.loadUrl API. The API will reject headers if the name or value contains any of NULL, CR, LF with an IllegalArgumentException. However, header names have more forbidden characters than just those three, and the API will silently discard those headers to maintain long-term compatibility. The purpose of this histogram is to identify applications who rely on this silent rejection of invalid headers in order to determine the disruption caused if we change the API contract in the future. This histogram logs the count of headers that are silently rejected. The histogram will only be emitted if the application is setting at least one header, and will be 0 if no invalid headers were rejected. It will not be emitted if any headers were rejected due to the 3 characters mentioned above. peconn@chromium.org src/android_webview/OWNERS Records whether a call to loadUrl succeeds or not, with regards to whether NavigationController.loadUrl returns a non-null NavigationHandle. This is logged once per call to loadUrl. ntfschr@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(). pbirk@chromium.org src/android_webview/OWNERS Records the Media Integrity API Status set by the embedding application. This status can be different for different URLs, but this histogram just records the reported API status without any URL information. This metric is logged when the API status for the source origin is checked. This is done during the initial call to supply a token provider to the Blink Renderer Extension. pbirk@chromium.org src/android_webview/OWNERS Records the ceil(log2(x)) of the size of the provided content binding on a requestToken call. Play restricts the length of the content binding to 500, but this histogram is recorded before calling Play, so any values higher that 9 would likely have led to a client error. This histogram is recorded as an exact linear histogram with a max value of 32. pbirk@chromium.org src/android_webview/OWNERS Counts the number of calls to 'requestToken' for a token provider. This metric is counted individually for each token provider, and is emitted when the request for a token is made. The metric will show the usage pattern of token providers by individual clients, by showing how many times they are used by the client As a cumulative value, this value is incremented and logged for each successive call. This means that when this histogram is logged for the Nth time, it will already have been emitted for all values [1 ... N-1]. Before analysing the histogram, it should be normalised by subtracting the raw count of the next higher bucket from the bucket count. The interesting value is "how far did the app get". By subtracting the raw count of N+1 from bucket N, you remove all the counts where the app continued to emit the next value in the sequence. pbirk@chromium.org src/android_webview/OWNERS Counts the number of times the WebView Media Integrity getIntegrityProvider method has been called by web content since the app loaded. This metric will be used to analyse the usage pattern of the Media Integrity API in apps, specifically to understand if apps are causing multiple sessions to be created, or if apps are instead creating a single webpage that loads a single resource which instantiates the API once. The metric is logged whenever a valid request is made from Web Content. As a cumulative value, this value is incremented and logged for each successive call. This means that when this histogram is logged for the Nth time, it will already have been emitted for all values [1 ... N-1]. Before analysing the histogram, it should be normalised by subtracting the raw count of the next higher bucket from the bucket count. The interesting value is "how far did the app get". By subtracting the raw count of N+1 from bucket N, you remove all the counts where the app continued to emit the next value in the sequence. pbirk@chromium.org src/android_webview/OWNERS Records the end-to-end time for a GetTokenProvider call to a successful response. This will be the time observed by a JavaScript client waiting for a new token provider. This includes both responses served from the cache and responses that go to Play. This histogram is not logged if the call results in an error. This histogram replaces Android.WebView.MediaIntegrity.GetTokenProviderResponseTime by extending the range of valid values from 10 seconds to 3 minutes. pbirk@chromium.org src/android_webview/OWNERS Logs the status of calling the Play getTokenProvider API. This histogram is logged on both successful responses and error responses. The error enum corresponds to the StandardIntegrityErrorCode, but introduces an UNKNOWN_ERROR code to catch situations where the Play client library introduces a new error code. pbirk@chromium.org src/android_webview/OWNERS Logs the status of calling the Play request token API on the StandardIntegrityTokenProvider. This histogram is logged on both successful responses and error responses. The error enum corresponds to the StandardIntegrityErrorCode, but introduces an UNKNOWN_ERROR code to catch situations where the Play client library introduces a new error code. pbirk@chromium.org src/android_webview/OWNERS Records the time from the beginning of a getToken request to a successful response is returned to JavaScript. pbirk@chromium.org src/android_webview/OWNERS Logs invalid calls from JavaScript to the Media Integrity API Java implementation. This histogram will be used to understand the extend to which clients are bypassing the JavaScript client API and sending unexpected requests to Java. pbirk@chromium.org src/android_webview/OWNERS Records the reason for returning a "Non-recoverable Error" from the Android WebView Media Integrity API, to aid in investigating why clients are seeing a relatively high proportion of this error code. The histogram is emitted every time this error code is produced by the implementation. pbirk@chromium.org src/android_webview/OWNERS Counts the number of times the token provider cache size has been exceeded, or in other words how many times an existing token provider was evicted from the cache in order to make room for a new one. The purpose of this histogram is to measure the effectiveness of the current cache size parameter, and will help inform if it should be changed, by giving us a histogram of how much larger it should have been to avoid evictions. This metric is logged every time a token provider is evicted. As a cumulative value, this value is incremented and logged for each successive call. This means that when this histogram is logged for the Nth time, it will already have been emitted for all values [1 ... N-1]. Before analysing the histogram, it should be normalised by subtracting the raw count of the next higher bucket from the bucket count. The interesting value is "how far did the app get". By subtracting the raw count of N+1 from bucket N, you remove all the counts where the app continued to emit the next value in the sequence. pbirk@chromium.org src/android_webview/OWNERS Counts the number of times a cached token provider is returned in response to a request from web content. This metric will help gauge the effectiveness of the token provider cache, especially if the cache size is changed in the future. It serves as a way to measure the savings on requests to Play caused by the cache. The metric is logged when a cached token provider is found in the cache. As a cumulative value, this value is incremented and logged for each successive call. This means that when this histogram is logged for the Nth time, it will already have been emitted for all values [1 ... N-1]. Before analysing the histogram, it should be normalised by subtracting the raw count of the next higher bucket from the bucket count. The interesting value is "how far did the app get". By subtracting the raw count of N+1 from bucket N, you remove all the counts where the app continued to emit the next value in the sequence. pbirk@chromium.org src/android_webview/OWNERS Counts the number of cache misses for the token provider cache in an application. This metric will help gauge the effectiveness of the token provider cache, especially if the cache size is changed in the future. It serves as a way to measure the savings on requests to Play caused by the cache. The metric is logged when a cached token provider is not found the cache. As a cumulative value, this value is incremented and logged for each successive call. This means that when this histogram is logged for the Nth time, it will already have been emitted for all values [1 ... N-1]. Before analysing the histogram, it should be normalised by subtracting the raw count of the next higher bucket from the bucket count. The interesting value is "how far did the app get". By subtracting the raw count of N+1 from bucket N, you remove all the counts where the app continued to emit the next value in the sequence. pbirk@chromium.org src/android_webview/OWNERS Logs how many times a new TokenProvider is created by Play. This metric will show how many different token providers are requested from Play. With the token provider cache in place, this count is expected to be lower than GetTokenProviderCumulative. This metric is logged when a provider is returned from Play. As a cumulative value, this value is incremented and logged for each successive call. This means that when this histogram is logged for the Nth time, it will already have been emitted for all values [1 ... N-1]. Before analysing the histogram, it should be normalised by subtracting the raw count of the next higher bucket from the bucket count. The interesting value is "how far did the app get". By subtracting the raw count of N+1 from bucket N, you remove all the counts where the app continued to emit the next value in the sequence. pbirk@chromium.org src/android_webview/OWNERS Records the time from requesting a new token provider from Play to receiving a successful response. This histogram is not emitted if the call results in an error. This histogram replaces Android.WebView.MediaIntegrity.TokenProviderCreationTimeV2 by extending the range of valid values from 10 seconds to 3 minutes. isaacmadgwick@chromium.org pbirk@chromium.org src/android_webview/OWNERS Records the memory usage by mFavicon in AwContents in the java side. This is to determine how much memory is being used by favicons in Java. This histogram is logged everytime onReceivedIcon is called. This histogram replaces Android.WebView.Memory.FaviconJavaAllocatedMemory, which was configured with a min-value of 1000, and thus put most values in the 0 bucket. ntfschr@chromium.org carlosil@chromium.org src/android_webview/OWNERS Records the mixed content mode set when an app uses the WebSettings.setMixedContentMode API. isaacmadgwick@chromium.org src/android_webview/OWNERS For each navigation e.g. loadUrl, this histogram records if a Favicon is downloaded or not. This is recorded by the value of AwContents::ShouldDownloadFavicon. Emitted everytime a WebView page navigation attempts to download a Favicon. torne@chromium.org src/android_webview/OWNERS For each committed navigation in the main frame of a WebView, records whether this was the initial navigation, a same-document navigation, or in all other cases whether it is same- or cross-origin and whether it was triggered by the browser or renderer. Navigations that do not commit (interrupted, HTTP 204, etc) are not counted. torne@chromium.org src/android_webview/OWNERS Records the type of UID that WebView is running as if it's not a standard application UID. This is recorded once during WebView startup on SDK30+ devices. 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 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). 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. ntfschr@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. ntfschr@chromium.org ziadyoussef@chromium.org src/android_webview/OWNERS This captures three pieces of information about renderer crashes: did the app developer handle the renderer crash to recover, what type of crash was this and was the app in foreground or background? This is recorded once each time the renderer process dies unexpectedly, and is logged after we have notified the app via the onRenderProcessGone() callback. Note that the foreground/background state tracked here is different from the foreground/background state of WebView that we typically track. Those track the state of the WebViews in an app while this tracks the state of the app as a whole. 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. peconn@chromium.org src/android_webview/OWNERS The time from when AwContents.loadUrl is called on the UI thread to when the network request for the URL starts. Recorded only for API initiated page loads. peconn@chromium.org src/android_webview/OWNERS The time from when AwContents.loadUrl is called on the UI thread to when the first contentful paint occurs for the loaded page. Recorded only for API initiated page loads. peconn@chromium.org src/android_webview/OWNERS Records the duration of a {Protocol} preconnected session in WebView. This is the time elapsed between connection opening and closing. Logged when the preconnected session is closed. peconn@chromium.org src/android_webview/OWNERS Records events during the WebView preconnect lifecycle. Logged when the preconnect process begins and when the session is closed. peconn@chromium.org src/android_webview/OWNERS Records the setup latency of a {Protocol} preconnected session in WebView. Logged when the connection is established. tasak@google.com lizeb@chromium.org ziadyoussef@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. Warning: this histogram was expired from 2025-04-30 to 2025-12-12; data may be missing. taiyo@chromium.org wbjacksonjr@chromium.org webview-team@google.com Records the result of prefetch API calls, distinguishing between UI thread and worker thread calls, and success/failure states. Recorded when a prefetch request is initiated (or fails validation). wbjacksonjr@chromium.org webview-team@google.com The delay between when an application starts a prefetch request on a background and when that prefetch actually executes on the UI thread. This is recorded every time WebView sends a prefetch request to the prefetch infrastructure inside of //content, it is not recorded for prefetches that are deemed as duplicate (or error out) and thus never reach //content. elabadysayed@chromium.org src/android_webview/OWNERS A profile can be created from several code paths, including the AsyncStartupWebView API. This histogram specifically records when ProfileStore.getOrCreateProfile() is triggered by that startup path. ziadyoussef@chromium.org src/android_webview/OWNERS Records the fate of a renderer process that was kept alive pending reuse. Recorded when a renderer enters the pending reuse state, when it is reused by a new WebView, or when the keep-alive timer expires. This metric is only recorded if the WebViewRendererKeepAlive feature is enabled. ziadyoussef@chromium.org src/android_webview/OWNERS Records the time elapsed from when a renderer process entered the pending reuse state until it was reused by a new WebView. Only recorded if the process was reused before the keep-alive timer expired. This metric is only recorded if the WebViewRendererKeepAlive feature is enabled. pbirk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records whether the SafeBrowsingClient.getSupportedThreatTypes API call returns a result which matches our disk cache. This does not record the actual value of that call: a log of "true" means that the return value matches the disk cache and a log of "false" means that the disk cache didn't match. This histogram is recorded when the task completes successfully. Note: Prior to M151, timeouts and errors were recorded as a consent value of false. pbirk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records the duration of the call to SafeBrowsingClient.getSupportedThreatTypes during the flow to determine if restricted content blocking should be enabled. This histogram is recorded when the task completes, which can be on either success, failure, or timeout. pbirk@chromium.org ntfschr@chromium.org src/android_webview/OWNERS Records the result of the call to SafeBrowsingClient.getSupportedThreatTypes during the flow to determine if restricted content blocking should be enabled. It will log success/failure/timeout. This histogram is recorded when the task completes, which can be on either success, failure, or timeout. ntfschr@chromium.org src/android_webview/OWNERS Records which SafeModeAction was executed. This is recorded once during WebView startup and only if SafeMode is enabled (see "Android.WebView.SafeMode.SafeModeEnabled"). 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. ntfschr@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. jdeabreu@chromium.org src/android_webview/OWNERS Recorded whenever an embedder calls WebView#saveState, for each navigation entry saved, records whether any headers are associated with the entry. This is logged even if the feature to save the headers to saveState is disabled. This data will be used to check that no headers are currently being passed through via AwContents#loadUrl or any other flow and that headers are being passed through once the new AwContents#navigate method is being used. peconn@chromium.org src/android_webview/OWNERS Recorded whenever an embedder calls WebView#saveState, it records the size of that state in KB. The size isn't expected to exceed 1MB, as that is the limit for Android saveInstanceState. ntfschr@chromium.org src/android_webview/OWNERS Records the action WebView took (if any) to "fix up" secure cookies for backwards compatibility. pbirk@google.com src/android_webview/OWNERS Records whether WebView handled a navigation by sending a browsing intent or not. The default behavior is to send a browsing intent for navigations and redirects, but this behavior is disabled if the application provides a WebViewClient of any kind. The aim of this histogram is to determine if any applications use the default behavior. This histogram is emitted when WebViewClient.shouldOverrideUrlLoading is called. 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(). torne@chromium.org src/android_webview/OWNERS Records the layout algorithm requested in each call to WebSettings.setLayoutAlgorithm(). pbirk@chromium.org src/android_webview/OWNERS Logs whether the application used the option to provide multiple Set-Cookie headers through WebResourceResponseCompat. The histogram aims to track adoption of the new API to provide response cookies through shouldInterceptRequest. Logged when the application responds to shouldInterceptRequest calls for either the WebView or service workers with a non-null response. peconn@chromium.org src/android_webview/OWNERS Whether a WebViewClient passed into setWebViewClient has overridden the shouldInterceptRequest method. Recorded when setWebViewClient is called. pbirk@chromium.org src/android_webview/OWNERS Records the total time spent processing work to provide cookie headers to apps. This is recorded when WebViewInterceptedCookieHeader is enabled and after the mojo call returns with the cookie jar contents. This is recorded on all devices. pbirk@chromium.org src/android_webview/OWNERS Measures the total time for shouldInterceptRequest in WebView, from the time the invocation is posted to the worker thread pool, until the response is posted back to the IO thread. pbirk@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. Not all requests will result in the callback being invoked, and thus the histogram will not be emitted in these cases. Some non-exhaustive edge cases include post-redirect requests not invoking the callback, and callbacks being triggered by non-network requests, such as data URIs. 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. Warning: this histogram was expired from 2024-06-13 to 2025-04-14; data may be missing. peconn@chromium.org src/android_webview/OWNERS Whether WebView skipped running shouldInterceptRequest because the embedder hadn't overridden it (and hadn't provided the async version either). This is logged in the shouldInterceptRequest flow before jumping onto the background thread. pbirk@chromium.org src/android_webview/OWNERS Records the total time spent processing work to update the cookie jar. This is recorded when WebViewInterceptedCookieHeader is enabled and a set-cookie header is provided by a site embedded in the app. This is recorded on all devices. 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. abhijithnair@chromium.org src/android_webview/OWNERS Measures the time taken to initialize shared preferences and cached flags in WebViewChromiumFactoryProvider.initialize(). Only measured in Android WebView. abhijithnair@chromium.org src/android_webview/OWNERS Reports whether or not `checkNeedsPost` (https://source.chromium.org/chromium/chromium/src/+/main:android_webview/glue/java/src/com/android/webview/chromium/SharedWebViewChromium.java;l=208;drc=6712edb4e0491c96b69c7346ac278e5c093b6584) is called on the Chromium UI thread. Conditions for recording this metric: Chromium is initialized and AwContents is not null. `checkNeedsPost` is called by various WebView APIs. Only recorded on Android WebView. abhijithnair@chromium.org src/android_webview/OWNERS Reports whether or not `checkNeedsPost` (https://source.chromium.org/chromium/chromium/src/+/main:android_webview/glue/java/src/com/android/webview/chromium/SharedWebViewChromium.java;l=208;drc=6712edb4e0491c96b69c7346ac278e5c093b6584) is called before Chromium is initialized or not. `checkNeedsPost` is called by various WebView APIs. Only recorded on Android WebView. colibie@google.com src/android_webview/OWNERS For synchronous WebView initialization, this value measures the entire duration of running StartupTasksRunner's tasks together without yielding the UI thread, and will equal the "Android.WebView.Startup.CreationTime.StartChromiumLocked" histogram. For asynchronous initialization, it measures the longest task run by StartupTasksRunner. This histogram is recorded in the last step of chromium init and so, is not recorded when init does not complete for any reason or if init had been completed in previous runs. colibie@google.com src/android_webview/OWNERS Records the completion sequence of the WebView's Chromium initialization, indicating whether startup was fully synchronous, fully asynchronous, or a hybrid approach. This metric is only recorded upon successful completion of the initialization process. colibie@google.com src/android_webview/OWNERS The wall clock time it takes to start up Chromium. This is different from ("Android.WebView.Startup.CreationTime.StartChromiumLocked") because for async startup, it includes the time spent in-between startup tasks. abhijithnair@chromium.org torne@chromium.org src/android_webview/OWNERS The total time to add WebView assets to AssetManager. Reported on S+. This task is performed and measured in the framework. This time is included in `Android.WebView.Startup.CreationTime.TotalFactoryInitTime`. abhijithnair@chromium.org torne@chromium.org src/android_webview/OWNERS The total time to create the WebView APK context. Reported on S+. This task is performed and measured in the framework. This time is included in `Android.WebView.Startup.CreationTime.TotalFactoryInitTime`. torne@chromium.org src/android_webview/OWNERS How long it takes to initialize the first WebViewChromium instance in the case where we have already finished the process-global browser startup: ("Android.WebView.Startup.CreationTime.StartChromiumLocked") was already complete and did not need to be performed during the instance initialization. This is recorded separately as it is significantly faster than the "FirstInstanceWithGlobalStartup" case, but slower than the "NotFirstInstance" case. torne@chromium.org src/android_webview/OWNERS How long it takes to initialize the first WebViewChromium instance in the case where we had to also do the process-global browser startup: ("Android.WebView.Startup.CreationTime.StartChromiumLocked") had not yet run and was performed during the instance initialization. This is recorded separately as it is significantly slower than the "FirstInstanceAfterGlobalStartup" and "NotFirstInstance" cases. abhijithnair@chromium.org torne@chromium.org src/android_webview/OWNERS The total time to create the WebView ClassLoader. Reported on S+. This task is performed and measured in the framework. This time is included in `Android.WebView.Startup.CreationTime.TotalFactoryInitTime`. abhijithnair@chromium.org torne@chromium.org src/android_webview/OWNERS The total time taken by `getWebViewProviderClass` method (https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/webkit/WebViewFactory.java;l=270;drc=61197364367c9e404c7da6900658f1b16c42d0da) in the framework. Reported on S+. This task is performed and measured in the framework. This time is included in `Android.WebView.Startup.CreationTime.TotalFactoryInitTime`. torne@chromium.org src/android_webview/OWNERS Records the reason for initialization (startChromium call), such as creating a WebView instance, calling a static method through getStatics() or other static methods. The older version of this histogram (Android.WebView.Startup.CreationTime.InitReason) used a less granular callsite enum. If any WebView instance methods or static method was the callsite, we couldn't know which exact method it was since it was grouped together as the same callsite. This issue is fixed in this histogram. Warning: this histogram was expired from 2026-01-01 to 2026-01-26; data may be missing. abhijithnair@chromium.org torne@chromium.org src/android_webview/OWNERS The total time to load the WebView native library for the first time. Reported on S+. This also includes the time taken for processing relocations using the relro sharing mechanism. This task is performed and measured in the framework. This time is included in `Android.WebView.Startup.CreationTime.TotalFactoryInitTime`. torne@chromium.org src/android_webview/OWNERS How long it takes to initialize a subsequent WebViewChromium instance. This will be recorded once for each instance created, other than the first to be created in the current process. This is recorded separately as it is significantly faster than the "FirstInstanceWithGlobalStartup" and "FirstInstanceAfterGlobalStartup" cases. torne@chromium.org src/android_webview/OWNERS How long it takes to run WebViewChromiumFactoryProvider.initialize(). This does not count the time spent beforehand in WebViewFactory in the Android framework, which first has to load the WebView code and do some basic setup before initialize() can be called. This will be recorded once per host process since the initialization is process-global. The "Android.WebView.Startup.CreationTime.TotalFactoryInitTime" histogram measures the entire duration from when WebViewFactory.getProvider() is first called until the WebViewChromiumFactoryProvider is fully initialized and should be preferred for most purposes, but is only recorded on Android S+ devices, so this older metric is retained for now to allow "fair" comparisons with Android R and earlier. torne@chromium.org src/android_webview/OWNERS For synchronous WebView initialization, this value measures the entire duration of running StartupTasksRunner's tasks together without yielding the UI thread, and will equal the "Android.WebView.Startup.ChromiumInitTime.LongestUiBlockingTaskTime" histogram. For asynchronous initialization, it measures the cumulative duration of each task run by the StartupTasksRunner on the UI thread. This reflects the total time StartupTasksRunner's tasks block the UI thread. It does not measure the wall clock time from the start of the first task to the end of the last task. This histogram is recorded in the last step of chromium init and so, is not recorded when init does not complete for any reason or if init had been completed in previous runs. This histogram is of special interest, do not change its semantics or retire it without talking to the owners first. 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. abhijithnair@chromium.org src/android_webview/OWNERS The total time to initialize WebViewChromiumFactoryProvider if the initialization is done on the main looper. 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. abhijithnair@chromium.org src/android_webview/OWNERS The total time to initialize WebViewChromiumFactoryProvider if initialization is not on the main looper. 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. torne@chromium.org src/android_webview/OWNERS Records how long it took to wait for the UI thread before running startChromium. Only recorded if startChromium was posted as a task. Recorded in M125+. abhijithnair@chromium.org src/android_webview/OWNERS Reports whether or not the Chromium UI thread is the Android main looper. Recorded once during WebView process global startup. Only recorded on Android WebView. torne@chromium.org src/android_webview/OWNERS Recorded after successfully acquiring the WebView data dir lock based on the number of retry attempts and whether we saw an OverlappingFileLockException. This is not recorded when we run out of retries and fail to acquire the lock because this case throws an exception - we don't complete startup and so would never actually store and upload the metric value. This does not record the exact number of retries, just a few buckets - we're primarily interested in whether OverlappingFileLockException is involved and whether retrying provides any value at all. ntfschr@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. Warning: this histogram was expired from 2023-09-01 to 2025-07-29; data may be missing. elabadysayed@chromium.org src/android_webview/OWNERS Records whether a {Operation} operation in WebView was blocked waiting for synchronous NetworkContext initialization. Only measured in Android WebView. elabadysayed@chromium.org src/android_webview/OWNERS Records the duration that a {Operation} operation in WebView was blocked waiting for synchronous NetworkContext initialization. Recorded only when blocked. Only measured in Android WebView. abhijithnair@chromium.org src/android_webview/OWNERS Records whether getDefaultUserAgent was called on the UI thread or not. Emitted only if browser startup has not been started during the time of the call. This is only logged in Android WebView. ntfschr@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 call to GMS Core, which checks if the url is allowed. This is recorded during each URL load, however only for the resource types which undergo this type of URL check. Note: This histogram was expired between 2025-08-01 and 2025-12-02, data may be missing. ntfschr@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. This is recorded during each URL load, however only for the resource types which undergo this type of URL check. Note: This histogram was expired between 2025-08-01 and 2025-12-02, data may be missing. ntfschr@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. This metric is only recorded on the first call to GMS Core. This is recorded only for the first URL load, and only for the resource types which undergo this type of URL check. Note: This histogram was expired between 2025-08-01 and 2025-12-02, data may be missing. ntfschr@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. This metric is not recorded on the first call, only on subsequent ones. This is recorded during each URL load after the initial load, however only for the resource types which undergo this type of URL check. Note: This histogram was expired between 2025-08-01 and 2025-12-02, data may be missing. 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. pbirk@chromium.org src/android_webview/OWNERS Time spent on the main thread waiting for background tracing init to finish. This histogram is emitted a the point where WebView determines if tracing should start on the main browser thread, since that is the point where the startup code assumes that tracing is initialized. The histogram is only emitted if tracing was initialized on a bachground thread, and it measures the time spent waiting on the main thread for this initialization to finish. Any values higher than 0 indicate that tracing did not manage to initialize fully on the background thread before the main thread reached the point where tracing is required. The purpose of this histogram is to determine if background initialization of tracing provides an overall benefit to WebView Startup Time. 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. peconn@chromium.org src/android_webview/OWNERS Recorded when a WebView is attached to the window. Records whether the window the WebView is attached to is a PopupWindow. 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. 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. ziadyoussef@chromium.org src/android_webview/OWNERS Reports the sync blocking time for the warm up renderer process API call. Recorded once per call to the warm up renderer process API. ziadyoussef@chromium.org src/android_webview/OWNERS Reports whether or not the warm up renderer process API call starts a new process. Recorded once per call to the warm up renderer process API. ntfschr@google.com src/android_webview/OWNERS Records whether the app calling setWebAuthenticationSupport with BROWSER mode has the CREDENTIAL_MANAGER_SET_ORIGIN permission. This permission has always been required for browser mode; however, if it is missing, the app will only crash later at the time of performing WebAuthn operations. This is recorded once per API call to setWebAuthenticationSupport, but only if the app is requesting BROWSER mode. This will help evaluate if we can safely throw a SecurityException earlier to indicate when apps are missing this permission. bewise@chromium.org src/android_webview/OWNERS Recorded every time AwContents.adopt() is called to transfer WebView state to a new WebView instance. Adopt is triggered by app developers using the WebContent API. Captures successful adoptions as well as precondition check failures (e.g. view attachment races or destroyed instances). kalutes@google.com clank-large-form-factors@google.com Records the duration a window was occluded. Recorded when a window is unoccluded or destroyed. kalutes@google.com clank-large-form-factors@google.com Records the duration spent in each bucket of the maximum of all the minimum dimensions of visible rects for a window. This value gives a rough idea of 'how much a window is visible by'. For example, if a window has two visible rects on the left and top sides with dimensions of 1000x20 and 50x1000, respectively, then this metric value will be 50 and count towards the 31-50 bucket. This metric is logged when the bucket changes for a WindowAndroid instance or when the window is destroyed. kalutes@google.com clank-large-form-factors@google.com Records the number of WindowAndroid instances that are currently occluded. Recorded periodically every 5 minutes. kalutes@google.com clank-large-form-factors@google.com Records the percentage of the window's lifetime that it spent occluded. Recorded when the window is destroyed. kalutes@google.com clank-large-form-factors@google.com Records the total occluded pixels over time in megapixel*seconds since the last emission. This metric gives an estimate of the saved rendering work due to occlusion optimizations. Recorded periodically every 5 minutes. kalutes@google.com clank-large-form-factors@google.com Records the sum total pixel area of all occluded windows in megapixels. If there are 3 separate 1000x1000 pixel windows that are occluded, the value of this metric would be 3. Sampled periodically every 5 minutes. No accumulation is performed, only the instanntaneous value at every 5 minute interval is reported. chominskib@google.com lt-web-apps-team@google.com Records the time it takes to acquire on-screen bounds of the browser window by the `WindowAndroid::GetBoundsInScreenCoordinates()` method. chominskib@google.com lt-web-apps-team@google.com Records the time it takes to process a window bounds change event received from the OS, including notifying native counterparts and sending new bounds to Blink in native part. Recorded only if the window bounds have actually changed compared to values cached in the WindowAndroid Java object. aishwaryarj@google.com zheliooo@google.com clank-large-form-factors@google.com Records the window width in density-independent pixels (dp) when a Chrome window is first opened or resized. lizeb@chromium.org pasko@chromium.org Recorded when RELRO is replaced with a shared memory region, in all processes consuming RELRO. Indicates whether the shared RELRO was available synchronously right after the native library was loaded. ModernLinker only. lizeb@chromium.org pasko@chromium.org Recorded when the native library is loaded by the Chromium linker, and an attempt to spawn a shared RELRO region is made. Indicates whether the attempt was a success. If the number of samples from "ChromiumAndroidLinker.RelroAvailableImmediately" where the availability was not immediate is large compared to the counts of successful RELRO spawns, it would indicate potential startup performance improvements when starting child process(es) during early browser startup phases. ModernLinker only. lizeb@chromium.org pasko@chromium.org Recorded when RELRO is replaced with a shared memory region, in all processes consuming RELRO. Indicates whether the replacement was a success. ModernLinker only. See a description of RELRO sharing here: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/android_native_libraries.md#RELRO-Sharing Warning: this histogram was expired from 2022-12-04 to 2023-09-07; data may be missing. pasko@chromium.org rsesek@chromium.org The amount of time it took to load the native libraries in {ProcessType}. In order to explain the nature of the uploaded samples for this histogram it is necessary to define a few core properties of the running processes. On Android 10 (=Q) a new feature was introduced and became used in Chrome: App Zygotes. An App Zygote (AZ) is a process pre-created by the system to allow faster initialization of isolated processes (IP) for a specific app. When AZ is created it runs the app-specific "preload" function once, and becomes idle, after that no work can be performed in the AZ other than getting forked. Whenever an app requests the Android Framework (AF) to provide an isolated process, the AF notifies the AZ to fork itself into a new process, which later will be provided to the app. An AZ created for one app (package) cannot be used for another app. The purpose of the AZ in Chrome is to load the native library - it avoids loading the same library in each isolated process separately. Capabilities of the AZ are very restricted. It runs in the same sandbox constraints as an isolated process, while also not having the ability to communicate with any other process on the system. Only after forking from the AZ the inherited process becomes able to communicate to the rest of Chrome. Beyond isolated processes, Chrome can request processes with more privileges: privileged processes (PP). In this case those processes will be forked from another zygote. There are several types of those zygotes, we will refer to them as Other Zygote (OZ) for simplicity. The decisions whether to start an isolated process through an AZ, and when to start a new AZ are made dynamically and depends on a few factors. The suffixes of this histogram, as described below, correspond to distinct execution scenarios: Suffix "Browser": the native library is loaded in the main app process Suffix "Zygote": OZ forks into AZ, AZ loads the native library, AZ forks into IP Suffix "Child": OZ forks into PP, PP loads the native library Suffix "Child": OZ forks into IP, IP loads the native library Suffix "Child": OZ forks into AZ, AZ fails to load the native library, AZ forks into IP, IP loads the native library (this scenario should happen rarely). After library loading happens in the AZ, the recorded histogram value (for simplicity) gets copied to each child process forked from this AZ process and uploaded "as if" it is a unique sample from this child process. This leads to a discrepancy in sample counts. In early 2021-10 it had about 7% extra uploaded samples in "ChromiumAndroidLinker.ZygoteLoadTime2". pasko@chromium.org agrieve@chromium.org The amount of CPU time (thread time) it took to load the native libraries in {ProcessType}. For a more detailed description of each suffix process type suffix (Browser, Child, Zygote) see description of the ChromiumAndroidLinker.*LoadTime2. twellington@chromium.org clank-app-team@google.com Overscroll gesture was made beyond a threshold big enough to regard it as a valid gesture navigation i.e. at least 1/3 of the arrow puck is visible. Similar to 'Triggered' but is used in pair with 'Cancelled' on M81 forward to measure cancellation rate. Implemented for Android. twellington@chromium.org clank-app-team@google.com Overscroll gestures that were cancelled before they were completed. Similar to 'Abandoned' but is used in pair with 'Activated' on M81 forward to measure cancellation rate. Implemented for Android. twellington@chromium.org clank-app-team@google.com Navigations that were triggered due to completed overscroll gesture. Implemented for Android. twellington@chromium.org clank-app-team@google.com Overscroll gesture was made to trigger navigation, but within 3 seconds user used overscroll gesture to navigate back to the page. Implemented for Android. twellington@chromium.org clank-app-team@google.com Gesture navigation type. It can be either Chrome's own gesture UI that supports back and forward navigation or OS-provided default system gesture navigation that supports only back action on both left and right edge. This is recorded on Chrome startup at the feature component initialization. ckitagawa@chromium.org meiliang@chromium.org This histogram records the frame rate of the transition animation between Tab and Grid Tab Switcher. {GridTabSwitcherAnimationType} ckitagawa@chromium.org meiliang@chromium.org This histogram records the maximum interval between rendered frames during the transition animation between Tab and Grid Tab Switcher. {GridTabSwitcherAnimationType} zhiyuancai@chromium.org wychen@chromium.org ayman@chromium.org Records why the {GridTabSwitcherMessageType} is disabled in GridTabSwitcher and will no longer be shown to users. Recorded when the message is disabled. Implemented for Android.