I read that thread, and my conclusion is still the same: use your discretion. Everyone's use case is different and I'm not one who say what is good for them. In this case, for example, it depends a lot on the type of adversary you're trying to protect against:
- If your adversary is capable of root exploits, obviously these kind of solutions won't work for them. - If your adversary is capable of using ADB, you can install your program as a device administrator. - If your adversary is an average user or a 5-year-old kid, they're probably capable of entering Safe Mode. But then, it requires a reboot and your 5-year-old hopefully cannot proceed beyond the Android password prompt. - If your "adversary" is just a 3 year old kid who are barely learning how to read, solutions like this would work perfectly. In short, a single one-size-fits-all recommendation does not exist - therefore I tend to disclose what I know and let the developer decide on their use cases: what cannot be done with logs now for this purpose can (albeit clumsily) be done with the GET_TASKS permission. That is what makes most "blocking" software still work in JB. I'll stop short of making any recommendation because I believe the OP posted a question of a technical nature, and not an ideological one. On Tuesday, 27 November 2012 14:29:49 UTC-5, Kristopher Micinski wrote: > > There was a long discussion on android-developers as to the removal of > this view logs permission, by the way, that brings up the points germane to > the consequences of this. > > kris > > > On Tue, Nov 27, 2012 at 2:28 PM, Kristopher Micinski > <[email protected]<javascript:> > > wrote: > >> Still, you could defeat these apps by simply restarting the phone in >> "safe mode" and uninstalling the app, making this type of app essentially >> useless unless you included it in firmware. >> >> kris >> >> >> On Tue, Nov 27, 2012 at 2:15 PM, Michael <[email protected] <javascript:>>wrote: >> >>> It used to be possible if an application can view logs of the >>> ActivityManager. >>> >>> Starting from JB, viewing other app's logs is a SystemOrSignature >>> permission. Therefore unless your application gets installed on the device >>> prior to the update, the application can only view its own logs. >>> >>> On Stock device - no viewing logs. However, there are workarounds that >>> you can perform such as one that constantly checks with the Framework to >>> see which app is on top. I'm not to say whether these workaround is good >>> or not because it entirely depends on what you are trying to achieve. All >>> I can say is that these are fully documented methods - use your discretion. >>> >>> >>> >>> >>> On Tuesday, 27 November 2012 13:34:00 UTC-5, Kristopher Micinski wrote: >>> >>>> This will not be possible on stock hardware, because you basically >>>> can't "intercept" other intents with a standard app. Proxying intents is >>>> possible if you modify the system, but the ability to do this on stock >>>> firmware would be a security hole in itself. >>>> >>>> The place you would want to look --- should you want to modify the >>>> system to support this --- is the Android package manager that handles the >>>> mediation of intents through the system. >>>> >>>> Kris >>>> >>>> >>>> On Fri, Nov 23, 2012 at 12:05 AM, Igor Cavallera >>>> <[email protected]>wrote: >>>> >>>>> Hey guys, >>>>> >>>>> Is it possible to create an App that would monitor which Apps are >>>>> launched so that it would prompt the user for a password before launching >>>>> a >>>>> possibly sensitive App (say Gmail)? But would not ask the user for his >>>>> password for an App like the Weather App? I was thinking about >>>>> intercepting >>>>> onStart and onResume intents in order to do this, but I am not sure if >>>>> this >>>>> is possible. >>>>> By the way, I am a high student trying to learn android development >>>>> and I was thinking of developing a simple App that did this (as a >>>>> learning >>>>> experience). >>>>> >>>>> Thank You very much for the help. >>>>> >>>>> Igor >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Android Security Discussions" group. >>>>> To view this discussion on the web visit https://groups.google.com/d/* >>>>> *msg/android-security-discuss/-**/SJ1OWS-15wMJ<https://groups.google.com/d/msg/android-security-discuss/-/SJ1OWS-15wMJ> >>>>> . >>>>> To post to this group, send email to android-secu...@** >>>>> googlegroups.com. >>>>> >>>>> To unsubscribe from this group, send email to >>>>> android-security-discuss+**[email protected]. >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/android-security-**discuss?hl=en<http://groups.google.com/group/android-security-discuss?hl=en> >>>>> . >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Security Discussions" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/android-security-discuss/-/I5l3rNF9uqUJ. >>> >>> To post to this group, send email to >>> [email protected]<javascript:> >>> . >>> To unsubscribe from this group, send email to >>> [email protected] <javascript:>. >>> For more options, visit this group at >>> http://groups.google.com/group/android-security-discuss?hl=en. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To view this discussion on the web visit https://groups.google.com/d/msg/android-security-discuss/-/9wGVamczcegJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
