Fix IncorrectContextUse warning

[eloev]

When StrictMode is enabled, Android 11 or higher will display a warning if the app requests WindowManager on application contexts. When trying to send event

E/ContextImpl: Tried to access visual service WindowManager from a non-visual Context:com.myApp@82752ca 
Visual services, such as WindowManager, WallpaperService or LayoutInflater should be accessed from Activity
 or other visual Context. Use an Activity or a Context created with Context#createWindowContext(int, Bundle), 
which are adjusted to the configuration and visual bounds of an area on screen.
    java.lang.IllegalAccessException: Tried to access visual service WindowManager from a non-visual Context:com.myApp@82752ca
        at android.app.ContextImpl.getSystemService(ContextImpl.java:1926)
        at android.content.ContextWrapper.getSystemService(ContextWrapper.java:814)
        at com.adjust.sdk.sig.NativeLibHelper.nSign(Native Method)
        at com.adjust.sdk.sig.NativeLibHelper.sign(NativeLibHelper.java:15)
        at com.adjust.sdk.sig.SignerInstance.sign(SignerInstance.java:112)
        at com.adjust.sdk.sig.Signer.sign(Signer.java:74)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.adjust.sdk.Reflection.invokeMethod(Unknown Source:8)
        at com.adjust.sdk.Reflection.invokeInstanceMethod(Unknown Source:4)
        at com.adjust.sdk.AdjustSigner.sign(Unknown Source:46)
        at com.adjust.sdk.PackageBuilder.buildEventPackage(Unknown Source:36)

When tried to handle deeplink

E/ContextImpl: Tried to access visual service WindowManager from a non-visual Context:com.myApp@82752ca 
Visual services, such as WindowManager, WallpaperService or LayoutInflater should be accessed from Activity
 or other visual Context. Use an Activity or a Context created with Context#createWindowContext(int, Bundle), 
which are adjusted to the configuration and visual bounds of an area on screen.
    java.lang.IllegalAccessException: Tried to access visual service WindowManager from a non-visual Context:com.myApp@82752ca
        at android.app.ContextImpl.getSystemService(ContextImpl.java:1926)
        at android.content.ContextWrapper.getSystemService(ContextWrapper.java:814)
        at com.adjust.sdk.sig.NativeLibHelper.nSign(Native Method)
        at com.adjust.sdk.sig.NativeLibHelper.sign(NativeLibHelper.java:15)
        at com.adjust.sdk.sig.SignerInstance.sign(SignerInstance.java:112)
        at com.adjust.sdk.sig.Signer.sign(Signer.java:74)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.adjust.sdk.Reflection.invokeMethod(Unknown Source:8)
        at com.adjust.sdk.Reflection.invokeInstanceMethod(Unknown Source:4)
        at com.adjust.sdk.AdjustSigner.sign(Unknown Source:46)
        at com.adjust.sdk.PackageBuilder.buildClickPackage(Unknown Source:69)
        at com.adjust.sdk.PackageFactory.buildDeeplinkSdkClickPackage(Unknown Source:135)

Appcenter have the same bug in past, and this commit will help you https://github.com/facebook/facebook-android-sdk/commit/235a0a02692ac5a57d4c10b0bfb6477c9a003e99

[shashanksu]

Hi @eloev, Thanks for reporting this. To understand more on the issue, could you please confirm:

1. Which context being passed to the sdk during initialization? I understand it's application context, but just to confirm.
2. Which Adjust SDK and Signature SDK version are you noticing this issue with? Also, we aren't using WindowManager anywhere in our SDK, so the suggested fix (commit) doesn't appear to be relevant.

Please share the asked details, so that we can look into this issue further, thanks.

[eloev]

Hi,

1. Yes, application context.
2. Adjust SDK version 4.33.2, updated to 4.33.3, problem still exists Signature SDK version is 2.8.2 (in library name), in manifest android:versionCode="1", android:versionName="0.1.0". I contacted the manager for an update a week ago. I'll write here when I get the new Signature version and test it.

[shashanksu]

Thanks @eloev. Can you also quickly confirm if the issue happens with or without Signature SDK?

[eloev]

Issue happens only with Signature SDK. Without the Signature SDK everything is fine. After updating the version of the Signature SDK, I will write the results here

[dimim]

@eloev thank you for bringing this to our attention (and your help @shashanksu). As this is related to the Signature SDK, could you please contact Adjust's support so that we track it internally?

Closing this. Happy to clarify further as needed.

[eloev]

@dimim @shashansku Sorry for the long reply, update signature library not solved this. I will return to the problem in Q3, because it's non-critical task, but it looks very strange Adjust 4.33.3 Signature version adjust-android-signaturev2-v2.15.10-s6

[dimim]

@dimim @shashansku Sorry for the long reply, update signature library not solved this. I will return to the problem in Q3, because it's non-critical task, but it looks very strange Adjust 4.33.3 Signature version adjust-android-signaturev2-v2.15.10-s6

Thank you for coming back to us! The change is not yet deployed. As mentioned, as this not related to the SDK, we need to track it internally. Apologies if this was mentioned already: Upon Q3 coming/When you reach out to Support, please request the ticket to be linked to Signature V2's team and we can follow internally. 🙂 Thank you!

[eloev]

I partially solved this. My old StrictMode configuraton:

            StrictMode.setVmPolicy(
                StrictMode.VmPolicy.Builder()
                    .detectAll()
                    .penaltyLog()
                    .build()
            )

Need disable StrictMode.VmPolicy.Builder.detectIncorrectContextUse() Because func permitIncorrectContextUse() are hided, I wrote extension for StrictMode, which are copy of detectAll() without incorrectContextUse()

[kibotu]

Still persist in com.adjust.sdk:adjust-android:5.1.0 and happens on each app start.

I don't understand the solution for closing the issue. The error message points towards adjust trying to use application context in order to access window manager from background where the activity is either not ready yet or not available. Which can't work obviously.

ContextImpl             Tried to access visual service WindowManager from a non-visual Context:de.my.id.App@c5afd5f WindowManager should be accessed from Activity or other visual Context. Use an Activity or a Context created with Context#createWindowContext(int, Bundle), which are adjusted to the configuration and visual bounds of an area on screen.
                        java.lang.IllegalAccessException: Tried to access visual service WindowManager from a non-visual Context:de.my.id.App@c5afd5f
                        	at android.app.ContextImpl.getSystemService(ContextImpl.java:2278)
                        	at android.content.ContextWrapper.getSystemService(ContextWrapper.java:951)
                        	at com.adjust.sdk.sig.NativeLibHelper.nSign(Native Method)
                        	at com.adjust.sdk.sig.NativeLibHelper.a(SourceFile:2)
                        	at com.adjust.sdk.sig.d.a(SourceFile:10)
                        	at com.adjust.sdk.sig.Signer.sign(SourceFile:5)
                        	at java.lang.reflect.Method.invoke(Native Method)
                        	at com.adjust.sdk.Reflection.invokeMethod(SourceFile:6)
                        	at com.adjust.sdk.Reflection.invokeInstanceMethod(SourceFile:2)
                        	at com.adjust.sdk.AdjustSigner.sign(SourceFile:8)
                        	at com.adjust.sdk.network.ActivityPackageSender.signParameters(SourceFile:28)
                        	at com.adjust.sdk.network.ActivityPackageSender.sendActivityPackageSync(SourceFile:1)
                        	at com.adjust.sdk.network.ActivityPackageSender$1.run(SourceFile:2)
                        	at com.adjust.sdk.scheduler.SingleThreadCachedScheduler.tryExecuteRunnable(SourceFile:4)
                        	at com.adjust.sdk.scheduler.SingleThreadCachedScheduler.access$000(SourceFile:1)
                        	at com.adjust.sdk.scheduler.SingleThreadCachedScheduler$3.run(SourceFile:1)
                        	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:487)
                        	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
                        	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                        	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
                        	at java.lang.Thread.run(Thread.java:1012)

[dimim]

Hi @kibotu,

Thanks for reaching out.

I don't understand the solution for closing the issue.

There was no solution provided. The topic was explored, but with no immediate solutions avail.: We rely on the application context and this leads to this error popping up (by the OS) despite the functionality not being impacted, i.e. things execute as expected. One immediate solution is removing said logic, but as the functionality is not impacted and this appears only when StrictMode is enabled, said option wasn't chosen.

As for why the issue was closed: It's an old issue and topics of Signature (the immediate cause of the error) were handled internally -- Signature wasn't by default included in SDKV4. Even now that Signature is included through SDKV5, we state that topics of Signature are usually best handled internally.

How critical is this for you?

CC: @rscloura

[kibotu]

Thanks for the info. It's not critical at all. At this point it's just a slight inconvenience at most.

Curious, do you already use a themed context wrapper? Which is valid with application context afaik.

MutableContextWrapper to be exact.

Here is an article that uses it in order to do webview pooling with application context. (Look for the obtain method)

https://medium.com/microsoft-mobile-engineering/clean-android-webview-caching-9b871b3579f3

[dimim]

Hey @kibotu,

Thank you for coming back to me & the recommendation. I raised it internally, as Signature relies solely on what the SDK provides on this front. Given the task at hand, the direct-er options (removing the logic or not relying on the context for this) are preferred. We're not prio-ing this, as per its scope & low number of reports but I'll reopen the task to have it also tracked here.

Thanks!