Btrace Perfetto

Step 1: Parse Arguments

If no arguments are provided, ask the user what they want to trace and which branches to compare. If only one branch is given, capture only that branch (no comparison).

Step 2: Integrate btrace into Sample App

The sample app is at sentry-samples/sentry-samples-android/.

2a: Add btrace dependency

In sentry-samples/sentry-samples-android/build.gradle.kts, add to the dependencies block:

implementation("com.bytedance.btrace:rhea-inhouse:3.0.0")

2b: Restrict ABI to device architecture

The btrace native library (shadowhook) does not support x86/x86_64. Replace the ndk abiFilters line in defaultConfig to match the connected device:

ndk { abiFilters.addAll(listOf("arm64-v8a")) }

Adjust if the device reports a different ABI.

2c: Initialize btrace in Application

In MyApplication.java, add attachBaseContext:

import android.content.Context;
import com.bytedance.rheatrace.RheaTrace3;

// Add before onCreate:
@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    RheaTrace3.init(base);
}

Important: The package is com.bytedance.rheatrace, not com.bytedance.btrace.

2d: Add ProGuard keep rules (release builds only)

Only needed when building release. In sentry-samples/sentry-samples-android/proguard-rules.pro, add:

-keep class com.bytedance.rheatrace.** { *; }
-keepnames class io.sentry.** { *; }

The first rule prevents R8 from stripping btrace's HTTP server classes (fails with SocketException otherwise). The second preserves Sentry class and method names so they appear readable in the Perfetto trace instead of obfuscated single-letter names.

Step 3: Build and Install

Prefer debug builds — they provide richer tracing instrumentation (Handler, MessageQueue, Monitor:Lock slices visible) which is essential for comparing internal SDK behavior. Use the default 1kHz btrace sampling rate for debug builds.

./gradlew :sentry-samples:sentry-samples-android:installDebug

Release builds are useful when you need to measure real-world performance without StrictMode/debuggable overhead or with R8 optimizations. Require the ProGuard keep rules from step 2d. Use -sampleInterval 333000 (333μs / 3kHz) for finer granularity since release code runs faster.

./gradlew :sentry-samples:sentry-samples-android:installRelease

Step 4: Capture Trace

For each branch to trace:

4a: Set btrace properties and launch app

Clear any stale port files, set properties, and launch:

adb shell "rm -rf /storage/emulated/0/Android/data/io.sentry.samples.android/files/rhea-port"
adb shell setprop debug.rhea3.startWhenAppLaunch 1
adb shell setprop debug.rhea3.waitTraceTimeout 60
adb shell am force-stop io.sentry.samples.android
sleep 2
adb shell am start -n io.sentry.samples.android/.MainActivity
sleep 5

The app must be started AFTER debug.rhea3.startWhenAppLaunch is set, otherwise the trace server won't initialize. The 5s sleep after launch gives the btrace HTTP server time to start.

4b: Play a sound to signal the user, then capture

Play a sound when tracing actually starts so the user knows to begin interacting. Pipe btrace output through a loop that triggers the sound on the "start tracing" line:

java -jar tools/btrace/rhea-trace-shell.jar \
  -a io.sentry.samples.android \
  -t ${duration} \
  -waitTraceTimeout 60 \
  -o tools/btrace/traces/${branch_name}.pb \
  sched 2>&1 | while IFS= read -r line; do
    echo "$line"
    if [[ "$line" == *"start tracing"* ]]; then
      afplay -v 1.5 /System/Library/Sounds/Ping.aiff &
    fi
  done

For release builds with finer sampling, add -sampleInterval 333000.

Do NOT use the -r flag — it fails to resolve the launcher activity because LeakCanary registers a second one. Launch the app manually in step 4a instead.

4c: Switch branches for comparison

When capturing a second branch:

1. Stash the btrace integration changes:

   git stash push -m "btrace integration" -- \
     sentry-samples/sentry-samples-android/build.gradle.kts \
     sentry-samples/sentry-samples-android/src/main/java/io/sentry/samples/android/MyApplication.java \
     sentry-samples/sentry-samples-android/proguard-rules.pro
   

2. Checkout the other branch
3. Pop the stash: git stash pop
4. Rebuild and install (same variant — debug or release — as the first branch)
5. Repeat steps 4a and 4b with a different output filename
6. Switch back to the original branch and restore files

Step 5: Open in Perfetto UI

Generate a viewer HTML and serve it locally. Use the template at assets/viewer-template.html as a base — copy it to tools/btrace/traces/viewer.html and replace the placeholder values:

• TRACE_FILES: array of {file, title} objects for each captured trace
• SQL_QUERY: the SQL query to prefill

The SQL query is passed via the URL hash parameter: https://ui.perfetto.dev/#!/?query=...

The trace data is sent via the postMessage API (required for local files — URL deep-linking does not work with file://).

Start a local HTTP server and open the viewer:

cd tools/btrace/traces && python3 -m http.server 8008 &
open http://localhost:8008/viewer.html

Default SQL Query

If no custom query is provided, use:

SELECT
  s.name AS slice_name,
  s.dur / 1e6 AS dur_ms,
  s.ts,
  t.name AS track_name
FROM slice s
JOIN thread_track t ON s.track_id = t.id
WHERE s.name GLOB '*SentryWindowCallback.dispatch*'
ORDER BY s.ts

Step 6: Query and Compare Traces

After capturing both branches, use trace_processor to compute comparison stats locally.

Basic stats query

For each trace file, run:

/tmp/trace_processor -Q "
WITH events AS (
  SELECT s.dur / 1e6 as dur_ms FROM slice s
  WHERE s.name GLOB '*${METHOD_GLOB}*' AND s.dur > 0
  ORDER BY s.dur
)
SELECT COUNT(*) as count,
  ROUND(AVG(dur_ms), 4) as avg_ms,
  ROUND((SELECT dur_ms FROM events LIMIT 1 OFFSET (SELECT COUNT(*)/2 FROM events)), 4) as median_ms,
  ROUND(MIN(dur_ms), 4) as min_ms,
  ROUND(MAX(dur_ms), 4) as max_ms
FROM events
" tools/btrace/traces/${trace_file}.pb

Replace ${METHOD_GLOB} with the method pattern to compare (e.g. SentryGestureDetector.onTouchEvent, SentryWindowCallback.dispatchTouchEvent).

Finding child calls (debug builds)

To find what happens inside a method (e.g. Handler calls, lock acquisitions):

/tmp/trace_processor -Q "
WITH RECURSIVE descendants(id, depth) AS (
  SELECT s.id, 0 FROM slice s WHERE s.name GLOB '*${PARENT_METHOD}*'
  UNION ALL
  SELECT s.id, d.depth + 1 FROM slice s JOIN descendants d ON s.parent_id = d.id WHERE d.depth < 10
)
SELECT s.name, COUNT(*) as count, ROUND(AVG(s.dur / 1e6), 3) as avg_ms
FROM slice s JOIN descendants d ON s.id = d.id
WHERE d.depth > 0
GROUP BY s.name ORDER BY count DESC
LIMIT 20
" tools/btrace/traces/${trace_file}.pb

Build the comparison table

Run the stats query on both trace files, then present a markdown table:

| Metric | Branch A | Branch B | Delta |
|--------|----------|----------|-------|
| Count  | ...      | ...      |       |
| Average| ...      | ...      | -X%   |
| Median | ...      | ...      | -X%   |
| Max    | ...      | ...      | -X%   |

Compute delta as (branchA - branchB) / branchB * 100. Negative means branch A is faster.

Sampling rate reference

Higher sampling rates capture shorter method calls but add CPU overhead which can skew results. For most comparisons, the default 1kHz is sufficient.

Cleanup

After tracing is complete, remind the user that the btrace integration changes to the sample app should NOT be committed. The tools/btrace/ directory is gitignored.

Troubleshooting