On Sun, Aug 26, 2012 at 10:33 PM, Tom karbonki...@gmail.com wrote:
So it's really a situation of a few bad apples ruining the whole bunch. I
don't like them apples.
Yup. And to the extent we can figure out ways to better filter the bad
apples, without saying we cannot have any apples, the
I think my explanation of DeviceAdministrators was poor, I didn't mean to
suggest that they can enable themselves. I dislike how DAs are
un-installable until disabled but I do agree that it makes it more
difficult to do malicious things this way. Pop-up permissions could also
work, like in iOS
On Mon, Aug 27, 2012 at 9:18 AM, Tom karbonki...@gmail.com wrote:
If that doesn't work I would have honestly suggested removing
KILL_BACKGROUND_PROCESSES long before removing the ActivityManager APIs.
Task-killers aside, I can't think of any good uses for that permission. By
removing it, don't
For what it's worth, there were a few interesting APIs that could
accomplish this effect much better.
IActivityWatcher (no longer exists in Jelly Bean), available 1.5 - 4.0 and
never required a permission
IProcessObserver (now guarded by the SET_ACTIVITY_WATCHER permission in
Jelly Bean),
It's not just inconvenient because you have to poll: it's inefficient
and forces the everlasting service pattern on an app, which means that
you not only have to poll, you also have to write your app in a way
that is inconsistent with good programming practices.
kris
On Sun, Aug 26, 2012 at 5:10
On Sun, Aug 26, 2012 at 5:10 PM, Tom karbonki...@gmail.com wrote:
The removal of these was more upsetting to me
because at the end of the day they provide NO security benefit. If I REALLY
want to know when the top app changes I will just poll every 100ms. These
simply made it more efficient
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,
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.
On Fri, Jul 27, 2012 at 1:26 PM, Bryan Ashby nuskoo...@gmail.com wrote:
Perhaps another solution is a API set and a new level of permission
authentication. E.g., an developer would need to sign with a key that
contains a trusted CA (Google stamp of approval or such)
That is not how Android
How about a broadcast to DeviceAdminReceiver.
Pent
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
Note that app-locking is not the only use-case for running-app-
detection.
My app does app-specific actions like 'if in Browser turn on wifi',
'if in Reader AND (if device orientation is vertical brightness high
else brightness low)'
However, Dianne has stated in another thread along the lines
Generally if you can do this, it's kind of considered a security hole, and
while these chinese wall policies are implementable, I'm a little skeptical
as to their real utility...
On Jul 27, 2012 2:09 AM, Pent supp...@apps.dinglisch.net wrote:
Note that app-locking is not the only use-case for
Generally if you can do this, it's kind of considered a security hole,
By whom and for what reason ?
while these chinese wall
policies are implementable, I'm a little skeptical as to their real utility...
Luckily my customers aren't.
Pent
--
You received this message because you are
Most people I know on this list argue that apps should never be allowed to
change system behavior. I hope you understand the implications for apps
that aren't legitimate, unlike yours. Sure there are hacks, removing them
happens slowly.
Whats your app title, since I'm assuming you won't disclose
By the way, I think anyone at Google would argue this is a security hole,
so I'm not alone
On Jul 27, 2012 9:37 AM, Kristopher Micinski krismicin...@gmail.com
wrote:
Most people I know on this list argue that apps should never be allowed to
change system behavior. I hope you understand the
By the way, I think anyone at Google would argue this is a security hole,
so I'm not alone
They seem to allow services to do virtually anything that an activity
can do at virtually any time. Doesn't seem to me they consider it a
security hole.
My app is called Tasker. It uses ActivityManager
I didn't say that was a security hole, but I believe you could. What I said
was bad was when an apparently could gain power over the system.
AM polling is an option, but while it's a possible hack, they certainly
don't *want* this, hence lack of an API, you can see the lengthy
discussions as to
By the way, I don't think your apparently shouldn't exist, I think there
should be a way to extended system functionality in a secure way, and I
don't think poor undocumented interfaces subject to change are the right way
On Jul 27, 2012 10:05 AM, Kristopher Micinski krismicin...@gmail.com
wrote:
App, not apparently, I have an overzealous autocorrect
On Jul 27, 2012 10:13 AM, Kristopher Micinski krismicin...@gmail.com
wrote:
By the way, I don't think your apparently shouldn't exist, I think there
should be a way to extended system functionality in a secure way, and I
don't think poor
That activity manager API was never intended to be used to poll the state,
it was there to provide debugging information.
I regret making it part of the SDK. There is really no good use of it for
regular applications, and lots of bad uses.
I do agree that having facilities to provide restricted
Glad to see a response, thanks.
While I think a platform feature vs an API set developers can access is
better than nothing, it's also much too restrictive. What I mean by this is
that parents and admins want to buy the devices they want to buy -- and
still have the ability to lock them down.
I just realized I may have misunderstood your response. If Android provided
parental controls, again, it would be better than nothing, but very much
too limiting.
The main point in my list there is this: People want to choose their
filtering / parental controls / enterprise control solution,
On Fri, Jul 27, 2012 at 3:26 PM, Bryan Ashby nuskoo...@gmail.com wrote:
Glad to see a response, thanks.
While I think a platform feature vs an API set developers can access is
better than nothing, it's also much too restrictive. What I mean by this is
that parents and admins want to buy the
23 matches
Mail list logo
