[guardian-dev] developer sneak peak: CacheWord

[Hans-Christoph Steiner]

On 03/26/2013 10:47 AM, Mark Murphy wrote:
> On Tue, Mar 26, 2013 at 1:06 PM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>> SIGTERM in UNIX is meant for exactly this: it is sent to a process
>> *requesting* it to terminate.  SIGKILL terminates the process and is not a
>> request.
> 
> OK. I have no idea if SIGTERM is even used in Android, then. If it is,
> at most you could get to it via the NDK.
> 
>> Can't the zeroization be done in the service's onDestroy() to guarantee that
>> it is run?
> 
> No, because onDestroy() itself is not guaranteed to run. Android can
> terminate the process at will without calling onDestroy(): swipe the
> app off of the recent-tasks list, task killers, Force Stop in the
> Settings app, extreme emergency need for RAM, etc. onDestroy() is
> *usually* run.

Does Abel's AlarmManager method guarantee that the zeroing will be run?  It
seems from Java, there is no way to guarantee something will be run before its
killed without a permanent notification.  I guess that's something we can live
with, but otherwise, I think its annoying to have a permanent notification if
its not really communicating something essential.

Perhaps it would be worthwhile to test whether Android terminates with SIGTERM
or SIGKILL.  Here's a good explanation of the two:
http://rackerhacker.com/2010/03/18/sigterm-vs-sigkill/

But my guess is that if Android kills a process without even calling
onDestroy(), then its probably sending SIGKILL, and then native code won't
help.  In that case, sounds like the permanent notification is required to
guarantee that the zeroification will be run.

.hc