Uwaga o trzymaniu zaszyfrowanego hasła itd. też jest bezsensowna (sorry ngcore 😉 ). Z założenia Android ma wystarczająco zabezpieczone dane aplikacji - sam system nie daje do nich dostępu.
Taka prosta uwaga: po co szyfrować hasło które trzymane jest np. w pliku konfiguracyjnym (preference)? Po pierwsze, dane do pliku są blokowane przez system. Po drugie, jeśli nawet nie (czyli mamy zrootowany telefon) to przecież i tak mamy dostęp do samego pliku (co za problem usunąć sam plik). Jasne, teoretycznie przed tym też się można "zabezpieczyć", brak pliku, wymusza brak danych, jeśli są dane cały plik po pierwsze musi istnieć, po drugie sam w sobie musi być zabezpieczony, mam na myśli jego integralność (czyli np. cały zaszyfrowany, do tego wypadałoby sam mechanizm użyty do tego był jednoznacznie powiązany z urządzeniem - przecież co za problem podmienić plik z innego, naszego urządzenia, gdzie jest nasze, znane hasło). Jednak istotne jest, że samo zaszyfrowanie hasła ogólnie nic nie daje, to złudne zabezpieczenie.
Sam rozważałem różne możliwości w swojej aplikacji (dane finansowe) i stanęło na tym, że:
1) dostęp do aplikacji jest blokowany wzorem, samego wzoru dostępu do aplikacji nie szyfruje, jest w pliku konfiguracyjnym,
2) kopię danych tworzoną na SD szyfruję AESem, przy czym hasło user ustala sam (także jest niezaszyfrowane w pliku konfiguracyjnym). Jednak dostęp do kopii nie polega na sprawdzeniu poprawności hasła, kopia danych nie zawiera hasła. Podajesz hasło, po odszyfrowaniu pliku tym hasłem musi wyjść "prawidłowy" plik. Czemu wspominam o backupie, bo z reguły dane z każdej aplikacji są cenne, jeśli sam nie dajesz możliwości stworzenia ich kopii, pociąga to np. konieczność szukanie innych sposób - czyli root i mamy błędne koło,
3) w końcu sama baza danych, jak dla mnie jeśli ktoś chce mieć bezpieczne dane, to nie może np. rootować telefonu 🙂 . Wiem, wielu mój pogląd wyda się dziwny, ale taka jest prawda. No chyba, że faktycznie zastosujesz szyfrowanie w locie. Swoją drogą, wszystko zależy od danych, jeśli są dość proste (a swoją drogą jeśli trzymasz tylko ścieżki, to chyba nie jest skomplikowane), to może lepiej zrobić własny mechanizm ich zapisu. Jednak tracisz możliwości jakie daje SQL, jak dla mnie np. to jest bezcenne. Ale coś za coś (czy wxsqlite3 lub coś podobnego jest na Androida?).
Teraz pytanie co chcesz tak na prawdę zabezpieczyć? Pomyśl może najpierw po prostu nad możliwością zabezpieczenia dostępu do aplikacji (wariant: wścibska żona 😉 ). Na razie jak dla mnie wystarczającym zabezpieczeniem jest: blokada dostępu do danych przez sam system (brak roota) oraz blokada dostępu do aplikacji. Nie da się chyba zrobić roota bez skasowania wszystkiego. Do tego sama blokada dostępu do telefonu.
PS. Jeszcze co do samej bazy, też bym się dobrze zastanowił, żeby wiedzieć co się robi. Rozumiem, że motyw z odszyfrowywaniem/szyfrowaniem pliku bazy był tylko w zakresie - odkodowany plik istnieje tylko w pamięci. Każdy inny wariant jest bezsensu. Nie wiem czy to nawet możliwe przy mechanizmach Androida (o ile się orientuję sam SQLite buforuje pewne dane w pliku tymczasowym, np. operacje w większych transakcjach). Bo tworzenie pliku tymczasowego odpada całkowicie (to tak jak z hasłem, "szyfrujemy" aby czuć się bezpiecznym, a obok leżą jawne dane oznaczone tylko jako "ukryte", tj. usunięte).
PS2. Co do DELETE, teoretycznie mógłbyś przebudowywać bazę po takich operacjach (puszczać VACUUM), ale to też absurd.