Pyjnius: 1.3.0 breaks android's request_permission

hi guys I have the same problem, how to solve it? it's possible to use an older pyjnius in buildozer build? thanks!

hi guys I have the same problem, how to solve it? it's possible to use an older pyjnius in buildozer build? thanks!

Pinning the version using requirements = pyjnius==1.2.1,... should work.

I'm not a Kivy person, but can someone paste a link to the relevant source code?

hi guys I have the same problem, how to solve it? it's possible to use an older pyjnius in buildozer build? thanks!

Pinning the version using requirements = pyjnius==1.2.1,... should work.

thanks, infact it worked!

While pegging the Pyjnius version to 1.2.1 may work for this, v1.2.1 has other limitations, so ideally this should be addressed going forward....

that would be there https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/recipes/android/src/android/permissions.py#L513 sorry i didn't take the time to investigate this at all.

Its made difficult as we cant easily see what the Activity class name is

i would expect it to be https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java#L42 but it can be the equivalent class in another bootstrap (https://github.com/kivy/python-for-android/tree/develop/pythonforandroid/bootstraps)

It looks like python_activity.requestPermissions is a non-static method. But it's being called as if it were static. Which for some reason used to work with older versions of pyjnius. Using python_activity.mActivity.requestPermissions instead seems to work with 1.3.0.

So it looks like it's a bug in p4a's android library instead.

Good spot. Indeed; as in Java, calling a non-static method on a static object would not be allowed by the compiler. @obfusk can you update https://github.com/kivy/python-for-android/issues/2304?

I do think the Pyjnius error could be clearer also - ie the name of the method was not found and in what object!

I'm rather surprised this used to work. ~What instance was it being called on? A null pointer? Or some actual instance of the class?~

Could this be related to these FIXMEs?
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

I do think the Pyjnius error could be clearer also - ie the name of the method was not found and in what object!

:+1:

I do think the Pyjnius error could be clearer also - ie the name of the method was not found and in what object!

👍

PR sent - see #558.

So the summary for anyone reading this in the future:

• the bug was with python-for-android, and the patch has been merged: https://github.com/kivy/python-for-android/pull/2341
• Pyjnius now has an improved error https://github.com/kivy/pyjnius/pull/558

the patch has been merged

Not yet; but it has been approved :)

I think those FIXMEs are indeed related. Since __get__ sets the j_self instead of returning a bound method and simply returns self when called on a class instead of an instance, calling a non-static method on a class will use the last instance it was called on (if any). Of course, calling a non-static method on a class should never have been allowed (and no longer is).

I think those FIXMEs are indeed related. Since __get__ sets the j_self instead of returning a bound method and simply returns self when called on a class instead of an instance, calling a non-static method on a class will use the last instance it was called on (if any). Of course, calling a non-static method on a class should never have been allowed (and no longer is).

Can you show a simpler test case, and then we make a new issue?

Can you show a simpler test case, and then we make a new issue?

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

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

Since calling a non-static method on a class no longer works, the problem's already been fixed.
And now we understand the cause of the problem.
So I don't think we need a new issue.

Or: as no-one seems aware of how this was fixed in 1.3.0, we add a testcase to prevent a future regression back to the previous behaviour. The testcase can expect the exception in the case above.

And can we remove the FIXME's then?

Or: as no-one seems aware of how this was fixed in 1.3.0, we add a testcase to prevent a future regression back to the previous behaviour. The testcase can expect the exception in the case above.

I've actually figured it out now. And the problem was only partially fixed :sweat_smile:. See #567

And can we remove the FIXME's then?

Not yet I think. See #563.

Just a note, I changed my p4a branch to 'develop' and still had this issue. I wiped my .buildozer folder and rebuilt, and the 'develop' branch won't build fresh for me without linking errors (2020-12-13, 16:22 -0500) (EDIT: sorry, this was a different issue. I can't seem to run buildozer successfully on my system, at all, for now.)

I think the way to go for working around this in client apps is to manually make the pyjnius call, so the client codebase will work equally well on the different versions. Obviously releases that fix this are sorely needed here.