Re: [PLUG] Android (was Blocking A Program From Running - android too)

[Jason Stelzer <jason.stelzer@gmail.com>]

On Sun, Oct 3, 2010 at 6:38 AM, Richard Freeman
<r-plug@thefreemanclan.net> wrote:
> Yup - in many ways Android today is where Windows 3.1 was 15 years ago.
> ÂYou can install an app, or you can not install an app, and if you do
> install an app it is up to the app writer to keep your battery from
> draining in 20 minutes, or from becoming slower than molasses.
>

What ways are you referring to? Please elaborate because I'm really
not seeing much at all in the way of analogy.

Dalvik is a register machine, not a stack machine.

Android is a fully preemptive multitasking system.

Android applications run as their own process. Each app is assigned
its own UID. Each app is running within its own VM. This means that in
addition to memory protection, you have VM isolation.

Given the level of isolation and that applications have NO IDEA about
anything other than their own little microcosm, they need a way to
communicate with the base OS. Gone are the days of unprotected memory
pages and writing all over someone else's stack.

The phone has essentially one button (home) and a touch pad that can
be used to interact with the running VM's. The other buttons
(settings, back and search) only become useful when there's an app to
interact with.

So how does an app start? When you click that icon, a message is sent
and an android.app.Application activity is brought to the foreground.
However, this is achieved via the event broadcasting subsystem. In
order to receive events, applications need to register what events
they can receive and be able to respond to them.

To illustrate the point... when you click a mailto: on a web page and
android offers to start one of the email programs, how do you think
that works? Right, it's through messaging. The applications that
respond with 'I am capable of responding to that kind of event' are
presented and you can pick which one to use (and check an 'always use
this' option in the process).

In android parlance, 'running' doesn't mean quite what it means on a
traditional PC.

http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle
http://developer.android.com/reference/android/content/BroadcastReceiver.html
http://developer.android.com/reference/android/content/Intent.html
http://thinkandroid.wordpress.com/2010/02/02/custom-intents-and-broadcasting-with-receivers/

> Android needs the ability for users to install software, but deny
> individual permissions. ÂIt needs the ability for users to control when
> services run, and with what priority. ÂIf you don't want a program to
> run in the background you should be able to disable that, but still use
> the program (it would launch the service when the program runs, and stop
> it when the program terminates).

Ok, so why do we need this ability? When you install a program, you
see what kinds of events it's going to receive and what type of
interactions with the system it's going to have. Beyond adding an
obnoxious popout menu of confusing 'settings', what does this offer
the majority of people?

Given the sheer number of people I've attempted to help on irc who
have completely mangled their /system folder and are really struggling
to figure out how to flash a simple sbf onto their device in order to
undo whatever unholy thing they've done to themselves I have very
little faith in the ability of the average user to act in a non
destructive manner. To me it seems that the more difficult it is to
navigate to some obscure button, the more perverse of a pleasure it is
for these very same inexperienced 'experts' to click on.

Equally importantly, as a developer why would I want to allow a
mechanism to break my application via mental confusion of the user
followed by a one star rating and a comment of 'this is teh crap --
duznt work lawl'?

There simply aren't enough support resources to protect the masses
from themselves.
http://en.wikipedia.org/wiki/Tragedy_of_the_commons

Granted, I haven't installed anywhere near a representative number of
apps in the market, but I generally go 2 days between charges and my
battery statistics speak for themselves. Most of my power goes to the
display, cell calls (and standby) and gps (in that order). Obviously
if I use things heavily, like gps or cell calls, my charge schedule
changes, but I have yet to have an unruly application completely
vampire my battery. I have yet to witness battery carnage that was not
self inflicted by jumping to conclusions and doing exactly the wrong
things. If I do experience a battery draining app, then I'd most
likely give the developer feedback and remove it. I have yet to find
something on the market that didn't have multiple competing
alternatives.

The android process model (from the perspective of an app running in
its own vm) is not the same as the linux (PC) process model and the
IPC mechanisms are completely different. Spinning up a dalvik vm on
demand isn't going to be the most responsive thing to do and I'm very
happy to not have a 'file extension' based mechanism for handling
things.

The listener model isn't pefect and I do wish that the 'manage
applications' panel had something besides 'running'.  Maybe a
'listening' and a 'running' tab would be nice.


> The best you can do right now is task killers - some will automatically
> keep killing processes that keep rising from the grave. ÂI hear they
> don't work so well in Android 2.2, and of course for whatever religious
> reason the various distro maintainers hate them (again, the win3.1
> mentality - just get everybody to write perfect apps).


The process life cycle for applications was changed significantly in
2.2. You simply cannot use task killer any longer. If you use task
killer, things keep 'coming back' because you are essentially calling
restart for the application and chewing battery in the process while
it re-initializes itself over and over. Pre-2.0 the memory and task
model was a bit different. A lot has changed rapidly moving to 2.2. My
comments are coming from 'current (2.2+) versions of android'. If you
are rooted, you could use things like Watchdog and Autostarts, but to
be honest I don't really see the point of them unless you're using
them to monitor an application you're working on. The expected
behavior of an application as well as its life cycle is well
documented and formalized. The behavior of an application on a linux
desktop is not. Trying to force android to behave like a pc is not
going to be a fun experience. But, if you're crazy enough to do it,
you could always fork things and see where it leads you.

http://developer.android.com/guide/topics/fundamentals.html#lcycles


-- 
J.



http://en.wikipedia.org/wiki/Register_machine
http://en.wikipedia.org/wiki/Stack_machine
http://www.dalvikvm.com/
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug