Pyjnius: 1.3.0 unterbricht die request_permission von Android

hallo leute ich habe das gleiche problem, wie kann man es lösen? Ist es möglich, einen älteren Pyjnius im Buildozer-Build zu verwenden? Danke!

hallo leute ich habe das gleiche problem, wie kann man es lösen? Ist es möglich, einen älteren Pyjnius im Buildozer-Build zu verwenden? Danke!

Das Anheften der Version mit requirements = pyjnius==1.2.1,... sollte funktionieren.

Ich bin keine Kivy-Person, aber kann jemand einen Link zum relevanten Quellcode einfügen?

hallo leute ich habe das gleiche problem, wie kann man es lösen? Ist es möglich, einen älteren Pyjnius im Buildozer-Build zu verwenden? Danke!

Das Anheften der Version mit requirements = pyjnius==1.2.1,... sollte funktionieren.

danke, es hat tatsächlich funktioniert!

Während das Verknüpfen der Pyjnius-Version mit 1.2.1 dafür funktionieren könnte, hat v1.2.1 andere Einschränkungen, also sollte dies idealerweise in Zukunft angegangen werden ....

das wäre da https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/recipes/android/src/android/permissions.py#L513 Entschuldigung, ich habe mir nicht die Zeit genommen, dies zu untersuchen überhaupt.

Dies wird erschwert, da wir nicht leicht erkennen können, wie der Name der Aktivitätsklasse lautet

Ich würde erwarten, dass es https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java# ist

Es sieht so aus, als ob python_activity.requestPermissions eine nicht statische Methode ist. Aber es wird aufgerufen, als ob es statisch wäre. Was aus irgendeinem Grund früher mit älteren Versionen von pyjnius funktionierte. Die Verwendung python_activity.mActivity.requestPermissions scheint stattdessen mit 1.3.0 zu funktionieren.

Es sieht also so aus, als wäre es stattdessen ein Fehler in der android -Bibliothek von p4a.

Gute Stelle. In der Tat; Wie in Java würde der Compiler das Aufrufen einer nicht statischen Methode für ein statisches Objekt nicht zulassen. @obfusk kannst du https://github.com/kivy/python-for-android/issues/2304 aktualisieren?

Ich denke, der Pyjnius-Fehler könnte auch klarer sein - dh der Name der Methode wurde nicht gefunden und in welchem ​​​​Objekt!

Ich bin ziemlich überrascht, dass das früher funktioniert hat. ~Welche Instanz wurde aufgerufen? Ein Nullzeiger? Oder eine tatsächliche Instanz der Klasse?~

Könnte das mit diesen FIXME zusammenhängen?
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

Ich denke, der Pyjnius-Fehler könnte auch klarer sein - dh der Name der Methode wurde nicht gefunden und in welchem ​​​​Objekt!

:+1:

Ich denke, der Pyjnius-Fehler könnte auch klarer sein - dh der Name der Methode wurde nicht gefunden und in welchem ​​​​Objekt!

👍

PR gesendet - siehe Nr. 558.

Also die Zusammenfassung für alle, die dies in Zukunft lesen:

• der Fehler lag bei python-for-android, und der Patch wurde zusammengeführt: https://github.com/kivy/python-for-android/pull/2341
• Pyjnius hat jetzt einen verbesserten Fehler https://github.com/kivy/pyjnius/pull/558

Der Patch wurde zusammengeführt

Noch nicht; aber genehmigt :)

Ich denke, diese FIXME s sind tatsächlich verwandt. Da __get__ j_self setzt, anstatt eine gebundene Methode zurückzugeben, und einfach self zurückgibt, wenn es für eine Klasse statt für eine Instanz aufgerufen wird, wird das Aufrufen einer nicht statischen Methode für eine Klasse Verwenden Sie die letzte Instanz, in der es aufgerufen wurde (falls vorhanden). Natürlich hätte das Aufrufen einer nichtstatischen Methode für eine Klasse niemals erlaubt werden dürfen (und ist es nicht mehr).

Ich denke, diese FIXME s sind tatsächlich verwandt. Da __get__ j_self setzt, anstatt eine gebundene Methode zurückzugeben, und einfach self zurückgibt, wenn es für eine Klasse statt für eine Instanz aufgerufen wird, wird das Aufrufen einer nicht statischen Methode für eine Klasse Verwenden Sie die letzte Instanz, in der es aufgerufen wurde (falls vorhanden). Natürlich hätte das Aufrufen einer nichtstatischen Methode für eine Klasse niemals erlaubt werden dürfen (und ist es nicht mehr).

Können Sie einen einfacheren Testfall zeigen, und dann machen wir ein neues Problem?

Können Sie einen einfacheren Testfall zeigen, und dann machen wir ein neues Problem?

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

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

Da der Aufruf einer nicht statischen Methode auf einer Klasse nicht mehr funktioniert, wurde das Problem bereits behoben.
Und jetzt verstehen wir die Ursache des Problems.
Ich glaube also nicht, dass wir eine neue Ausgabe brauchen.

Oder: Da niemand zu wissen scheint, wie dies in 1.3.0 behoben wurde, fügen wir einen Testfall hinzu, um eine zukünftige Regression zurück zum vorherigen Verhalten zu verhindern. Der Testfall kann im obigen Fall mit der Ausnahme rechnen.

Und können wir die FIXMEs dann entfernen?

Oder: Da niemand zu wissen scheint, wie dies in 1.3.0 behoben wurde, fügen wir einen Testfall hinzu, um eine zukünftige Regression zurück zum vorherigen Verhalten zu verhindern. Der Testfall kann im obigen Fall mit der Ausnahme rechnen.

Ich habe es jetzt tatsächlich kapiert. Und das Problem wurde nur teilweise behoben :sweat_smile :. Siehe Nr. 567

Und können wir die FIXMEs dann entfernen?

Noch nicht denke ich. Siehe #563.

Nur eine Anmerkung, ich habe meinen p4a-Zweig auf „Entwickeln“ geändert und hatte immer noch dieses Problem. Ich habe meinen .buildozer-Ordner gelöscht und neu erstellt, und der Zweig „develop“ wird ohne Verknüpfungsfehler nicht neu für mich erstellt (2020-12-13, 16:22 -0500) (BEARBEITEN: Entschuldigung, das war ein anderes Problem. Ich kann buildozer derzeit überhaupt nicht erfolgreich auf meinem System ausführen.)

Ich denke, der Weg, um dies in Client-Apps zu umgehen, besteht darin, den Pyjnius-Aufruf manuell durchzuführen, damit die Client-Codebasis auf den verschiedenen Versionen gleich gut funktioniert. Offensichtlich werden hier Releases dringend benötigt, die dies beheben.