Ich habe einen Anwendungsfall, bei dem der Benutzer die Geräteberechtigung bestätigen muss, und die Methode createConfirmDeviceCredentialIntent in KeyguardManager entspricht genau meinen Anforderungen. Diese Methode wurde jedoch seit API 21 hinzugefügt. ( Referenzlink ) Wie kann ich die gleiche Funktionalität vor Android 5.0 erreichen? Ich möchte auch Versionen wie Android 4.X unterstützen.
Danke!
Vor Version 21 ist dies auf nicht gerooteten Geräten sicher nicht möglich und es gibt keine Alternative mit regulären Berechtigungen.
Wenn zusätzliche Administratorberechtigungen erforderlich sind, ist es wahrscheinlich möglich, die Anmeldebestätigung sehr lose mit viel mehr Aufwand zu emulieren, indem Sie DeviceAdminReceiver.onPasswordSucceeded . Sperren Sie den Bildschirm, wenn das Passwort erfolgreich ausgeführt wurde, führen Sie die erforderliche Aktion aus. Dies kann sich als relativ komplex herausstellen, da die Aktion nicht immer empfangen wird (nur wenn sich der Status geändert hat), der letzte Erfolg beibehalten, mit dem Empfänger kommuniziert werden muss usw.
Als eine Nebenbemerkung, überprüfen Sie den Anwendungsfall und Ihr Design, in den meisten Fällen, wenn createConfirmDeviceCredentialIntent verwendet wird, ist es tatsächlich nicht erforderlich und andere Design-Optionen können die Notwendigkeit dafür beseitigen.
Es war besser, Details darüber anzugeben, was genau Sie zu schützen versuchen. Wenn es ein Szenario für einen zufälligen Zugriff auf das Gerät durch eine unautorisierte Person gibt und ein permanentes Token beispielsweise von einem oauth-Dienst erzeugt wird, kann es sinnvoll sein, entweder den gleichen Dienstanmeldeablauf erneut zu autorisieren oder einige ursprüngliche Zugangsdaten zu speichern Zusammen mit dem Token werden dann die Anmeldeinformationen abgefragt und erneut validiert, anstatt nach Geräte-Anmeldedaten zu fragen. Wenn dies für den Anwendungsfall ausreicht, können Sie alternativ google verwenden Melden Sie sich an , um den Zugriff auf Ihre App / Ihr Token zu autorisieren, und verifizieren Sie, dass der Google-Nutzer für das gespeicherte Token identisch ist.
Die beste Antwort, die ich für diese Situation gesehen habe, ist in einem Blogpost beschrieben:
Er erstellt jedoch Systemklassen neu, die privat sind und AOSP-Code aufrufen, der nicht öffentlich ist. Mein Kopfgeld ist für eine bessere Antwort, die keine explizite Klassenbenennung innerhalb des Projekts erfordern würde. Vielleicht kann Smart Lock oder eine andere großartige Sicherheitsbibliothek für die erforderliche Abwärtskompatibilität verwendet werden.