Android Question API 36 Problem - Activity_Keypress event does not fire.

[RichardN]

I have a simple legacy calculator app (pre-B4X pages) that is sold the Play store. Google tell me that it needs to be updated to API36 before the end of August. It all seems to work aside from one glaring problem.... The Activity_Keypress event does not fire at all. The code is simple:

Sub Activity_KeyPress (KeyCode As Int) As Boolean     'Return True to consume the event
   
    Log("Some key is pressed...")
   
    If KeyCode = KeyCodes.KEYCODE_BACK Then
   
        If pnlResults.Visible = True Then
            pnlResults.Visible = False
            Return True
        End If
   
    End If
   
    Return False
           
End Sub

This all works fine with TargetSDK 35 compiling under that Javac but switching to Javac/SDK 36 the problem is immediately obvious. The log reports no activity from that Sub and the program exits as if the keystroke has not been handled. Any ideas?

 

[DonManfred]

You should NOT USE target sdk 36 until we got a B4A Version which is build for this SDK. The recommendet targetSDK ist still 35
Erel is working on it.

 

[RichardN]

Perhaps a bit of customer feedback might actually be useful to @Erel ..... Just a thought!

 

[Scantech]

Perhaps a bit of customer feedback might actually be useful to @Erel ..... Just a thought!

I confirm this too. I tested it last year on emulator and i thought it was emulator issue. But today, i tested on samsung 24FE API 36 + Manifest and spotted the same issue.

 

[Scantech]

Its my first time using Claude. Been using Gemini and chatgpt. Claude said put this in your manifest. It works! Temp Workaround until Erel resolves. it.

SetApplicationAttribute(android:enableOnBackInvokedCallback, "false")

Straight answer: as of that thread (posted within the last day), there's no confirmed fix yet — the B4A team's only advice so far is "don't target 36 until B4A ships SDK 36 support," and a third user just confirmed the same bug on a real Samsung device (not just the emulator). So nobody's posted a working code-level workaround publicly yet.


That said, here's the likely root cause and a workaround worth trying, since it fits the symptom pattern:


Likely cause: Android made predictive back gesture mandatory-enabled for apps targeting API 36 (it was opt-in before). This replaces the old KeyEvent.KEYCODE_BACK dispatch mechanism with a new OnBackInvokedCallback/OnBackInvokedDispatcher API at the OS level — the back "key press" often never reaches dispatchKeyEvent/Activity_KeyPress anymore because the system intercepts it earlier as a gesture callback instead of a key event. This would explain why it specifically breaks on 36 and specifically breaks the back key.


Workaround to try — opt out of predictive back in the manifest:



SetApplicationAttribute(android:enableOnBackInvokedCallback, "false")

Add this as an application attribute in your Manifest editor. This tells Android to keep using the legacy key-event-based back handling instead of the new callback dispatcher, even while targeting API 36. This is Google's own documented escape hatch for apps not yet migrated, and it doesn't require lowering targetSdkVersion.


If that doesn't fully fix it (some report the opt-out itself gets ignored on newer OS versions per one user's experience that opting out of edge-to-edge enforcement didn't work when target sdk was 36), the more involved workaround is bypassing Activity_KeyPress entirely and hooking dispatchKeyEvent directly via a JavaObject/inline Java, or registering an OnBackInvokedCallback manually through reflection — but that's a real workaround, not a quick fix, and I don't have a tested B4A code snippet for it I can vouch for. B4X


Given this is actively being tracked by Erel and is only ~1 day old as a reported issue on 36, I'd suggest posting your case in that same thread (or the RichardN one) — if the manifest opt-out above doesn't work for you, you'll likely get the real fix fastest straight from Erel once he responds.