> You presume that the polling option will be maintained in future > releases in its current incarnation. I would not make that assumption. >
Why should I not make *that *assumption? Those are *public *APIs in ActivityManager and the polling part could be done 100 different ways (Threads, Handler, TimerTasks, etc.) I guess I forget that Google has removed public APIs in the past so there is nothing stopping them from doing that again. > You mean, besides the security and privacy reasons? For example, I've > been personally reporting apps that use crap like this to prevent > themselves from being uninstalled. The ability for any app to find out > about the foreground, come to the foreground itself, then kill the > background process, has always been seriously scary, even though > knowledge of what is in the foreground has legit uses. > So it's really a situation of a few bad apples ruining the whole bunch. I don't like them apples. Some users lose out, from lost (or less-efficient) functionality. Some > users gain, from lost (or weakened) malware. Google, in their > estimation, and given plans for upcoming releases, presumably believes > that what they have done is a net gain. You, of course, are welcome to > disagree. > That's a fair point, but honestly at the current moment they just made malware less efficient. I have serious doubts that Google curbed an epidemic because of this. You are welcome to contribute changes via the AOSP for a more > controlled means of providing this sort of app-locker capability, such > as via an extension to the device admin APIs. Of course, I wish that > this contribution process would be substantially easier (and more > likely to succeed) than it is. > > You are welcome to add app-locker capabilities to your favorite ROM > mod, if the AOSP option is not working. > > You are welcome to make a complete fork of Android, if you so choose. > > You are also welcome to brainstorm other ways where app lockers can > exist while the same techniques cannot be used for nefarious purposes. > Personally, I think that's impossible -- the device admin approach at > least makes it a whole lot less likely that a user will accidentally > run into problems. But I have certainly been wrong before. > > Google's decision to make the Play Store be non-curated (i.e., no > up-front manual inspection of apps, a la the iOS App Store and the > Amazon AppStore for Android) means that Google is going to have to > continue to tighten the screws to help prevent malware from doing the > "mal" part. Yes, these changes will result in some fallout with some > legit apps. And, one hopes that if they do remove the polling option > that they turn around and expose something else that enables the legit > apps while helping slow down the malware (e.g., making this > information available via device admin APIs). > Unfortunately, from my perspective this only worsens fragmentation (not to beat a dead horse). At the end of the day, hackers will find a way around this (polling still works). DeviceAdministrators are un-installable until they are disabled, and what's to stop an app from doing just that? Once enabled, they listen for the opening of that Activity and force close it? I would have preferred something along the lines of notifying developers "we will remove this API X and replace it with API Y in the next version" similar to the READ_EXTERNAL_STORAGE permission. Too late for that. I would like to contribute to AOSP but I really don't have the time. I honestly don't even know how, but I've heard from other developers that you'll get nowhere fast offering "enhancements". I just don't need to waste my time with that. Also, I develop applications even if they go a bit outside the SDK. AOSP is great but it powers a small percent of devices right now. Custom ROMs are FAR fewer. I don't target root users, I target the average user. My goal is to bring the personalization features of custom ROMs via applications to REAL Android devices. Unfortunately, I'm coming to terms with the fact that I either need to work a heck of a lot harder, or move on. To Google's pleasure I'm definitely leaning toward the later. Tom > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://github.com/commonsguy > http://commonsware.com/blog | http://twitter.com/commonsguy > > Android Training in NYC: http://marakana.com/training/android/ > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. 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-developers?hl=en
