Android 12 ~ Red Moon doesn't allow proper screen interaction on homescreen.

[Rufusdotrufus]

Red Moon Version: v3.5.0 Android version: 12 Device Pixel: Both 3 & 4 on Graphene OS & a Pixel 3 on a standard Android OS

Expected behavior: App functions normally. At set time, Red Moon starts and provides red screen settings based upon my choosing. I am able to interact with apps that are overdrawn, ex. scrolling, touch buttons and typing.

Actual behavior: With the rollout of Android 12, App turns on at set time as expected EXCEPT I cannot touch anywhere on home screen to pull up drawer, click on apps to open or swipe to other screens. I can swipe down and interact with turning off the Red Moon overdrawing other apps function.

Steps to reproduce: Upgrade to Android 12. Turn on Red Moon. Allow app to overdraw other apps. Try to interact with homescreen.

This happens on all 3 of my phones.

[gadgetguy08]

Seeing same behavior on Android 12.

Did see this warning in the log: type=1400 audit(0.0:27180): avc: denied { lock } for path="/apex/com.android.art/javalib/arm64/boot-bouncycastle.art" dev="dm-12" ino=141 scontext=u:r:untrusted_app_29:s0:c166,c256,c512,c768 tcontext=u:object_r:system_file:s0 tclass=file permissive=0 app=com.jmstudios.redmoon

and this note about bouncy castle and Android 12. Not sure if it applies or not:

https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle

[smichel17]

In general, there's many issues on modern Android that are not addressed, because my phone is still running 7.0.

This particular issue looks like it's related to this section: https://developer.android.com/about/versions/12/behavior-changes-all#untrusted-touch-events

Look for the log message, Untrusted touch due to occlusion by PACKAGE_NAME

It seems like the only way around this would be to mark the app as an accessibility overlay. Honestly this is probably a better fit than TYPE_APPLICATION_OVERLAY, anyway.

I'd welcome a PR adapting Red Moon to be an accessibility service. This might also enable us to drop other workarounds, make it less likely that Red Moon will be killed due to running out of memory, etc.

[hamishmb]

The accessibility overlay thing would probably also fix the issues with the lock screen and notification bar not being filtered.

Is this easy to implement? If so, I might give it a go when I have some time, as I'm new to developing anything for Android.

[smichel17]

Yes, I think this would also fix https://github.com/LibreShift/red-moon/issues/312, https://github.com/LibreShift/red-moon/issues/253, and probably a couple other issues floating around with the api26+ tag.

For ease of implementation—

• Switching from TYPE_APPLICATION_OVERLAY to TYPE_ACCESSIBILITY_OVERLAY is a simple find-and-replace.
• I'm not 100% sure what's involved in otherwise declaring Red Moon as an accessibility service. Some research needed here.
  • The main open question is whether it just needs some tweaks to the AndroidManifest.xml and Overlay.kt, or whether the FilterService also needs to be updated and (if so) whether accessibility services follow the same lifecycle as regular services.
• There may be some additional UI work needed. If accessibility service permission replaces the overlay permission, then it's minimal enough, but if the user needs to grant both, then we might want to update how the prompt works a little bit. Although, I would merge a less-than-perfect UX in this case — better than not working at all!

[hamishmb]

Okay, seeing as you're interested and have given me some pointers, I will see if I can find some time soonish to have a look at least and report back.

[IMPranshu]

Anyone working on this bug??? I am looking to start with this any tips will be very much helpful.

[smichel17]

I am looking to start with this any tips will be very much helpful.

I'm not sure what else you'd like to know besides the information I already shared. A good place to start would be researching what's needed for Red Moon to mark itself as an accessibility service.

[mateMathieu]

+1

[wombalton]

My Samsung s10se just got an update to Android 12. Now not any touch input is recognised on the screen area wich red moon overdraws. Luckily this is not the status and notification bar, so I'm able to turn redmoon of again ... I think this is related to the issues mentioned here.

I hope you guys find a fix quickly. At the moment red moon is unusable for me. Im sorry but I cannot code to help.

[Yachont]

I found a solution to this for Android 12 users:

Using adb, type the following command: adb shell settings put global block_untrusted_touches 0

---

This is documented here: https://developer.android.com/about/versions/12/behavior-changes-all#untrusted-touch-events

If you need to setup ADB (Android Debug Bridge), here's a guide: https://www.xda-developers.com/install-adb-windows-macos-linux/

[AdamNiederer]

I have a minimal PoC for this that enables the overlay as soon as the Accessibility Service is enabled, but I have no idea how to add the overlay view outside of the "privileged" context you get when enabling it. This passes all touches through, and draws over the notification shade, status/nav bars, and homescreen.

class OverlayAccessibilityService : AccessibilityService() {
    override fun onInterrupt() {}
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {}
    override fun onServiceConnected() {
        val layout = (getSystemService(LAYOUT_INFLATER_SERVICE) as LayoutInflater).inflate(R.layout.overlay_layout, null)
        val lp = WindowManager.LayoutParams().apply {
            type = WindowManager.LayoutParams.TYPE_ACCESSIBILITY_OVERLAY
            format = PixelFormat.TRANSLUCENT
            flags = WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE.or(WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE)
        }
        (getSystemService(WINDOW_SERVICE) as WindowManager).addView(layout, lp)
    }
}

        <service
            android:name=".OverlayAccessibilityService"
            android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"
            android:label="@string/overlay_accessibility_service_label"
            android:exported="true">
            <intent-filter>
                <action android:name="android.accessibilityservice.AccessibilityService" />
            </intent-filter>
        </service>

The overlay layout can be literally any fullscreen layout with a translucent background.

I've tried making FilterService a subclass of AccessibilityService (they're all services, right?), but that won't let me set it. It seems like it has to be in one of the AccessibilityService-specific methods.

[hamishmb]

I'm not sure I understand what the problem is with that patch actually? Presumably the overlay doesn't need to be edited outside of the privileged context?

[AdamNiederer]

I'm not sure I understand what the problem is with that patch actually? Presumably the overlay doesn't need to be edited outside of the privileged context?

That patch will enable the filter when you enable the accessibility service in your phone's settings, so to turn it off you'd have to go back into your settings and turn off the accessibility service. No timing it or turning it off/on from the app's activity or notification.

[hamishmb]

Ah, I see.

[AdamNiederer]

I believe I've figured it out: We can add a transparent overlay upon enabling the AccessibilityService, and then manipulate its color/transparency by sending events over an EventBus to the AccessibilityService as needed. Only thing left is to get it working with the app monitor and notification, and make the UX not terrible.

Partially completed code can be tracked here https://github.com/AdamNiederer/red-moon/tree/accessibility-overlay

[hamishmb]

Awesome :)