Pyjnius: 1.3.0 quebra request_permission do android

oi pessoal estou com o mesmo problema, como resolver? é possível usar um pyjnius mais antigo na compilação do buildozer? obrigado!

oi pessoal estou com o mesmo problema, como resolver? é possível usar um pyjnius mais antigo na compilação do buildozer? obrigado!

Fixar a versão usando requirements = pyjnius==1.2.1,... deve funcionar.

Eu não sou uma pessoa Kivy, mas alguém pode colar um link para o código-fonte relevante?

oi pessoal estou com o mesmo problema, como resolver? é possível usar um pyjnius mais antigo na compilação do buildozer? obrigado!

Fixar a versão usando requirements = pyjnius==1.2.1,... deve funcionar.

obrigado, de fato funcionou!

Embora vincular a versão do Pyjnius a 1.2.1 possa funcionar para isso, a v1.2.1 tem outras limitações, portanto, idealmente, isso deve ser resolvido daqui para frente....

isso estaria lá https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/recipes/android/src/android/permissions.py#L513 desculpe, eu não tive tempo para investigar isso em absoluto.

É difícil porque não podemos ver facilmente qual é o nome da classe Activity

eu esperaria que fosse https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java# L42 mas pode ser a classe equivalente em outro bootstrap (https://github.com/kivy/python-for-android/tree/develop/pythonforandroid/bootstraps)

Parece que python_activity.requestPermissions é um método não estático. Mas está sendo chamado como se fosse estático. Que por algum motivo costumava funcionar com versões mais antigas do pyjnius. Usar python_activity.mActivity.requestPermissions parece funcionar com 1.3.0.

Então parece que é um bug na biblioteca android do p4a.

Bom lugar. De fato; como em Java, chamar um método não estático em um objeto estático não seria permitido pelo compilador. @obfusk você pode atualizar https://github.com/kivy/python-for-android/issues/2304?

Eu acho que o erro Pyjnius poderia ser mais claro também - ou seja, o nome do método não foi encontrado e em qual objeto!

Estou bastante surpreso que isso costumava funcionar. ~ Em que instância ele estava sendo chamado? Um ponteiro nulo? Ou alguma instância real da classe?~

Isso poderia estar relacionado a esses 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

Eu acho que o erro Pyjnius poderia ser mais claro também - ou seja, o nome do método não foi encontrado e em qual objeto!

:+1:

Eu acho que o erro Pyjnius poderia ser mais claro também - ou seja, o nome do método não foi encontrado e em qual objeto!

👍

PR enviado - veja #558.

Então, o resumo para quem ler isso no futuro:

• o bug estava com python-for-android, e o patch foi mesclado: https://github.com/kivy/python-for-android/pull/2341
• Pyjnius agora tem um erro aprimorado https://github.com/kivy/pyjnius/pull/558

o patch foi mesclado

Ainda não; mas foi aprovado :)

Eu acho que esses FIXME s estão realmente relacionados. Como __get__ define j_self em vez de retornar um método vinculado e simplesmente retorna self quando chamado em uma classe em vez de uma instância, chamar um método não estático em uma classe use a última instância em que foi chamado (se houver). Claro, chamar um método não estático em uma classe nunca deveria ter sido permitido (e não é mais).

Eu acho que esses FIXME s estão realmente relacionados. Como __get__ define j_self em vez de retornar um método vinculado e simplesmente retorna self quando chamado em uma classe em vez de uma instância, chamar um método não estático em uma classe use a última instância em que foi chamado (se houver). Claro, chamar um método não estático em uma classe nunca deveria ter sido permitido (e não é mais).

Você pode mostrar um caso de teste mais simples e, em seguida, criar um novo problema?

Você pode mostrar um caso de teste mais simples e, em seguida, criar um novo problema?

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

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

Como chamar um método não estático em uma classe não funciona mais, o problema já foi corrigido.
E agora entendemos a causa do problema.
Então eu não acho que precisamos de um novo problema.

Ou: como ninguém parece saber como isso foi corrigido na versão 1.3.0, adicionamos um caso de teste para evitar uma regressão futura ao comportamento anterior. O caso de teste pode esperar a exceção no caso acima.

E podemos remover os FIXME's então?

Ou: como ninguém parece saber como isso foi corrigido na versão 1.3.0, adicionamos um caso de teste para evitar uma regressão futura ao comportamento anterior. O caso de teste pode esperar a exceção no caso acima.

Na verdade, descobri agora. E o problema foi apenas parcialmente corrigido :sweat_ smile:. Veja #567

E podemos remover os FIXME's então?

Ainda não eu acho. Veja #563.

Apenas uma observação, mudei minha ramificação p4a para 'desenvolver' e ainda tive esse problema. Limpei minha pasta .buildozer e reconstruí, e a ramificação 'develop' não será compilada de novo para mim sem erros de vinculação (2020-12-13, 16:22 -0500) (EDIT: desculpe, este foi um problema diferente. Eu não consigo executar o buildozer com sucesso no meu sistema, por enquanto.)

Acho que a maneira de contornar isso em aplicativos cliente é fazer manualmente a chamada pyjnius, para que a base de código do cliente funcione igualmente bem nas diferentes versões. Obviamente, os lançamentos que corrigem isso são extremamente necessários aqui.