China's new regulations prohibit automatic acquisition of user clipboard

[yuanyunhua]

China's new regulation prohibits access to user information until the user agrees to the privacy policy: clipboard.
Thetrue</disabling SensorAccess>has already been added to the XML, but it will still fail the audit. May I ask if it is possible to cancel the automatic acquisition of ClipboardManager by AIRSDK.

[pengyangjin]

We also encountered the same problem and was rejected for review by Huawei App Store.

[ajwfrost]

Hi

We appear to be using the clipboard manager in two places:

1. If there is a context menu created (presumably upon right-click / long-press) - within the onCreateContextMenu method and the event handlers for this (see https://developer.android.com/reference/android/view/View.OnCreateContextMenuListener)
2. When an AS3 Clipboard object is created (see https://airsdk.dev/reference/actionscript/3.0/flash/desktop/Clipboard.html)

When we run up a normal application, we're not hitting either of those calls. When I then long-press on a text field, then it does hit the clipboard manager breakpoint.

So .. we don't appear to be automatically accessing the ClipboardManager, this seems to always be on-demand. Unless your applications are trying to access an AS3 clipboard object at start-up, it should be possible to have an application running without ever ending up requesting this service.

Do you know why they think it's being accessed automatically? Are there any guidelines for how/when to configure the app to ensure they don't think this is happening?

thanks

[pengyangjin]

May I ask if we can disable this feature? This feature is not necessary for us.We don't want to get into this predicament because the government has strengthened restrictions in this area. We choose to go around.

[ajwfrost]

We could disable it but that wouldn't change the behaviour or instances of this in the code. It would just prevent it from being called ... but at the moment, it shouldn't be called, unless your application is trying to access it...?

As an interim measure, I'll upload a version of the runtime classes here that disables this by default (and without a way to then enable it); then we can put in an app descriptor switch in 51.2 to allow this to be controlled from there.

thanks

[ajwfrost]

@pengyangjin please try with the attached zip, which contains an updated runtimeClasses.jar file, that you can use on a 51.1.2.1 version of AIR SDK - you would need to put this into the lib/android/lib folder.

thanks
runtimeClasses.zip

[pengyangjin]

ok i will try,tks.

…

---Original--- From: "Andrew ***@***.***&gt; Date: Wed, Nov 6, 2024 18:59 PM To: ***@***.***&gt;; Cc: ***@***.******@***.***&gt;; Subject: Re: [airsdk/Adobe-Runtime-Support] China's new regulations prohibitautomatic acquisition of user clipboard (Issue #3558) @pengyangjin please try with the attached zip, which contains an updated runtimeClasses.jar file, that you can use on a 51.1.2.1 version of AIR SDK - you would need to put this into the lib/android/lib folder. thanks runtimeClasses.zip — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

[pengyangjin]

use 51.1.2.1 win version get an error , I have 30.0.3 in android sdk build-tools folder , but why need 30.0.3-2 ? Did something go wrong?

[java] unexpected failure: Unable to run java: com.adobe.air.ADTException: gradle tool failed: NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
[java]
[java] FAILURE: Build failed with an exception.
[java]
[java] * Where:
[java] Build file 'C:\Users\YTTX-DBJ1\AppData\Local\Temp\9a09b8c7-2b81-4160-875b-12067d99600d\app\build.gradle' line: 13
[java]
[java] * What went wrong:
[java] A problem occurred evaluating project ':app'.
[java] > Invalid revision: 30.0.3-2
[java]
[java] * Try:
[java] > Run with --stacktrace option to get the stack trace.
[java] > Run with --info or --debug option to get more log output.
[java] > Run with --scan to get full insights.
[java]
[java] * Get more help at https://help.gradle.org/
[java]
[java] BUILD FAILED in 24s
[java]
[java] java.io.IOException: Unable to run java: com.adobe.air.ADTException: gradle tool failed: NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
[java]
[java] FAILURE: Build failed with an exception.
[java]
[java] * Where:
[java] Build file 'C:\Users\YTTX-DBJ1\AppData\Local\Temp\9a09b8c7-2b81-4160-875b-12067d99600d\app\build.gradle' line: 13
[java]
[java] * What went wrong:
[java] A problem occurred evaluating project ':app'.
[java] > Invalid revision: 30.0.3-2
[java]
[java] * Try:
[java] > Run with --stacktrace option to get the stack trace.
[java] > Run with --info or --debug option to get more log output.
[java] > Run with --scan to get full insights.
[java]
[java] * Get more help at https://help.gradle.org/
[java]
[java] BUILD FAILED in 24s
[java]
[java] at com.adobe.air.apk.AABOutputStream.buildGradle(AABOutputStream.java)
[java] at com.adobe.air.apk.AABPackager.renameOutput(AABPackager.java)
[java] at com.adobe.air.ApplicationPackager.createPackage(ApplicationPackager.java)
[java] at com.adobe.air.apk.AABPackager.createPackage(AABPackager.java)
[java] at com.adobe.air.ADT.parseArgsAndGo(ADT.java)
[java] at com.adobe.air.ADT.run(ADT.java)
[java] at com.adobe.air.ADT.main(ADT.java)

[ajwfrost]

Hi
In your build tools, 30.0.3 folder, can you check in the source.properties file and see what this says? I just downloaded it and mine says:

Pkg.UserSrc=false
Pkg.Revision=30.0.3
#Pkg.Revision=30.0.0 rc4

but I suspect if it has 30.0.3-2 there, it would cause this problem... you could probably edit the file directly, or maybe remove/re-add this via the Android SDK Manager?

thanks

[yuanyunhua]

@pengyangjin please try with the attached zip, which contains an updated runtimeClasses.jar file, that you can use on a 51.1.2.1 version of AIR SDK - you would need to put this into the lib/android/lib folder.

thanks runtimeClasses.zip

After adding the file you sent and publishing it, it still hasn't passed the review. It seems that you haven't disabled the clipboard function, but I tested and found that it can still copy and paste.

[pengyangjin]

@pengyangjin please try with the attached zip, which contains an updated runtimeClasses.jar file, that you can use on a 51.1.2.1 version of AIR SDK - you would need to put this into the lib/android/lib folder.

thanks runtimeClasses.zip

Can this attached zip file be used in version 50.2.3.4? The apk file compiled by the SDK 51.1.2.1 window ver. encountered a startup crash exception, which I will explain in detail in another bug

[yuanyunhua]

@pengyangjin please try with the attached zip, which contains an updated runtimeClasses.jar file, that you can use on a 51.1.2.1 version of AIR SDK - you would need to put this into the lib/android/lib folder.
thanks runtimeClasses.zip

Can this attached zip file be used in version 50.2.3.4? The apk file compiled by the SDK 51.1.2.1 window ver. encountered a startup crash exception, which I will explain in detail in another bug

I successfully packaged it with ADK, but when I tried to upload it again, I still received the same issue and was unable to pass the review.

[pengyangjin]

The stack call information obtained from the Huawei review team.

应用获取用户信息：剪切板 （Application obtains user information: clipboard）

com.adobe.air.Entrypoints.EntryMainWrapper(Native Method),

com.adobe.air.Entrypoints.EntryMain(Entrypoints.java:240),

com.adobe.air.AndroidActivityWrapper.LaunchApplication(AndroidActivityWrapper.java:1281),

com.adobe.air.AndroidActivityWrapper.launchApplication(AndroidActivityWrapper.java:1581),

com.adobe.air.AndroidActivityWrapper.onSurfaceInitialized(AndroidActivityWrapper.java:1567),

com.adobe.air.AIRWindowSurfaceView.surfaceChanged(AIRWindowSurfaceView.java:816),

android.view.SurfaceView.updateSurface(SurfaceView.java:1238),

android.view.SurfaceView.lambda$new$0$SurfaceView(SurfaceView.java:192),

android.view.-$$Lambda$SurfaceView$w68OV7dB_zKVNsA-r0IrAUtyWas.onPreDraw(Unknown Source:2),

android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1103),

android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3752),

android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2406),

android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9465),

android.view.Choreographer$CallbackRecord.run(Choreographer.java:1286),

android.view.Choreographer.doCallbacks(Choreographer.java:1025),

android.view.Choreographer.doFrame(Choreographer.java:917),

android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1254),

android.os.Handler.handleCallback(Handler.java:955),

android.os.Handler.dispatchMessage(Handler.java:102),

android.os.Looper.loop(Looper.java:228),

android.app.ActivityThread.main(ActivityThread.java:9016),

java.lang.reflect.Method.invoke(Native Method),

com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:614),

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1129)

[pengyangjin]

According to the new audit rules, it is not allowed to call directly in this way.It can only be called after user permission.The currently stable solution is to completely disable this type of call.

[yuanyunhua]

The logs provided by my software feedback are as follows:

com.adobe.air.Entrypoints.EntryMainWrapper(Native Method),
com.adobe.air.Entrypoints.EntryMain(Entrypoints.java:267),
com.adobe.air.AndroidActivityWrapper.LaunchApplication(AndroidActivityWrapper.java:1301),
com.adobe.air.AndroidActivityWrapper.launchApplication(AndroidActivityWrapper.java:1643),
com.adobe.air.AndroidActivityWrapper.onSurfaceInitialized(AndroidActivityWrapper.java:1607),
com.adobe.air.AIRWindowSurfaceView.surfaceChanged(AIRWindowSurfaceView.java:845),
android.view.SurfaceView.updateSurface(SurfaceView.java:1238),
android.view.SurfaceView.lambda$new$0$SurfaceView(SurfaceView.java:192),
android.view.-$$Lambda$SurfaceView$w68OV7dB_zKVNsA-r0IrAUtyWas.onPreDraw(Unknown Source:2),
android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1103),
android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3752),
android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2406),
android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9465),
android.view.Choreographer$CallbackRecord.run(Choreographer.java:1286),
android.view.Choreographer.doCallbacks(Choreographer.java:1025),
android.view.Choreographer.doFrame(Choreographer.java:917),
android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1254),
android.os.Handler.handleCallback(Handler.java:955),
android.os.Handler.dispatchMessage(Handler.java:102),
android.os.Looper.loop(Looper.java:228),
android.app.ActivityThread.main(ActivityThread.java:9016),
java.lang.reflect.Method.invoke(Native Method),
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:614),
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1129)

[ajwfrost]

Thanks - although we should have disabled the call to get the Android clipboard service, so I'm not sure how this is still happening. The call stack just shows us going into native code so I'll double-check in case there's some NDK clipboard usage, but when we checked the code earlier, it looked like the native (C++) code called back into Java to get at this feature...

Do you know what API call they're actually concerned about there?

thanks

[yuanyunhua]

Thanks - although we should have disabled the call to get the Android clipboard service, so I'm not sure how this is still happening. The call stack just shows us going into native code so I'll double-check in case there's some NDK clipboard usage, but when we checked the code earlier, it looked like the native (C++) code called back into Java to get at this feature...

Do you know what API call they're actually concerned about there?

thanks

When I inquired about the specific API of the platform, the customer service replied, 'Let's locate ourselves based on the stack information.'.

[pengyangjin]

Thanks - although we should have disabled the call to get the Android clipboard service, so I'm not sure how this is still happening. The call stack just shows us going into native code so I'll double-check in case there's some NDK clipboard usage, but when we checked the code earlier, it looked like the native (C++) code called back into Java to get at this feature...
Do you know what API call they're actually concerned about there?
thanks

When I inquired about the specific API of the platform, the customer service replied, 'Let's locate it in the code based on the stack information.'.

Yes, I also received the same response.Is there a temporary solution?

[ajwfrost]

Hi

Thanks .. searching in the codebase, for ClipboardManager, this only happens in the Java code - our C++ glue code from ActionScript is calling through JNI into a Java class, which is in that jar file. So maybe I had missed something when providing the above version.. I've just re-built, and then did a test here:

1. Before the change - I can get an AS3 Clipboard object, and can copy and paste text using it.
2. After the change - I can still get an AS3 Clipboard object, but the copy/paste requests fail silently.

I think doing this properly, we should probably throw an error or similar, or return null when trying to access the general clipboard. And we can also add this to the permission manager mechanism if that would be an appropriate way to do the user permissions.

Are you able to try with the below one? Given there's a call stack, even though it's not actually complete, I am hoping that this means they're monitoring the application call into the below, which is what we are no longer actually calling:

(ClipboardManager)getContext().getSystemService(Context.CLIPBOARD_SERVICE);

thanks

runtimeClasses.zip

[pengyangjin]

Hi

Thanks .. searching in the codebase, for ClipboardManager, this only happens in the Java code - our C++ glue code from ActionScript is calling through JNI into a Java class, which is in that jar file. So maybe I had missed something when providing the above version.. I've just re-built, and then did a test here:

1. Before the change - I can get an AS3 Clipboard object, and can copy and paste text using it.
2. After the change - I can still get an AS3 Clipboard object, but the copy/paste requests fail silently.

I think doing this properly, we should probably throw an error or similar, or return null when trying to access the general clipboard. And we can also add this to the permission manager mechanism if that would be an appropriate way to do the user permissions.

Are you able to try with the below one? Given there's a call stack, even though it's not actually complete, I am hoping that this means they're monitoring the application call into the below, which is what we are no longer actually calling:

(ClipboardManager)getContext().getSystemService(Context.CLIPBOARD_SERVICE);

thanks

runtimeClasses.zip

Can you provide a runtimeClasses.zip used at 50.2.3.4 window version. the 51.1.2.1 version has a fashback bug which have been reported.

[ajwfrost]

Can you provide a runtimeClasses.zip used at 50.2.3.4 window version

Attached below, thanks
runtimeClasses_50.2.zip

[pengyangjin]

thinks.

…

---Original--- From: "Andrew ***@***.***&gt; Date: Fri, Nov 8, 2024 19:37 PM To: ***@***.***&gt;; Cc: ***@***.******@***.***&gt;; Subject: Re: [airsdk/Adobe-Runtime-Support] China's new regulations prohibitautomatic acquisition of user clipboard (Issue #3558) Can you provide a runtimeClasses.zip used at 50.2.3.4 window version Attached below, thanks runtimeClasses_50.2.zip — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

[pengyangjin]

There are still issues with using the provided solution。The attachment is a log。Is the access clipboard feature enabled by default? Do I need to set it off?
Startup_universal__613275b4d36f42d9be0d1262430cc605.zip

[ajwfrost]

What are the issues? Clipboard access is disabled in that version. I had a quick look at one of the logcat files, couldn't see any warnings/errors around clipboard access? What are you seeing that looks like it's wrong? -> or do you have any information about what's actually required here, e.g. are specific APIs forbidden to be called until user permission is granted? and if so, what APIs?

thanks

[yuanyunhua]

What are the issues? Clipboard access is disabled in that version. I had a quick look at one of the logcat files, couldn't see any warnings/errors around clipboard access? What are you seeing that looks like it's wrong? -> or do you have any information about what's actually required here, e.g. are specific APIs forbidden to be called until user permission is granted? and if so, what APIs?

thanks

The information found online to obtain clipboard permissions is:
ohos.permission.READ_PASTEBOARD
//Example code, specific implementation may vary due to different API versions
if (ContextCompat.checkSelfPermission(context, Manifest.permission.READ_PASTEBOARD) != PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(activity, new String[]{Manifest.permission.READ_PASTEBOARD}, REQUEST_CODE);
} else {
//The user has been authorized to directly access the clipboard
ClipData clipData = ClipboardManager.getDefault().getPrimaryClip();
//Processing clipboard data
}
I called EncryptedLocalStore during software runtime, and I'm not sure if this API has any impact. Currently, all of our AIR developed software requires rectification, and I hope to find the problem as soon as possible.

[pengyangjin]

The keyword ShareCodeClipboardHelper has found in the log file.Many detection systems are based on keyword matching.This detection system is like a black box.

[yuanyunhua]

ajwfrost 给的“runtimeClasses.jar”文件，你试过打包上传没有？

[pengyangjin]

Yes, it was used, and it was rejected.

…

---Original--- From: ***@***.***&gt; Date: Mon, Nov 11, 2024 11:41 AM To: ***@***.***&gt;; Cc: ***@***.******@***.***&gt;; Subject: Re: [airsdk/Adobe-Runtime-Support] China's new regulations prohibitautomatic acquisition of user clipboard (Issue #3558) ajwfrost 给的“runtimeClasses.jar”文件，你试过打包上传没有？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

[ajwfrost]

Curious - as I don't quite see how that log implies it's anything to do with AIR, but it started us looking more deeply throughout the code. The main AS3 clipboard access happens via a Java utility class that's in that runtimeClasses.jar file, where we'd made the change to prevent it. And likewise the other UI-based cut/copy/paste functionality was similarly in runtimeClasses.jar and updated.

But a full search throughout the codebase shows another class that's written in C++ and that doesn't use our Java utility class, instead there's a direct call to Context.getSystemService(CLIPBOARD_SERVICE) happening from the C++. Not sure why there are two different mechanisms being used here, but this one is happening in a constructor within the global runtime initialisation...

So to fix this we'll need to rebuild all the native code across the different platforms -> @pengyangjin presumably you would need that built on top of 50.2.3.4? @yuanyunhua are you okay with a build on top of 51.1.2.2?

thanks

[pengyangjin]

Curious - as I don't quite see how that log implies it's anything to do with AIR, but it started us looking more deeply throughout the code. The main AS3 clipboard access happens via a Java utility class that's in that runtimeClasses.jar file, where we'd made the change to prevent it. And likewise the other UI-based cut/copy/paste functionality was similarly in runtimeClasses.jar and updated.

But a full search throughout the codebase shows another class that's written in C++ and that doesn't use our Java utility class, instead there's a direct call to Context.getSystemService(CLIPBOARD_SERVICE) happening from the C++. Not sure why there are two different mechanisms being used here, but this one is happening in a constructor within the global runtime initialisation...

So to fix this we'll need to rebuild all the native code across the different platforms -> @pengyangjin presumably you would need that built on top of 50.2.3.4? @yuanyunhua are you okay with a build on top of 51.1.2.2?

thanks

The apk package packaged using 51.1.2.2 will crash, and I have already reported this issue. The current version that can be used normally is 50.2.3.4. So please provide the modifications for 50.2.3.4 version, thank you.

[yuanyunhua]

Curious - as I don't quite see how that log implies it's anything to do with AIR, but it started us looking more deeply throughout the code. The main AS3 clipboard access happens via a Java utility class that's in that runtimeClasses.jar file, where we'd made the change to prevent it. And likewise the other UI-based cut/copy/paste functionality was similarly in runtimeClasses.jar and updated.

But a full search throughout the codebase shows another class that's written in C++ and that doesn't use our Java utility class, instead there's a direct call to Context.getSystemService(CLIPBOARD_SERVICE) happening from the C++. Not sure why there are two different mechanisms being used here, but this one is happening in a constructor within the global runtime initialisation...

So to fix this we'll need to rebuild all the native code across the different platforms -> @pengyangjin presumably you would need that built on top of 50.2.3.4? @yuanyunhua are you okay with a build on top of 51.1.2.2?

thanks

I am currently using version 51.1.2.2, other versions are also acceptable. I have no version requirements for ADT packaging.

The developer platform has given us 7 days to rectify the situation, otherwise the application will be taken down. I think Chinese users have received similar rectification notices.

[ajwfrost]

Hi

Apologies for the delay - we had prepared the runtimes but I only just realised we'd not uploaded them here..
So with the zip files from in the below link, it contains all the runtime files needed to remove the clipboard capabilities, the zip should be extracted over the top of the existing AIR SDK.
https://transfer.harman.com/message/ApZ8bqFGZarABxXegKUtzr

Please let me know of any issues!

thanks