IssueTracker

Thanks! Over to Nader to take a detailed look!

I believe we should dup b/187839528 and this ticket, what do you think Nader?

Yes definitely. Thanks Siyamed!

In the meantime there maybe other ways to work around it. The main issue is that surface implicitly creates a seaprate layer which impacts the behavior of the blending modes. Being ale to just set the Brush on the paint directly would work around this in the most straightforward way.

The issue is that the content depends on transparent pixels existing in the scene before the gradient is applied.

To address this you can do the following in order to force rasterization of the graphicsLayer into a separate buffer using CompositingStrategy.Offscreen, then only draw the gradient on top of the pixels rendered by the text Composable.

       Text("Hello World!", modifier =
        // Use offscreen compositing strategy so that there are transparent pixels in the offscreen buffer
        // to blend against with the SrcIn blend mode
            Modifier.graphicsLayer(compositingStrategy = CompositingStrategy.Offscreen).drawWithCache {
                val brush = Brush.horizontalGradient(listOf(Color.Red, Color.Blue, Color.Cyan, Color.Magenta, Color.Green))
                onDrawWithContent {
                    drawContent()
                    drawRect(brush, blendMode = BlendMode.SrcIn)
                }
            }
        )

Correction: I can repro consistently if I make sure to launch the app from the work profile, instead of the one from the user.

notes: the issue is that the agent ATTACHED event is never sent by the transport. I am still not sure why this is the case.

The issue is arising from the fact that the current user is 0 (obtained running adb shell am get-current-user), which is the base user (in a case where the device has both regular and work profile), but the app belongs to user 10, which is the work profile user. Even though user 0 can launch the app, it does not have permission to execute files from an app belonging to user 10. I think for this reason the command used to launch the agent is not working.

The command executed by the transport is:

cmd activity attach-agent com.google.samples.apps.sunflower /data/user/0/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so=/data/local/tmp/perfd/agent.config

This tries to connect to the app belonging to user 0. Since the open app is the one belonging to user 10, the connection never completes.

I have tried to manually force connecting to the app belonging to user 10 with:

cmd activity attach-agent com.google.samples.apps.sunflower /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so=/data/local/tmp/perfd/agent.config

In this case I have faced the restrictions mentioned at the beginning of this comment, which prevent the agent from attaching.

I think we should:

1. enhance App Inspection to be able to differentiate between the same package belonging to different users.
2. enhance foreground process detection in the same way.

After this we should be able to avoid the confusion of connecting to the wrong app.

We should also figure out why the transport does not show any error when it fails to launch the agent on the user 10 app form user 0.

RE: "We should also figure out why the transport does not show any error when it fails to launch the agent on the user 10 app form user 0."
Maybe when you forced attaching agent to the user 10 app, the agent is attached successfully but the following connection logic failed?

Transport Pipeline supports secondary user (https://cs.android.com/android-studio/platform/tools/base/+/a4c97db784418341c9f1be60b98ba22301b5ced8), which can also be illustrated by adb shell am get-current-user. I wonder if it helps to make Line 249 here more flexible.

string user = ActivityManager::Instance()->GetCurrentUser();

it fails to launch the agent on the user 10 app form user 0

I think it fails because the attach-agent command is executed from user 0, but the files passed as argument are stored in the code_cache folder of the user 10 app. So user 0 lacks the permission to access them.

I have checked if there are ways to specify which user is running attach-agent, but it looks like it does not support the --user flag.

What do you mean with making Line 249 more flexible? That line is running am get-current-user, which returns 0.

RE: "So user 0 lacks the permission to access them."
Do you have a logcat error or some other data points to support this? It's very possible that you are correct, but I'm hoping there's more context. For some reason my impression is that the am command sends the path to the agent file, but it's the app process who reads it.

RE: Line 249.
I meant to make it pointing to the "user" of the running app. Right now, am get-current-user is returning the "user" of the phone/environment. I think for experimentation, we can try passing a hard coded "10".

This is all the logcat evidence I could find.

2024-09-02 17:40:57.960 18953-18964 studio.transport        transport                            D  Running 'cmd activity attach-agent com.google.samples.apps.sunflower /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so=/data/local/tmp/perfd/agent.config'
2024-09-02 17:40:58.016 18632-18632 .apps.sunflower         com.google.samples.apps.sunflower    W  Agent attach failed (result=1) : Unable to dlopen /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so: dlopen failed: library "/data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so" not found
2024-09-02 17:40:58.017 18632-18632 ActivityThread          com.google.samples.apps.sunflower    E  Attaching agent with dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/~~09UvVeVtpVbMdcAitVVW6g==/com.google.samples.apps.sunflower-SLGAPrDsO5IoAC9fveE-bQ==/base.apk"],nativeLibraryDirectories=[/data/app/~~09UvVeVtpVbMdcAitVVW6g==/com.google.samples.apps.sunflower-SLGAPrDsO5IoAC9fveE-bQ==/lib/arm64, /system/lib64, /system_ext/lib64]]] failed: /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so=/data/local/tmp/perfd/agent.config
2024-09-02 17:40:58.020 18632-18632 .apps.sunflower         com.google.samples.apps.sunflower    W  Agent attach failed (result=1) : Unable to dlopen /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so: dlopen failed: library "/data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so" not found
2024-09-02 17:40:58.020 18632-18632 ActivityThread          com.google.samples.apps.sunflower    E  Attaching agent with null failed: /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so=/data/local/tmp/perfd/agent.config
2024-09-02 17:40:58.027 19080-19080 studio.transport        transport                            V  Running connector for app com.google.samples.apps.sunflower with pid 18811, user 10
2024-09-02 17:40:58.049 19080-19080 run-as                  transport                            W  type=1400 audit(0.0:59866): avc:  granted  { execute } for  name="transport" dev="dm-69" ino=531551 scontext=u:r:runas_app:s0:c229,c259,c522,c768 tcontext=u:object_r:app_data_file:s0:c229,c259,c522,c768 tclass=file
2024-09-02 17:40:58.053 19080-19080 transport               transport                            W  type=1400 audit(0.0:59867): avc:  granted  { execute } for  path="/data/user/10/com.google.samples.apps.sunflower/code_cache/transport" dev="dm-69" ino=531551 scontext=u:r:runas_app:s0:c229,c259,c522,c768 tcontext=u:object_r:app_data_file:s0:c229,c259,c522,c768 tclass=file

This is from my device, libjvmtiagent_arm64.so exists in that folder.

adb shell
cheetah:/ $ run-as com.google.samples.apps.sunflower --user 10
cheetah:/data/user/10/com.google.samples.apps.sunflower $ cd code_cache/
cheetah:/data/user/10/com.google.samples.apps.sunflower/code_cache $ ls
libjvmtiagent_arm64.so  perfa.jar  transport

I agree that the conclusion that it's not working because user 0 lacks permission to access files from the app belonging to user 10 requires more proof. I will ask folks from the framework after the US holiday.

Pier, thanks for the logcat evidence. Those dlopen error messages came from the app process (PID 18632), which makes me think it was the user 10 reading the .so file.

What's the output if you run the following commands?

run-as com.google.samples.apps.sunflower --user 10
ls -l /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so
xxd -l 20 /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so

Sure. They both look ok to me.

ls -l /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so

-rwxr-xr-x 1 u10_a997 u10_a997_cache 10893952 2024-09-03 16:58 /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so


xxd -l 20 /data/user/10/com.google.samples.apps.sunflower/code_cache/libjvmtiagent_arm64.so

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0300 b700                                ....