docs(anr-profiling): Clarify that ANR Profiling is billed under UI Profiling

docs/platforms/android/configuration/app-not-respond.mdx

@@ -115,7 +115,7 @@ ANR Profiling is available starting in SDK version `8.35.0`. This feature is exp
 
 <Alert>
 
-ANR profiles are powered by the Profiling platform and require a plan with profiling enabled. See the [pricing page](https://sentry.io/pricing/) for more details. 
+ANR profiles are powered by the Profiling platform and require a plan with profiling enabled. They are billed as UI Profile Hours. See the [pricing page](https://sentry.io/pricing/) for more details.
 
 ANR profiles _don't_ use ART profiler, but are being captured differently. Therefore, they are not prone to the known [issues](https://docs.sentry.io/platforms/android/profiling/troubleshooting/#i-see-an-elevated-number-of-crashes-in-the-android-runtime-when-profiling-is-activated) with ART's profiler, and are safe to use in production.
 

docs/pricing/quotas/manage-ui-profile-hours.mdx

@@ -13,11 +13,13 @@ You can look at your UI Profile hours in aggregate in the "Usage Stats" tab of t
 
 ## How Can I Sample Profiles?
 
-UI Profiling only supports **client-side** sampling. To control client-side sampling behavior, you can set the `profile_session_sample_rate` configuration parameter to a value between 0.0-1.0 to control the number of profiling sessions that are sampled (the default is 0.0.)
+UI Profiling only supports **client-side** sampling. To control client-side sampling behavior, you can set the `profile_session_sample_rate` configuration parameter to a value between 0.0-1.0 to control the number of profiling sessions that are sampled (the default is 0.0).
+
+Android [ANR Profiling](/platforms/android/configuration/app-not-respond/#anr-profiling-experimental) is also billed as UI Profile Hours. It uses a separate sampling option, `anrProfilingSampleRate`, which controls the probability of collecting a profile for each detected foreground ANR.
 
 For UI Profiling, the initial user session starts when the SDK is initialized, and sampling is first evaluated at this point. The user session will either end on termination of the application **or** depending on the platform, there can be other events that end a user session (like backgrounding a mobile application). The sampling rate will be re-evaluated on each new user session.
 
-For example: In the browser, the user session begins when the tab is opened and the user session ends when the tab is closed. Sampling will be evaluated once at the start of each session, so if `profile_session_sample_rate` is set to 0.5, then 50% of the time your application is opened in a browser tab, profiling will be active for that tab's lifetime. On mobile, the user session begins when the application is started or foregrounded, and the user session ends when the application is terminated or backgrounded. The sampling will be evaluated once at the start of each session, so if `profile_session_sample_rate` is set to 0.5%, then 50% of the time a user opens your mobile app, profiling will be active until the user backgrounds or quits the app.
+For example: In the browser, the user session begins when the tab is opened and the user session ends when the tab is closed. Sampling will be evaluated once at the start of each session, so if `profile_session_sample_rate` is set to 0.5, then 50% of the time your application is opened in a browser tab, profiling will be active for that tab's lifetime. On mobile, the user session begins when the application is started or foregrounded, and the user session ends when the application is terminated or backgrounded. The sampling will be evaluated once at the start of each session, so if `profile_session_sample_rate` is set to 0.5, then 50% of the time a user opens your mobile app, profiling will be active until the user backgrounds or quits the app.
 
 ## How Can I Control When Profiling Is Active?
 
@@ -34,7 +36,9 @@ UI Profiling provides two "lifecycle" modes that can be used to control when the
 
 ### On Mobile
 
-To estimate monthly usage for UI profiling when used on mobile, the calculation is **average user session length in hours * the number of sampled user sessions per month.** For example, if the average user session length is 6 minutes and there are 10,000 sampled user sessions per month, then the total usage os **0.1 hours * 10,000 sessions = 1,000 hours per month.** You can reduce the number of profiling hours by profiling a smaller number of user sessions (reducing `profile_session_sample_rate`), or only profiling devices or configurations that are particularly performance sensitive (like low-end mobile devices).
+To estimate monthly usage for UI profiling when used on mobile, the calculation is **average user session length in hours * the number of sampled user sessions per month.** For example, if the average user session length is 6 minutes and there are 10,000 sampled user sessions per month, then the total usage is **0.1 hours * 10,000 sessions = 1,000 hours per month.** You can reduce the number of profiling hours by profiling a smaller number of user sessions (reducing `profile_session_sample_rate`), or only profiling devices or configurations that are particularly performance sensitive (like low-end mobile devices).
+
+If Android ANR Profiling is enabled, your UI Profile Hours also include the duration of sampled ANR profiles. You can reduce that usage by lowering `anrProfilingSampleRate` or disabling ANR Profiling.
 
 ### In The Browser
 
@@ -63,4 +67,3 @@ To estimate monthly usage for UI Profiling in the browser, the calculation is **
 - If you're using the `trace` profile lifecycle mode, ensure that `traces_sample_rate` or `traces_sampler` are configured appropriately in addition to `profile_session_sample_rate`
 
 See the detailed [migration guide](/product/profiling/continuous-ui-profiling-migration-guide/) for more information.
-