Pyjnius: 1.3.0 rompe request_permission de Android

hola amigos tengo el mismo problema, como lo soluciono? ¿Es posible usar un pyjnius más antiguo en la compilación buildozer? ¡Gracias!

hola amigos tengo el mismo problema, como lo soluciono? ¿Es posible usar un pyjnius más antiguo en la compilación buildozer? ¡Gracias!

Fijar la versión usando requirements = pyjnius==1.2.1,... debería funcionar.

No soy una persona de Kivy, pero ¿alguien puede pegar un enlace al código fuente relevante?

hola amigos tengo el mismo problema, como lo soluciono? ¿Es posible usar un pyjnius más antiguo en la compilación buildozer? ¡Gracias!

Fijar la versión usando requirements = pyjnius==1.2.1,... debería funcionar.

gracias, de hecho funciono!

Si bien vincular la versión de Pyjnius a 1.2.1 puede funcionar para esto, v1.2.1 tiene otras limitaciones, por lo que idealmente esto debería abordarse en el futuro....

eso estaría allí https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/recipes/android/src/android/permissions.py#L513 lo siento, no me tomé el tiempo para investigar esto en absoluto.

Se hace difícil ya que no podemos ver fácilmente cuál es el nombre de la clase Actividad

esperaría que fuera https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java# L42 pero puede ser la clase equivalente en otro bootstrap (https://github.com/kivy/python-for-android/tree/develop/pythonforandroid/bootstraps)

Parece que python_activity.requestPermissions es un método no estático. Pero se está llamando como si fuera estático. Que por alguna razón solía funcionar con versiones anteriores de pyjnius. Usar python_activity.mActivity.requestPermissions en su lugar parece funcionar con 1.3.0.

Entonces parece que es un error en la biblioteca android de p4a.

Buen lugar. Por supuesto; como en Java, el compilador no permitiría llamar a un método no estático en un objeto estático. @obfusk , ¿puedes actualizar https://github.com/kivy/python-for-android/issues/2304?

Creo que el error de Pyjnius también podría ser más claro, es decir, ¡no se encontró el nombre del método y en qué objeto!

Estoy bastante sorprendido de que esto solía funcionar. ~¿En qué instancia se estaba llamando? ¿Un puntero nulo? ¿O alguna instancia real de la clase? ~

¿Podría esto estar relacionado con estos FIXME s?
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

Creo que el error de Pyjnius también podría ser más claro, es decir, ¡no se encontró el nombre del método y en qué objeto!

:+1:

Creo que el error de Pyjnius también podría ser más claro, es decir, ¡no se encontró el nombre del método y en qué objeto!

👍

PR enviado - ver #558.

Así que el resumen para cualquiera que lea esto en el futuro:

• el error fue con python-for-android, y el parche se fusionó: https://github.com/kivy/python-for-android/pull/2341
• Pyjnius ahora tiene un error mejorado https://github.com/kivy/pyjnius/pull/558

el parche ha sido fusionado

Aún no; pero ha sido aprobado :)

Creo que esos FIXME están realmente relacionados. Dado que __get__ establece j_self en lugar de devolver un método vinculado y simplemente devuelve self cuando se llama a una clase en lugar de a una instancia, llamar a un método no estático en una clase use la última instancia en la que se invocó (si corresponde). Por supuesto, nunca debería haberse permitido llamar a un método no estático en una clase (y ya no lo es).

Creo que esos FIXME están realmente relacionados. Dado que __get__ establece j_self en lugar de devolver un método vinculado y simplemente devuelve self cuando se llama a una clase en lugar de a una instancia, llamar a un método no estático en una clase use la última instancia en la que se invocó (si corresponde). Por supuesto, nunca debería haberse permitido llamar a un método no estático en una clase (y ya no lo es).

¿Puede mostrar un caso de prueba más simple y luego hacemos un nuevo problema?

¿Puede mostrar un caso de prueba más simple y luego hacemos un nuevo problema?

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

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

Dado que llamar a un método no estático en una clase ya no funciona, el problema ya se solucionó.
Y ahora entendemos la causa del problema.
Así que no creo que necesitemos un nuevo número.

O: como nadie parece saber cómo se solucionó esto en 1.3.0, agregamos un caso de prueba para evitar una regresión futura al comportamiento anterior. El caso de prueba puede esperar la excepción en el caso anterior.

¿Y podemos eliminar los FIXME entonces?

O: como nadie parece saber cómo se solucionó esto en 1.3.0, agregamos un caso de prueba para evitar una regresión futura al comportamiento anterior. El caso de prueba puede esperar la excepción en el caso anterior.

De hecho, lo he descubierto ahora. Y el problema solo se solucionó parcialmente :sweat_ smile:. Ver #567

¿Y podemos eliminar los FIXME entonces?

Aún no creo. Ver #563.

Solo una nota, cambié mi rama p4a a 'desarrollar' y todavía tenía este problema. Limpié mi carpeta .buildozer y la reconstruí, y la rama 'desarrollar' no se compilará de nuevo sin errores de vinculación (2020-12-13, 16:22 -0500) (EDITAR: lo siento, este fue un problema diferente. I Parece que no puedo ejecutar buildozer con éxito en mi sistema, por ahora).

Creo que el camino a seguir para solucionar esto en las aplicaciones cliente es hacer manualmente la llamada pyjnius, por lo que el código base del cliente funcionará igual de bien en las diferentes versiones. Obviamente, las versiones que solucionan esto son muy necesarias aquí.