Mobile settings

Learn how to control how Test Companion handles system permission dialogs on Android and iOS devices during testing.

Mobile app test sessions frequently trigger system permission dialogs for camera, location, notifications, and other capabilities. Tests can run on devices with locked orientation or network conditions, and produce logs you may want to capture. These dialogs can block test execution if they are not handled. The mobile settings lets you set defaults for these behaviors, so every new session starts in a known state. You can override individual settings in the panel before saving.

Configure mobile settings

1. Click the gear icon (⚙) in the top-right corner of the Test Companion panel.

   

2. Click the Mobile Settings tab in the sidebar.

   

3. Make the necessary changes and click Save to apply them.
4. Click Cancel to discard any unsaved changes.

The panel has two regions:

• Session overrides apply at the start of every new session. They control Android and iOS system dialogs, network conditions, device orientation, and bypasses for biometric, passcode, and certificate flows.
• Diagnostics defaults control which logs and recordings Test Companion captures during every new session.

Session overrides

Session overrides apply once when each new session starts. They stay in effect for the full session unless your test script changes them at runtime.

Android permission handling

Android apps trigger runtime permission dialogs for capabilities like camera, location, and storage. Choose how Test Companion handles these dialogs.

• Auto-grant permissions: Test Companion grants every Android runtime permission automatically. Permission dialogs do not appear during the session. Use this when your tests do not need to validate permission denial flows, and you want uninterrupted execution.

• Default (Test Companion): Test Companion takes no action when a permission dialog appears. The dialog renders on the device exactly as it would for a real user. Whatever drives the session, your test script or a manual tester, must tap Allow or Don’t allow itself. Use this when your tests need to validate both granted and denied permission flows.

Default is selected when you first open the panel.

iOS alert handling

iOS distinguishes between accepting and rejecting system permission alerts, so iOS offers one more option than Android.

• Auto-accept alerts: Test Companion accepts every iOS system permission alert automatically. Alerts for camera, location, notifications, and similar capabilities do not interrupt the session. Use this when your tests assume permissions are granted, and you want to eliminate alert handling from the script.

• Auto-dismiss alerts: Test Companion dismisses every iOS system permission alert automatically, which is equivalent to denying the permission. Use this when you need to verify that your app handles permission denials correctly. For example, testing the fallback when a user denies camera access.

• Default (Test Companion): Test Companion takes no action when an alert appears. The alert renders on the device exactly as it would for a real user. Whatever drives the session must tap the alert button itself. Use this when your tests need to validate both acceptance and denial on a case-by-case basis.

Default is selected when you first open the panel.

Network conditions

Apply a predefined network profile to simulate real-world conditions like 2G, lossy 4G, or no connectivity. The selected profile applies for the full session.

The dropdown contains three categories of options:

• Default uses the device’s unrestricted Wi-Fi connection. Selected by default.
• No Network disables the network on the device, equivalent to airplane mode.
• 15 measurable profiles simulate specific bandwidth, latency, and packet loss combinations. The full list and values are below.

Network conditions map to the networkProfile capability and are not supported for proxy-unaware applications.

Orientation

Lock the device to Portrait or Landscape for the full session. Test Companion sets this once at session start and does not rotate the device automatically during the session.

Portrait is selected when you first open the panel. Orientation maps to the deviceOrientation capability.

Biometric bypass

Select Biometric bypass to test app flows that rely on Touch ID, fingerprint sensors, or Face ID. Test Companion injects a sensor instrumentation layer that replaces the real biometric prompt with a Pass / Fail / Cancel control your test script can drive. Use this when your tests need to verify what happens after biometric success, failure, or cancellation.

Biometric bypass maps to the enableBiometric capability.

Passcode bypass

Select Passcode bypass to run sessions on a passcode-protected device. BrowserStack devices are not passcode-protected by default. When you enable this option, the device is provisioned with a passcode that your test script can use to validate flows like banking app login or payment confirmation.

The default passcode is 1234 on Android and 123456 on iOS. Your test script must enter the passcode through the keyboard. Passcode bypass maps to the testPasscode capability.

Insecure certificates

Select Insecure certificates to allow the session to trust self-signed and otherwise invalid SSL/TLS certificates. Use this when your app connects to a development or staging server that does not use a publicly trusted certificate. With this option off, the session rejects untrusted certificates and HTTPS calls fail.

Insecure certificates maps to the acceptInsecureCerts capability.

Diagnostics defaults

Diagnostics defaults control which logs and recordings Test Companion captures during every new session. Each option is independent. Turn on only what you need, because some captures add overhead to the session.

When you first open the panel, Device logs and Video recording are selected. The other three options are off.

• Network logs: Captures all HTTP and HTTPS requests and responses made by the app during the session, exported in HAR format. Use this to inspect timing, headers, payloads, and status codes for every network call. It maps to the networkLogs capability.

• Device logs: Captures Logcat output on Android and the system console on iOS. Use this to debug crashes, ANRs, and runtime errors that the app surfaces through standard device logging. It maps to the deviceLogs capability.

• Appium logs: Captures the raw Appium server logs for the session. Use this to debug issues with locator strategies, command timeouts, or the test framework itself. It maps to the appiumLogs capability.

• App profiling: Captures CPU, memory, battery, and network usage metrics during the session. Use this to identify performance regressions, memory leaks, or battery drain caused by your app. Maps to the appProfiling capability.

• Video recording: Captures a full-session video of the device screen. Use this to reproduce visual bugs, review test failures, and share session playback with your team. It maps to the video capability.