IssueTracker

What version of kotlin are you using?

1.7.10

related b/266687218

Fixed by https://cs.android.com/android-studio/platform/tools/base/+/2553f154c9148529f7bdad459553ca33fffd38d2 for the next canary.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Canary 6
• Android Gradle Plugin 8.3.0-alpha06

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Arif, is this a know issue with instrumented tests?

No this is not a known issue with instrumented tests. Let me see if I can repro.

Hi, I see the test APK containing the flag in the manifest that debuggable="true".

This is correct because the test APK runs out of the target app process and this is also why it can be running with debugger.

Given what I recall of AndroidProcessHandler (the thing that actually prints out "Waiting for processes <name>"), it's probably being handed target app's package name, rather than test APK's package name. If #6 cut and pasted, then that seems to be the case since it's not waiting for com.example.myapplication.test (test APK), but for com.example.myapplication (target APK) instead.

But I'll take a look.

I think there must've been some "recent" (<1year ago) change, because it used to work in previous versions of Studio.

Just checked in a project and comment #12 is right, it waits for the target package (which is wrong) and not for the test package.

#13: yes, the whole "build execution" pipeline has been completely refactored over the past year...this is probably one of the bugs that has slipped through

Hey Polina, we're probably just passing in the wrong process to wait on from the Config Executors.

Hi!

I talked with test team about it in past, we need to make decision here: http://cs/h/googleplex-android/platform/superproject/base/+/studio-main:tools/adt/idea/android/src/com/android/tools/idea/testartifacts/instrumented/AndroidTestRunConfigurationExecutorBase.kt?l=74

I provided in this class both package and testPackage values, but I don't know how do we decide with one to choose in which case

@pa...@google.com could you look into this ?

Yuki, can you take a look while Paige is OOO this week?

We cannot use package name here as a debug target process name can be different. AndroidModel has implemented a logic to determine the correct target process name for testing. I'll create a patch.

I created a patch for fixing this. It turned out self-instrumenting experimental flag has not been exposed to builder model so I needed to update the builder model. I'll clean up my patch and send it for review shortly.

My patch was merged on Oct 27. It will be included in the Canary 11 build.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Canary 12
• Android Gradle Plugin 8.3.0-alpha12

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

We just updated androidx to Iguana Beta 1 and the issue is still ongoing.

I'm attaching some screenshots.

Hi Marcello,

Screenshot doesn't give us much information to investigate the cause. It looks like the test was executed in non-debugging run to me, and it's likely to be caused by the separate root cause. Could you open a new bug and attach all other logs?

I created b/319878943 adding logs as well. Thanks.

I fixed the issue with self-instrumenting confusing the target debuggee process name in this bug. I renamed the issue title for clarify. Let's continue to discuss in b/319878943

A clarification: the conditions of b/319878943 are the same of this bug and both are self-instrumenting test modules.

In both cases:

• there is a test module
• the test module is self-instrumenting
• the tested variant is non-debuggable
• the issue is triggered when trying to debug an integration test of the test module

In this bug AS hangs "Waiting for process". In b/319878943 it doesn't start saying build type is non debuggable.

This is why I initially reopened. I'm ok in continuing the discussion in the other bug.