Pyjnius: 1.3.0 rompt le request_permission d'android

Salut les gars, j'ai le même problème, comment le résoudre? il est possible d'utiliser un ancien pyjnius dans buildozer build ? Merci!

Salut les gars, j'ai le même problème, comment le résoudre? il est possible d'utiliser un ancien pyjnius dans buildozer build ? Merci!

Épingler la version à l'aide requirements = pyjnius==1.2.1,... devrait fonctionner.

Je ne suis pas une personne de Kivy, mais quelqu'un peut-il coller un lien vers le code source pertinent ?

Salut les gars, j'ai le même problème, comment le résoudre? il est possible d'utiliser un ancien pyjnius dans buildozer build ? Merci!

Épingler la version à l'aide requirements = pyjnius==1.2.1,... devrait fonctionner.

merci, en fait ça a marché !

Bien que le rattachement de la version Pyjnius à 1.2.1 puisse fonctionner pour cela, la v1.2.1 a d'autres limitations, donc idéalement, cela devrait être résolu à l'avenir....

ce serait là https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/recipes/android/src/android/permissions.py#L513 désolé je n'ai pas pris le temps d'enquêter sur ce du tout.

C'est rendu difficile car nous ne pouvons pas voir facilement quel est le nom de la classe d'activité

je m'attendrais à ce que ce soit https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java# L42 mais cela peut être la classe équivalente dans un autre bootstrap (https://github.com/kivy/python-for-android/tree/develop/pythonforandroid/bootstraps)

Il semble que python_activity.requestPermissions soit une méthode non statique. Mais il est appelé comme s'il était statique. Qui, pour une raison quelconque, fonctionnait avec les anciennes versions de pyjnius. L'utilisation python_activity.mActivity.requestPermissions la place semble fonctionner avec 1.3.0.

Il semble donc que ce soit un bogue dans la bibliothèque android de p4a à la place.

Bon endroit. En effet; comme en Java, appeler une méthode non statique sur un objet statique ne serait pas autorisé par le compilateur. @obfusk pouvez-vous mettre à jour https://github.com/kivy/python-for-android/issues/2304 ?

Je pense que l'erreur Pyjnius pourrait également être plus claire - c'est-à-dire que le nom de la méthode n'a pas été trouvé et dans quel objet!

Je suis plutôt surpris que cela fonctionnait avant. ~ Dans quelle instance était-il appelé ? Un pointeur nul ? Ou une instance réelle de la classe ? ~

Cela pourrait-il être lié à ces 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

Je pense que l'erreur Pyjnius pourrait également être plus claire - c'est-à-dire que le nom de la méthode n'a pas été trouvé et dans quel objet!

:+1:

Je pense que l'erreur Pyjnius pourrait également être plus claire - c'est-à-dire que le nom de la méthode n'a pas été trouvé et dans quel objet!

👍

PR envoyé - voir #558.

Donc, le résumé pour tous ceux qui liront ceci à l'avenir:

• le bogue était avec python-for-android, et le patch a été fusionné : https://github.com/kivy/python-for-android/pull/2341
• Pyjnius a maintenant une erreur améliorée https://github.com/kivy/pyjnius/pull/558

le patch a été fusionné

Pas encore; mais c'est validé :)

Je pense que ces FIXME sont en effet liés. Étant donné que __get__ définit le j_self au lieu de renvoyer une méthode liée et renvoie simplement self lorsqu'il est appelé sur une classe au lieu d'une instance, appeler une méthode non statique sur une classe utilisez la dernière instance sur laquelle il a été appelé (le cas échéant). Bien sûr, appeler une méthode non statique sur une classe n'aurait jamais dû être autorisé (et ne l'est plus).

Je pense que ces FIXME sont en effet liés. Étant donné que __get__ définit le j_self au lieu de renvoyer une méthode liée et renvoie simplement self lorsqu'il est appelé sur une classe au lieu d'une instance, appeler une méthode non statique sur une classe utilisez la dernière instance sur laquelle il a été appelé (le cas échéant). Bien sûr, appeler une méthode non statique sur une classe n'aurait jamais dû être autorisé (et ne l'est plus).

Pouvez-vous montrer un cas de test plus simple, puis nous créerons un nouveau problème ?

Pouvez-vous montrer un cas de test plus simple, puis nous créerons un nouveau problème ?

Avec 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'

Avec 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: []

Étant donné que l'appel d'une méthode non statique sur une classe ne fonctionne plus, le problème a déjà été résolu.
Et maintenant nous comprenons la cause du problème.
Je ne pense donc pas que nous ayons besoin d'un nouveau numéro.

Ou : comme personne ne semble savoir comment cela a été corrigé dans la version 1.3.0, nous ajoutons un cas de test pour empêcher une future régression vers le comportement précédent. Le cas de test peut s'attendre à l'exception dans le cas ci-dessus.

Et pouvons-nous alors retirer les FIXME ?

Ou : comme personne ne semble savoir comment cela a été corrigé dans la version 1.3.0, nous ajoutons un cas de test pour empêcher une future régression vers le comportement précédent. Le cas de test peut s'attendre à l'exception dans le cas ci-dessus.

Je l'ai compris maintenant. Et le problème n'a été que partiellement résolu :sweat_ smile:. Voir #567

Et pouvons-nous alors retirer les FIXME ?

Pas encore je pense. Voir #563.

Juste une note, j'ai changé ma branche p4a en "développer" et j'avais toujours ce problème. J'ai effacé mon dossier .buildozer et reconstruit, et la branche "développer" ne se construira pas pour moi sans erreurs de liaison (2020-12-13, 16:22 -0500) (EDIT : désolé, c'était un problème différent. Je n'arrive pas à exécuter buildozer avec succès sur mon système, du tout, pour l'instant.)

Je pense que la solution pour contourner ce problème dans les applications clientes consiste à effectuer manuellement l'appel pyjnius, de sorte que la base de code client fonctionnera aussi bien sur les différentes versions. De toute évidence, des versions qui résolvent ce problème sont indispensables ici.