Open SomberNight opened 4 years ago
@akshayaurora any idea?
Right, that seems related, thanks. p4a currently bundles sdl 2.0.9, and that bug is fixed in 2.0.10 However, when they tried to upgrade sdl2 the last time, they had to revert :/
@ecdsa @SomberNight The patch is small https://hg.libsdl.org/SDL/rev/b5cd5e1e4440 I don't see why we can't just add this patch to p4a, instead of moving to sdl2 2.0.10 completely., I will check with inclement and try to get this patch integrated.
@ecdsa @SomberNight setting android.api=27 instead of 28 seems to bypass this issue. Without the need for the patch above. The patch itself does not work when using api=28. Further investigation needed.
If Electrum is not using anything specific to api 28 then I’d suggest using android.api = 27 for now.
@akshayaurora Google Play mandates a lower bound of targetSdkVersion
of 28 at the moment :/
Although, I can' t imagine targetSdkVersion
would matter here. If anything, it is probably compileSdkVersion
, don't you think?
I guess it might be possible to set compileSdkVersion
to 27 and targetSdkVersion
to 28.
(although p4a kinda fuzzes the distinction: https://github.com/kivy/python-for-android/blob/36825d7ffe91eebcd12992911ddf7b5a5d87ccd7/pythonforandroid/bootstraps/common/build/templates/build.tmpl.gradle#L32-L36)
I've just compiled two apks and apparently it is about the targetSdkVersion
and not the compileSdkVersion
. I find this extremely weird.
An apk with compileSdkVersion==27
and targetSdkVersion==28
has the bug but
an apk with compileSdkVersion==27
and targetSdkVersion==27
does not have the bug.
I think I have figured it out.
If it's related to targetSdkVersion
that means the Android OS does something differently for our app just because we signalled that we have tested for that sdk version.
Here are some potentially relevant changes re that: https://developer.android.com/about/versions/pie/android-9.0-changes-28#focus
Also see these SO questions:
https://stackoverflow.com/questions/58209728/adobe-air-back-button-event-not-working-with-android-api-28
https://stackoverflow.com/questions/52074298/requestfocus-for-edittext-not-working-on-devices-running-android-p-api-28
where the common theme is that they needed to call view.requestFocus();
on API >= 28
Then the next clue was
Workaround: if you pull down the statusbar it will start working again.
If the user pulls down and up the statusbar, Activity.onResume
will run, and hence this code:
https://github.com/spurious/SDL-mirror/blob/8a812a24270dc19824a666b3c9b7fdd8f8829891/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java#L1533-L1536
Note that requestFocus();
is called there.
So what we need is to call requestFocus();
on the main surface when the software keyboard disappears.
https://github.com/SomberNight/python-for-android/commit/c571db9d58ceb3e840bbd16f903459c183d64f1a
@SomberNight nice job!
Ok so that patch (https://github.com/SomberNight/python-for-android/commit/c571db9d58ceb3e840bbd16f903459c183d64f1a) does not fix everything... There are multiple ways to trigger the bug and not all involve the software keyboard.
I have been reproducing via method (1):
Thomas has a different method (2):
Method (2) does not trigger the bug reliably for me :/ but nevertheless the above patch only fixes method (1). EDIT: method (2) triggers every time for me after fresh app start.
for me (2) triggers it reliably. Actually, it is triggered by any popup window.
I can only trigger it with method (2) right after the application opens.
See also method (3):
The fact that method (3) reproduces the issue means that the application does not get focus when it opens, from which method (2) also follows.
just to be clear: in my case too, it happens only right after the application opens. when I said 'reliably', I meant that. so it seems we are looking at the same behavior.
note: I've tried https://github.com/SomberNight/python-for-android/commit/4f7bdf1bd2811b8a06a12f9d56bd5b18594caf60 for method (2) and (3) but it did not work (I have also tried scheduling a task again from there to get focus: did not help)
It probabilistically helped with method (3), but not with method (2) actually; I think after we transition from the wallet-select-dialog to a loaded wallet focus might be lost again for some reason.
I have another way to reproduce this, method (4):
I have another way to reproduce this, method (4):
- go to Receive tab, tap on "Description", popup appears. make the popup disappear by tapping the background (outside the popup). "back" button is now disfunctional again
I can replicate. Might be related to:
https://github.com/kivy/python-for-android/issues/2423 https://github.com/kivy/kivy/issues/6686 https://github.com/kivy/kivy/issues/7374
On Android, the back button ('<') sometimes stops working. This might be a bug with kivy / python-for-android (or even further upstream); or perhaps we are misusing some API that causes this.
Workaround: if you pull down the statusbar it will start working again.