Pyjnius: 1.3.0 ломает android request_permission

привет ребята у меня такая же проблема как решить? можно ли использовать более старый pyjnius в сборке buildozer? Спасибо!

привет ребята у меня такая же проблема как решить? можно ли использовать более старый pyjnius в сборке buildozer? Спасибо!

Закрепление версии с помощью requirements = pyjnius==1.2.1,... должно работать.

Я не человек Kivy, но может ли кто-нибудь вставить ссылку на соответствующий исходный код?

привет ребята у меня такая же проблема как решить? можно ли использовать более старый pyjnius в сборке buildozer? Спасибо!

Закрепление версии с помощью requirements = pyjnius==1.2.1,... должно работать.

спасибо, действительно получилось!

В то время как привязка версии Pyjnius к 1.2.1 может работать для этого, версия 1.2.1 имеет другие ограничения, поэтому в идеале это следует решить в будущем....

это было бы там https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/recipes/android/src/android/permissions.py#L513 извините, я не нашел время, чтобы исследовать это вообще.

Это сложно, так как мы не можем легко увидеть, что такое имя класса Activity.

я ожидаю, что это будет https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java# L42 , но это может быть эквивалентный класс в другом бутстрапе (https://github.com/kivy/python-for-android/tree/develop/pythonforandroid/bootstraps)

Похоже, python_activity.requestPermissions — это нестатический метод. Но он вызывается так, как если бы он был статичным. Который по какой-то причине работал со старыми версиями pyjnius. Вместо этого использование python_activity.mActivity.requestPermissions похоже работает с 1.3.0.

Так что похоже, что это ошибка в библиотеке p4a android .

Хорошее место. Конечно; как и в Java, вызов нестатического метода для статического объекта не разрешен компилятором. @obfusk , вы можете обновить https://github.com/kivy/python-for-android/issues/2304?

Я думаю, что ошибка Pyjnius также могла бы быть более ясной - т.е. имя метода не было найдено и в каком объекте!

Я довольно удивлен, что это работало. ~ В каком экземпляре он вызывался? Нулевой указатель? Или какой-то реальный экземпляр класса?~

Может ли это быть связано с этими FIXME ами?
https://github.com/kivy/pyjnius/blob/3371e1012873fe373773c43b556d2796d10d102e/jnius/jnius_export_class.pxi#L815 -L822
https://github.com/kivy/pyjnius/blob/3371e1012873fe373773c43b556d2796d10d102e/jnius/jnius_export_class.pxi#L1079 -L1087

Я думаю, что ошибка Pyjnius также могла бы быть более ясной - т.е. имя метода не было найдено и в каком объекте!

:+1:

Я думаю, что ошибка Pyjnius также могла бы быть более ясной - т.е. имя метода не было найдено и в каком объекте!

👍

PR отправлен - см. #558.

Итак, резюме для тех, кто будет читать это в будущем:

• ошибка была с python-for-android, и патч был слит: https://github.com/kivy/python-for-android/pull/2341
• Pyjnius теперь имеет улучшенную ошибку https://github.com/kivy/pyjnius/pull/558 .

патч был объединен

Еще нет; но одобрили :)

Я думаю, что эти FIXME действительно связаны. Поскольку __get__ устанавливает j_self вместо возврата связанного метода и просто возвращает self при вызове в классе вместо экземпляра, вызов нестатического метода в классе будет использовать последний экземпляр, на котором он был вызван (если есть). Конечно, вызов нестатического метода в классе никогда не должен был быть разрешен (и больше не разрешен).

Я думаю, что эти FIXME действительно связаны. Поскольку __get__ устанавливает j_self вместо возврата связанного метода и просто возвращает self при вызове в классе вместо экземпляра, вызов нестатического метода в классе будет использовать последний экземпляр, на котором он был вызван (если есть). Конечно, вызов нестатического метода в классе никогда не должен был быть разрешен (и больше не разрешен).

Можете ли вы показать более простой тестовый пример, а затем мы делаем новую проблему?

Можете ли вы показать более простой тестовый пример, а затем мы делаем новую проблему?

С 1.2.1:

>>> from jnius import autoclass
>>> s = autoclass("java.lang.String")
>>> s.toString()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "jnius/jnius_export_class.pxi", line 755, in jnius.JavaMethod.__call__
  File "jnius/jnius_export_class.pxi", line 699, in jnius.JavaMethod.ensure_method
jnius.JavaException: Unable to find a None method!
classname: None, definition: ()Ljava/lang/String;
>>> s("foo").toString()
'foo'
>>> s.toString()
'foo'

С 1.3.0:

>>> from jnius import autoclass
>>> s = autoclass("java.lang.String")
>>> s("foo").toString()
'foo'
>>> s.toString()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "jnius/jnius_export_class.pxi", line 1134, in jnius.JavaMultipleMethod.__call__
jnius.JavaException: No methods matching your arguments, requested: (), available: []

Поскольку вызов нестатического метода для класса больше не работает, проблема уже решена.
И теперь мы понимаем причину проблемы.
Поэтому я не думаю, что нам нужен новый выпуск.

Или: поскольку никто, кажется, не знает, как это было исправлено в 1.3.0, мы добавляем тестовый пример, чтобы предотвратить регрессию к прежнему поведению в будущем. Тестовый пример может ожидать исключение в случае выше.

И можем ли мы тогда удалить FIXME?

Или: поскольку никто, кажется, не знает, как это было исправлено в 1.3.0, мы добавляем тестовый пример, чтобы предотвратить регрессию к прежнему поведению в будущем. Тестовый пример может ожидать исключение в случае выше.

Я действительно понял это сейчас. И проблема была устранена лишь частично :sweat_ smile: . См. № 567

И можем ли мы тогда удалить FIXME?

Думаю, еще нет. См. № 563.

Просто примечание: я изменил свою ветку p4a на «разработку», и эта проблема все еще была. Я стер свою папку .buildozer и пересобрал ее, и ветка «разработка» не будет собираться для меня без ошибок связывания (2020-12-13, 16:22 -0500) (EDIT: извините, это была другая проблема. Я пока не могу успешно запустить buildozer в моей системе.)

Я думаю, что способ обойти это в клиентских приложениях — вручную сделать вызов pyjnius, поэтому клиентская кодовая база будет одинаково хорошо работать в разных версиях. Очевидно, что релизы, исправляющие это, здесь крайне необходимы.