Mam przypadek użycia, który wymaga od użytkownika potwierdzenia poświadczenia urządzenia, a metoda createConfirmDeviceCredentialIntent w KeyguardManager idealnie spełnia moje potrzeby. Jednak ta metoda została dodana od czasu interfejsu API 21. (reference link) Jak więc uzyskać tę samą funkcjonalność przed Androidem 5.0? Chcę również wspierać wersje takie jak Android 4.X.Jak potwierdzić poświadczenia urządzenia przed Androidem 5.0 (API 21)?
Dzięki!
Przed 21 poziomem na pewno nie jest to możliwe na urządzeniu nierootowanym i nie ma alternatywy dla zwykłych uprawnień.
Jeśli jest ok, aby wymagać dodatkowych uprawnień administratora, to prawdopodobnie można naśladować poświadczeń potwierdzenie bardzo luźno, z dużo więcej wysiłku, poprzez wdrożenie DeviceAdminReceiver.onPasswordSucceeded. Zablokuj ekran, gdy hasło powiedzie się, wykonaj wymagane działanie. Może się to okazać stosunkowo skomplikowane, ponieważ akcja nie zawsze jest odbierana (tylko, jeśli status się zmienił), trzeba zachować ostatni sukces, komunikować się z odbiorcą, itp.
Na marginesie, sprawdź dokładnie przypadek użycia i Twój projekt, w większości przypadków kiedy używany jest createConfirmDeviceCredentialIntent, w rzeczywistości nie jest wymagany, a inne opcje projektu mogą wyeliminować jego potrzebę.
Lepiej podać szczegóły tego, co dokładnie próbujesz chronić. Jeśli jest to scenariusz przypadkowego dostępu do urządzenia przez nieupoważnioną osobę i generowany jest stały token, powiedzmy, z jakiejś usługi OASH, rozsądne może być ponowne autoryzowanie przez ten sam przepływ logowania do usługi lub przechowywanie niektórych hmac oryginalnych danych uwierzytelniających wraz z tokenem monituje i ponownie sprawdza dane uwierzytelniające zamiast monitować o poświadczenia urządzenia. Alternatywnie, jeśli jest to wystarczające dla przypadku użycia, możesz użyć numeru google login, aby autoryzować dostęp do swojej aplikacji/tokena i zweryfikować, że użytkownik google jest taki sam dla zapisanego tokena.
Najlepszą odpowiedzią widziałem tej sytuacji jest opisana w blogu:
jednak odtwarza klas systemowych, które są prywatne i zwraca kod AOSP że nie jest publiczna. Moja nagroda to lepsza odpowiedź, która nie wymagałaby wyraźnego nazewnictwa klas wewnątrz projektu. Być może Smart Lock lub inna niesamowita biblioteka zabezpieczeń może być użyta dla wymaganej kompatybilności wstecznej.
Problem nie wydaje się być sposobem, aby wymusić potwierdzenie pin z tymi prywatnymi API. Odblokowuje się raz na odblokowaniu telefonu, więc otrzymujesz bezpieczny magazyn bez wyzwania dotyczącego ochrony na otwartym telefonie. Jeśli twoim celem jest właśnie to, próbujesz odpowiedzieć na inne pytanie, różni się ono od tego, co zostało zadane, ponieważ nie zastępuje potwierdzenia createConfirmDeviceCredentialIntent. –
Ale to jest ... UI potwierdzenie pin jest w blogu jest na niebezpieczną ścieżkę przy użyciu systemu Android: 'try {if (Build.VERSION.SDK_INT
Nie tylko jest to niebezpieczna ścieżka (dobrze, nie * tak * niebezpiecznie), nie działa w sposób, w jaki można myśleć. Po odblokowaniu sklepu (w tym na odblokowaniu telefonu) nie będzie już monitować o pin, wysyłanie intencji UNLOCK nic nie wyskakuje, a AFAIK nie ma sposobu na wymuszenie auth do wyskakiwania w ten sposób. Tak więc odpowiedź na oryginalne pytanie - nie ma wymiany (więc twoje pytanie jest inne). –
Może zaistnieć potrzeba samodzielnego zaimplementowania. – tynn
Powodzenia z tym @ danny-zheng? – Beth