IssueTracker

Translation:

Component used:StartupTimingMetric
Version used: 1.1.0-alpha13
Devices/Android versions reproduced on:R

Test engineering description:
The test project is a multi-process project, the package name is com.example.demo, but all UI interfaces of the application are implemented in the com.example.demo:ui process.

Analysis of the cause of the problem:
In the getMetrics method, the StartupTimingQuery.getFrameSubMetrics parameter is called and the PackageName is passed in, and the parameter source is
Marcobenchmark.kt
val iterationResult = userspaceTrace("extract metrics") {
                metrics
                    // capture list of Map<String,Long> per metric
                    .map { it.getMetrics(Metric.CaptureInfo(
                        targetPackageName = packageName,
                        testPackageName = macrobenchPackageName,
                        startupMode = startupModeMetricHint,
                        apiLevel = Build.VERSION.SDK_INT
                    ), tracePath) }
                    // merge into one map
                    .reduce { sum, element -> sum + element }
            }
 Query statement: val queryResult = PerfettoTraceProcessor.rawQuery(
            absoluteTracePath = absoluteTracePath,
            query = getFullQuery(
                testProcessName = testPackageName,
                targetProcessName = targetPackageName
            )
        )

private fun getFullQuery(testProcessName: String, targetProcessName: String) = """
        ------ Select all startup-relevant slices from slice table
        SELECT
            slice.name as name,
            slice.ts as ts,
            slice.dur as dur
        FROM slice
            INNER JOIN thread_track on slice.track_id = thread_track.id
            INNER JOIN thread USING(utid)
            INNER JOIN process USING(upid)
        WHERE (
            (process.name LIKE "$testProcessName" AND slice.name LIKE "startActivityAndWait") OR
            (
                process.name LIKE "$targetProcessName" AND (
                    (slice.name LIKE "activityResume" AND process.pid LIKE thread.tid) OR
                    (slice.name LIKE "Choreographer#doFrame%" AND process.pid LIKE thread.tid) OR
                    (slice.name LIKE "reportFullyDrawn() for %" AND process.pid LIKE thread.tid) OR
                    (slice.name LIKE "DrawFrame%" AND thread.name LIKE "RenderThread")
                )
            ) OR
            (
                -- Signals beginning of launch event, only present in API 29+
                process.name LIKE "system_server" AND
                slice.name LIKE "MetricsLogger:launchObserverNotifyIntentStarted"
            )
        )
        ------ Add in async slices
        UNION
        SELECT
            slice.name as name,
            slice.ts as ts,
            slice.dur as dur
        FROM slice
            INNER JOIN process_track on slice.track_id = process_track.id
            INNER JOIN process USING(upid)
        WHERE (
            -- API 23+: "launching: <target>"
            -- API 19-22: "launching"
            slice.name LIKE "launching%" AND process.name LIKE "system_server"
        )
        ORDER BY ts ASC
    """.trimIndent()

The packagename will be used as a restriction, resulting in no query results.

For users, this parameter cannot be modified to achieve the purpose of querying the correct process.


Proposed changes:
(1) When the Metric object is a specific process, the open parameter is passed in the specified process name (the default value is the package name). For example: FrameTimingGfxInfoMetric, FrameTimingMetric, StartupTimingMetric.

(2) At present, Metric is sealed, it is recommended to open it to users to give users more space to customize Metric.

Would the following change to app process.name matching work for your scenario, to make it match your :ui process?

(process.name LIKE "$targetProcessName") OR (process.name LIKE "$targetProcessName:%") (I should probably also rename that variable targetPackageName since it's not process name).

I'd like to avoid adding an API for this if we can, so it will simply work for multiprocess apps.

We do plan to open up other means of constructing your own metric, but are focusing on getting to a stable release first.

Re #comment4 - thanks, fuzzy matching just landed above, please try it out (should be available in next beta 04) and let us know if that works for you. We're working through bugs to get to stable, hopefully fairly soon.

To your earlier point, about opening up the metrics APIs, I agree, and we'll be looking into that for 1.2 - b/219851406

Thanks for the bug report!