If your Services are indeed totally separate processes then the unmounting shouldn't be needed really. Unmounting is really only needed to zero the password from memory. A regular Android Service is not in a separate process, you have to have `android:process=":service"` in the <service> block in AndroidManifest.xml
.hc zoki: > I tried that (discussion above) but I have a problem: > https://www.pastiebin.com/58b942a5c304b > > - I start a service (in different process than app) where I create or mount > an iocipher container. I'm playing files from it and when I'm done I detach > all threads and unmount container (snippet below) and stop service > (stopSelf; onDestroy on service is called). > - When I start again I see that service is created again (onCreate in > service is called) and I repeat a process same as before (iocipher > container is mounted, reading from container for playing, when done detach > all threads and unmount and stopService....) > - After repeating that 4 or 5 times I get a crash (log is above) > > I have more thread because I two schedulers. > > I detach threads like this (there are always 3 or 4 active threads): > > int i = 8; > VirtualFileSystem vfs = VirtualFileSystem.get(); > while (i > 0 && vfs.isMounted()) { > try { > vfs.unmount(); > } catch (IllegalStateException e) { > vfs.detachThread(); > } > i--; > } > > Unmount on the end is always successful, but is this the correct way of > unmounting container? Can be problem here? > > For playback I'm using custom content provider ( > https://github.com/n8fr8/CameraCipher/blob/master/src/info/guardianproject/iocipher/camera/io/IOCipherContentProvider.java). > Can be problem somewhere here that pipe is not closed? How could I check > this? > > I would be very glad if someone could point me to any direction where to > check for errors why is this crashing. Thanks! > > On Fri, Feb 10, 2017 at 12:21 PM zoki <[email protected]> wrote: > >> Thanks. >> Service and provider in another process looks like a way to go. Will try >> that. >> >> On Fri, 10 Feb 2017, 11:16 Hans-Christoph Steiner, < >> [email protected]> wrote: >> >> >> hey Zoki, >> >> It is theoretically possible to use multiple containers, but it is not >> well tested and it is not the use case we have in mind for it. IOCipher >> is designed around the idea of having a single file system that is >> dedicated to the app. It was not really designed to be general purpose >> "containers". That said, there is no technical limitation that would >> prevent IOCipher from handling multiple containers. Its mostly a >> question of how to design a good API for that. IOCipher uses >> java.io.File as the API, there is no way to specify which container to >> use in that API. Having a global "switch container" method seems like a >> recipe for many super confusing bugs. >> >> I think starting a Service in its own process for each container would >> be the best way to do that with IOCipher as it is now. >> >> .hc >> >> zoki: >>> Hello, I have few questions regarding using multiple iocipher containers. >>> Is it possible to use multiple containers at the same time? Or at least >>> easy switching between them? >>> I don't know how to use them because VirtualFileSystem is singleton. I >>> guess that has some purpose, can someone please explain why? >>> >>> Now with new ExoPlayer which has support for playing from content >> provider >>> is very easy to play videos from secure container. I'm thinking to use >>> another container for caching video files, because it's easier to delete >>> container files and free storage rather than doing container shrinking. >>> Would I need to start new process for that? >>> >>> Thanks for any help :) >>> >>> >>> >>> _______________________________________________ >>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >>> To unsubscribe, email: [email protected] >>> >> >> -- >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 >> _______________________________________________ >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >> To unsubscribe, email: [email protected] >> >> > -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
