kivy: On android, the event handler stops working when you click on a text field
- Python: 3.8.5
- OS: Android
- Kivy: 2.0.0
- Kivy installation method: pip
When you click on the input field, the event handler that is declared in the init method stops working, but if you open the control center after that, as shown in the video below, the handler starts working until you click on the text field again. This bug only occurs on android.
The bug is present on all architectures
from kivy.app import App
from kivy.uix.textinput import TextInput
from kivy.core.window import Window
class MainApp(App):
def __init__(self, **kwargs):
super(MainApp, self).__init__(**kwargs)
Window.bind(on_keyboard=self.events)
def build(self):
return TextInput(text="Hello, World")
def events(self, instance, keyboard, keycode, text, modifiers):
if keyboard in (1001, 27):
print('back')
return True
MainApp().run()
2-nd example
from kivy.app import App
from kivy.uix.button import Button
from kivy.lang.builder import Builder
from kivy.core.window import Window
KV = '''
Screen:
ScreenManager:
id: screen_manager
Screen:
name: 'home'
BoxLayout:
padding: 100
Button:
text: 'Open text input screen'
on_release: app.open_input_screen()
Screen:
name: 'input'
BoxLayout:
orientation: 'vertical'
padding: 50
spacing: 20
Button:
id: btn
text: 'Text input'
TextInput:
id: text_input
text: 'Text'
'''
class TestApp(App):
def build(self):
Window.bind(on_keyboard=self.events)
return Builder.load_string(KV)
def open_input_screen(self):
self.root.ids.screen_manager.current = 'input'
def events(self, instance, keyboard, keycode, text, modifiers):
if keyboard in (1001, 27): # back
if self.root.ids.text_input.text == 'Text':
self.root.ids.text_input.text = ')'
return True
if self.root.ids.screen_manager.current == 'input':
self.root.ids.screen_manager.current = 'home'
else:
quit()
return True
return False
TestApp().run()
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 47 (14 by maintainers)
I also think that there is a bug in the latest version of android 11
I have encountered this issue and it only occurs in
android version 10, and maybe9other version works perfectly.in my own case, I did not include the 1001 key, but I still got that issue
@ChihayaK api 24 is deprecated, target development is done using api 29
I also have this bug in master branch, api 30, and as I remember, it is not new bug
I also tried deleting the folder .buildozer to the directory above the application (ie the main one) and rebuild everything with the following arguments
requirements = python3, kivy== master,android. api = 30,android. arch = armeabi-v7a,p4a. branch = develop,p4a. bootstrap = sdl2, the bug remains. To avoid the bug, you need to set the standard arguments and delete the folders.buildozer(there are 2 of them). But this is a very bad decision, I am waiting for your commentsThe most interesting thing is that if after all the manipulations you try to re-build the application with the standard values, deleting the buildozer folder before that, then the bug will be. It can be seen that something else needs to be deleted somewhere
I deleted the folder .buildozer, installed in the spec file
requirements = python3,kivy== master,p4a. branch = develop,p4a. bootstrap = sdl2, and built, the bug is the sameI tried to comment out
# p4a. bootstrap = sdl2and rebuild, it didn’t helpI found the problem. I created a clean VM and installed
buildozer 1.2.0.dev0, after which I made a standard init and built the application, everything worked, after I changed the branch to develop and uncommentedp4a.bootstrap = sdl2, re-built the application, and here it is a bugThat’s not what i understand, maybe i’m wrong but:
am i correct?
Hm, isn’t it from our text input management on android, that wouldn’t release control, and prevent over key handling, until the app itself loses focus?
Ok, I misread it to be the opposite of what you described. However, the answer is basically the same. Your
eventsmethod returns True indicating that it handled the event, hence it breaks the text input handler.I believe this is expected because when the text widget is handling the keyboard, the keyboard events don’t go to other handlers.