Can "android:persistent=true" be supported to all kind of application?

[YongHak Park]

I read following notification from developer site.

"android:persistent
Whether or not the application should remain running at all times —
"true" if it should, and "false" if not. The default value is "false".
Applications should not normally set this flag; persistence mode is
intended only for certain system applications."

What I want to know is.. "android:persistent" is supported to any
application - preloaded app, downloaded app and so on..

And..
If an application sets the value as true and it is killed by other
application,
dose it restart automatically? or it receives a specific broadcast
intent to decide restart or not.


Can anyone tell me more information how "android:persistent" works
exactly?

thanks..

[AppCoder]

Works for preloaded applications, doesn't work for downloaded
applications. To achieve similar functionality for downloaded
applications use:

http://developer.android.com/reference/android/app/Service.html#startForeground%28int,%20android.app.Notification%29

To make 1 apk that "does the right thing" (in this case, puts up
the notification if downloaded, or if it's preloaded let the property
android:persistent take care of it) do something like:

ApplicationInfo appInfo =
getApplicationContext().getApplicationInfo();
if (((appInfo.flags & ApplicationInfo.FLAG_SYSTEM) == 0) {
/* make a notification and put use startForeground
}

Expect "you shouldn't need to run all the time, this is bad for the
battery and make the users hate you" responses soon. If you
can, follow the life cycle rules for a service and save/restore your
state in the right on* methods.

[mike zhu]

you can have a try to kill application setting it true with "adb shell kill -10 pidof process_name", then see whether your app would be restarted.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Dianne Hackborn]

You really should not be using this in anything except core platform code.  In the entire Android platform there is exactly one thing that uses it: the phone app, which is the thing that maintains the connection with the RIL and displays the incoming call UI and such.  (That is, very critical code for a phone.)

(Actually I take that back, I believe that there is now another persistent process, SystemUI, which is the thing that shows the status bar and other well system UI.  Also pretty critical.)

Using this means that the overall platform has much less flexibility dealing with  low memory situations.  Unless you are writing code at the level of core platform code -- where you are taking great care in memory use, avoiding memory leaks, and generally not writing like an application -- I really urge you to not use this facility.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[AppCoder]

On Jun 25, 3:11 am, Dianne Hackborn <hack...@android.com> wrote:
> You really should not be using this in anything except core platform code.
>  In the entire Android platform there is exactly one thing that uses it: the
> phone app, which is the thing that maintains the connection with the RIL and
> displays the incoming call UI and such.  (That is, very critical code for a
> phone.)
>
> (Actually I take that back, I believe that there is now another persistent
> process, SystemUI, which is the thing that shows the status bar and other
> well system UI.  Also pretty critical.)

And the NfcService, and I seem to find something with persistent=true
from com.android.providers.settings as well the phone app and SystemUI
on a stock nexus S.

Granted, it sort of pales next to the 70 or so native/root/system
level
processes, but there seem to be a bunch of other things running on an
android phone that want to run all the time (and I'll admit, not much
can
be done about dhcpd and the various mount tasks which are linux
required) but to say that things like:

media 132 1 22828 4508 ffffffff afd0b77c S /system/bin/
mediaserver
bluetooth 133 1 1264 700 c00cd3d0 afd0c63c S /system/bin/
dbus-daemon
root 134 1 824 312 c037cdd4 afd0b4dc S /system/bin/
installd
keystore 135 1 1752 432 c02e169c afd0c16c S /system/bin/
keystore
gps 136 1 15488 5316 ffffffff afd0b8c4 S /system/vendor/
bin/gpsd

aren't running with the same sort of "I don't want to be killed off
and
restarted" permissions granted by persistent=true is somewhat
misleading.

Not that I'm saying Angry Birds or "Joe Bob's wallpaper app" need this
protection, but there are more than 2 tasks running on an android
phone
that seem to need it. (I'm not sure if the NfcService is an
aberration and
the general solution should be write a native bin <something>d and
have
java classes talk to it, or if implementing more system services in
java
is the goal.)

[Dianne Hackborn]

On Sat, Jun 25, 2011 at 9:00 AM, AppCoder <dan.s...@gmail.com> wrote:

And the NfcService, and I seem to find something with persistent=true

from com.android.providers.settings as well the phone app and SystemUI
on a stock nexus S.

True, NfcService was added as well.  Settings isn't a separate process, it runs in the system process.

 

Granted, it sort of pales next to the 70 or so native/root/system
level
processes, but there seem to be a bunch of other things running on an
android phone that want to run all the time (and I'll admit, not much
can
be done about dhcpd and the various mount tasks which are linux
required) but to say that things like:

media     132   1     22828  4508  ffffffff afd0b77c S /system/bin/
mediaserver
bluetooth 133   1     1264   700   c00cd3d0 afd0c63c S /system/bin/
dbus-daemon
root      134   1     824    312   c037cdd4 afd0b4dc S /system/bin/
installd
keystore  135   1     1752   432   c02e169c afd0c16c S /system/bin/
keystore
gps       136   1     15488  5316  ffffffff afd0b8c4 S /system/vendor/
bin/gpsd

aren't running with the same sort of "I don't want to be killed off
and
restarted" permissions granted by persistent=true is somewhat
misleading.

None of those things are even Dalvik applications or .apks.  My comment about not using android:persistent for things unless they are core system code with all of the caveats about how you need to manage them?  The things you list above are even more system-level than that.

For example, if you do a "procrank" you will see that this stuff is MUCH smaller than any .apk you are going to find, because they are all written in native code with no Dalvik interpreter, and most are written in pure C.

Not that I'm saying Angry Birds or "Joe Bob's wallpaper app" need this
protection, but there are more than 2 tasks running on an android
phone
that seem to need it.  (I'm not sure if the NfcService is an
aberration and
the general solution should be write a native bin <something>d and
have
java classes talk to it, or if implementing more system services in
java
is the goal.)

Okay, you got me, there are 3 .apks actually using android:persistent in all of the platform and its apps. :p

Now let's go back to the original question, asking if android:persistent is available to third party *apps*.  We aren't talking about low-level daemon services here, so there is no reason to bring them up.

So let me go back to my same point -- don't use android:persistent unless you are writing core system code and are thinking about things that way instead of an app developer, paying close attention to memory use and leaks and such.  Abusing this facility can result in the system not running well because when it gets low on memory it has no options for dealing with the situation.

Also I would *strongly* recommend against someone writing code that switches between android:persistent and startForeground() depending on whether they are pre-installed on the system image.  This is going to make your code a lot more difficult to maintain, as you now need to deal with two fairly different environments.

This is also most likely an abuse of startForeground(), since android:persistent is explicitly for things that need to be running forever, from the boot of the system until shutdown; if you try to do the same thing with startForeground() you are forcing a notification in the user's face forever while your app is installed, which is rude and likely to get you uninstalled.

[AppCoder]

> Okay, you got me, there are 3 .apks actually using android:persistent in all
> of the platform and its apps. :p

Just saying I saw 4 PIDs with persistent=true, and somebody made a
design decision that said "all the dalvik VM overhead is worth it to
have
the tools available there" for the nfc instead of making small tight C
code.
And while it may be just 3 .apks (putting aside that having the
system.apk
start two PIDs to get that permission might indicate there are 4 long
running
operations that do better with the dalvik VM heaviness than being
written in
C), the other view is that 3 out of 60 or so .apks to run the phone
(5%) need
android:persistent, and 3rd party developers can lump it with
"difficult to
maintain" and "rude" solutions.

> Now let's go back to the original question, asking if android:persistent is
> available to third party *apps*. We aren't talking about low-level daemon
> services here, so there is no reason to bring them up.

I don't have a good distinction between third "party *apps*" and "low-
level
daemons" (I think the Nfc process has blurred that), and 3rd party
apps
that want to do something like bring up a VPN and keep it around,
or validating that user has the a CAC card plugged into the usb port
to browse some protected internal network, or gather statistics on
device use a'la com.cyangoenmod.stats package, or an equalizer
app for somebody that wants to pump up the bass all seem like
valid things the android platform should support without having to
do something that is "rude and likely to get you uninstalled".

> So let me go back to my same point -- don't use android:persistent unless
> you are writing core system code and are thinking about things that way
> instead of an app developer, paying close attention to memory use and leaks

> and such. .........................................................................................................

I think app developers should be encouraged to pay close attention to
memory
use and leaks in all cases.

> ...................... Abusing this facility can result in the system not running well

> because when it gets low on memory it has no options for dealing with the
> situation.

Even not (ab)using it an application that has memory leaks will
degrade performance
of other applications which should have been able to hang about in the
background
and get swapped in fast (and not have the font cache flushed out once
the leaky
foreground app has gotten other well behaved apps killed.)

> Also I would *strongly* recommend against someone writing code that switches
> between android:persistent and startForeground() depending on whether they
> are pre-installed on the system image. This is going to make your code a
> lot more difficult to maintain, as you now need to deal with two fairly
> different environments.

What would be the best place to start looking at documentation that
could help
distinguish what these difficulties might be and distinctions between
the two
environments are (or do you have a quick top 5 that folks should watch
out
for?)

> This is also most likely an abuse of startForeground(), since
> android:persistent is explicitly for things that need to be running forever,
> from the boot of the system until shutdown; if you try to do the same thing
> with startForeground() you are forcing a notification in the user's face
> forever while your app is installed, which is rude and likely to get you
> uninstalled.

There is no other alternative if you can't get preloaded on the ROM
aside
from startForeground(), correct? (I'd prefer to not have to write an
application
that is "rude" but I think that's all that I'm allowed to do.)

Dan Schmitt

[Alex Blanco]

Diane:

I am trying to write a system level app for my employer, and was running into the situation where when the app gets killed, its process gets restarted, but there is no intent sent when that happens.  So the process is running, but no app code got started.  What should trigger a system app code in this case?

thanks.

[Dianne Hackborn]

That doesn't really make sense.  android:persistent just means to keep the process running.  If you want something else going on in it, you need to start it.  Like say startActivity().  Or you can implement a custom Application that does whatever you want when the process is brought up.

--

You received this message because you are subscribed to the Google Groups "android-platform" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/53_B3-1tq8sJ.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Dianne Hackborn]

I think I just answered this question...?

On Mon, Jul 2, 2012 at 10:01 AM, Cesar <cesar.m...@gmail.com> wrote:

I know this is an old thread, but I have a related question.

I understand and appreciate your warnings about use of android.persistent="true". That being said, I still need to do it. So my question is one of implementation.

In order to make an app persistent, does it need to be compiled into the platform image, or can it be a downloaded app (as long as it has the platform signature)?
Thanks

To post to this group, send email to android-platform@googlegroups.com.
To unsubscribe from this group, send email to android-platform+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/iBKXvtsh2C4J.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Karim Yaghmour]

On 11-06-23 11:10 PM, YongHak Park wrote:
> If an application sets the value as true and it is killed by other
> application,
> dose it restart automatically? or it receives a specific broadcast
> intent to decide restart or not.

If you kill it or it dies, it'll get restarted automagically.

--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour

[Karim Yaghmour]

Hi Dianne,

Sorry to "revive" this, but can you point me to the code/mechanism in the AOSP that discriminates against non-platform apps making use of the "persistent" flag? IOW, where are we stopping market apps using "persistent=true" from getting installed and/or running?

Thanks,

-- 
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour

On 12-07-03 09:45 AM, Dianne Hackborn wrote:

I think I just answered this question...?

On Mon, Jul 2, 2012 at 10:01 AM, Cesar <cesar.m...@gmail.com> wrote:

I know this is an old thread, but I have a related question.

I understand and appreciate your warnings about use of android.persistent="true". That being said, I still need to do it. So my question is one of implementation.

In order to make an app persistent, does it need to be compiled into the platform image, or can it be a downloaded app (as long as it has the platform signature)?
Thanks

On Saturday, June 25, 2011 3:11:52 AM UTC-4, Dianne Hackborn wrote:

You really should not be using this in anything except core platform code. �In the entire Android platform there is exactly one thing that uses it: the phone app, which is the thing that maintains the connection with the RIL and displays the incoming call UI and such. �(That is, very critical code for a phone.)

(Actually I take that back, I believe that there is now another persistent process, SystemUI, which is the thing that shows the status bar and other well system UI. �Also pretty critical.)

Using this means that the overall platform has much less flexibility dealing with �low memory situations. �Unless you are writing code at the level of core platform code -- where you are taking great care in memory use, avoiding memory leaks, and generally not writing like an application -- I really urge you to not use this facility.

On Fri, Jun 24, 2011 at 6:51 AM, AppCoder <dan.s...@gmail.com> wrote:

Works for preloaded applications, doesn't work for downloaded

applications. �To achieve similar functionality for downloaded

applications use:

http://developer.android.com/reference/android/app/Service.html#startForeground%28int,%20android.app.Notification%29

To make 1 apk that "does the right thing" (in this case, puts up
the notification if downloaded, or if it's preloaded let the property
android:persistent take care of it) do something like:

ApplicationInfo appInfo =
getApplicationContext().getApplicationInfo();
if (((appInfo.flags & ApplicationInfo.FLAG_SYSTEM) == 0) {

� � /* make a notification and put use startForeground

}

Expect "you shouldn't need to run all the time, this is bad for the

battery and make the users hate you" responses soon. � If you

can, follow the life cycle rules for a service and save/restore your
state in the right on* methods.

On Jun 23, 11:10�pm, YongHak Park <gdn...@gmail.com> wrote:
> I read following notification from developer site.
>
> "android:persistent

> Whether or not the application should remain running at all times �

> "true" if it should, and "false" if not. The default value is "false".
> Applications should not normally set this flag; persistence mode is
> intended only for certain system applications."
>
> What I want to know is.. "android:persistent" is supported to any
> application - preloaded app, downloaded app and so on..
>
> And..
> If an application sets the value as true and it is killed by other
> application,
> dose it restart automatically? or it receives a specific broadcast
> intent to decide restart or not.
>
> Can anyone tell me more information how "android:persistent" works
> exactly?
>
> thanks..

--
You received this message because you are subscribed to the Google Groups "android-platform" group.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.� All such questions should be posted on public forums, where I and others can see and answer them.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-platform/-/iBKXvtsh2C4J.

To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.� All such questions should be posted on public forums, where I and others can see and answer them.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.

[Ubuntu guy]

Its disabled by default for all apps and enabled only for system apps
(based on persistent flag's value)

ProcessRecord.java

ProcessRecord(BatteryStatsImpl.Uid.Proc _batteryStats,
IApplicationThread _thread,
ApplicationInfo _info, String _processName, int _uid) {
...
persistent = false;
...

}

On Nov 13, 1:22 am, Karim Yaghmour <karim.yaghm...@opersys.com> wrote:
> Hi Dianne,
>
> Sorry to "revive" this, but can you point me to the code/mechanism in
> the AOSP that discriminates against non-platform apps making use of the
> "persistent" flag? IOW, where are we stopping market apps using
> "persistent=true" from getting installed and/or running?
>
> Thanks,
>
> --
> Karim Yaghmour

> CEO - Opersys inc. /www.opersys.comhttp://twitter.com/karimyaghmour

>
> On 12-07-03 09:45 AM, Dianne Hackborn wrote:
>
>
>
>
>
>
>
> > I think I just answered this question...?
>

> > On Mon, Jul 2, 2012 at 10:01 AM, Cesar <cesar.maior...@gmail.com
> > <mailto:cesar.maior...@gmail.com>> wrote:
>
> >     I know this is an old thread, but I have a related question.
>
> >     I understand and appreciate your warnings about use of
> >     android.persistent="true". That being said, I still need to do it.
> >     So my question is one of implementation.
>
> >     In order to make an app persistent, does it need to be compiled
> >     into the platform image, or can it be a downloaded app (as long as
> >     it has the platform signature)?
> >     Thanks
>
> >     On Saturday, June 25, 2011 3:11:52 AM UTC-4, Dianne Hackborn wrote:
>
> >         You really should not be using this in anything except core

> >         platform code.  In the entire Android platform there is

> >         exactly one thing that uses it: the phone app, which is the
> >         thing that maintains the connection with the RIL and displays

> >         the incoming call UI and such.  (That is, very critical code

> >         for a phone.)
>
> >         (Actually I take that back, I believe that there is now
> >         another persistent process, SystemUI, which is the thing that

> >         shows the status bar and other well system UI.  Also pretty

> >         critical.)
>
> >         Using this means that the overall platform has much less

> >         flexibility dealing with  low memory situations.  Unless you

> >         are writing code at the level of core platform code -- where
> >         you are taking great care in memory use, avoiding memory
> >         leaks, and generally not writing like an application -- I
> >         really urge you to not use this facility.
>
> >         On Fri, Jun 24, 2011 at 6:51 AM, AppCoder

> >         <dan.schm...@gmail.com <mailto:dan.schm...@gmail.com>> wrote:
>
> >             Works for preloaded applications, doesn't work for downloaded

> >             applications.  To achieve similar functionality for downloaded
> >             applications use:
>
> >            http://developer.android.com/reference/android/app/Service.html#start...

>
> >             To make 1 apk that "does the right thing" (in this case,
> >             puts up
> >             the notification if downloaded, or if it's preloaded let
> >             the property
> >             android:persistent take care of it) do something like:
>
> >             ApplicationInfo appInfo =
> >             getApplicationContext().getApplicationInfo();
> >             if (((appInfo.flags & ApplicationInfo.FLAG_SYSTEM) == 0) {

> >                 /* make a notification and put use startForeground
> >             }
>
> >             Expect "you shouldn't need to run all the time, this is
> >             bad for the

> >             battery and make the users hate you" responses soon.   If you

> >             can, follow the life cycle rules for a service and
> >             save/restore your
> >             state in the right on* methods.
>

> >             <mailto:android-...@googlegroups.com>.

> >             To unsubscribe from this group, send email to
> >             android-platfo...@googlegroups.com

> >             <mailto:android-platform%2Bunsu...@googlegroups.com>.

> >             For more options, visit this group at
> >            http://groups.google.com/group/android-platform?hl=en.
>
> >         --
> >         Dianne Hackborn
> >         Android framework engineer

> >         hack...@android.com <mailto:hack...@android.com>

>
> >         Note: please don't send private questions to me, as I don't
> >         have time to provide private support, and so won't reply to

> >         such e-mails.  All such questions should be posted on public

> >         forums, where I and others can see and answer them.
>
> >     --
> >     You received this message because you are subscribed to the Google
> >     Groups "android-platform" group.
> >     To view this discussion on the web visit
> >    https://groups.google.com/d/msg/android-platform/-/iBKXvtsh2C4J.
>
> >     To post to this group, send email to
> >     android-...@googlegroups.com

> >     <mailto:android-...@googlegroups.com>.

> >     To unsubscribe from this group, send email to
> >     android-platfo...@googlegroups.com

> >     <mailto:android-platform%2Bunsu...@googlegroups.com>.

> >     For more options, visit this group at
> >    http://groups.google.com/group/android-platform?hl=en.
>
> > --
> > Dianne Hackborn
> > Android framework engineer

> > hack...@android.com <mailto:hack...@android.com>

>
> > Note: please don't send private questions to me, as I don't have time

> > to provide private support, and so won't reply to such e-mails.  All

[Karim Yaghmour]

Thx, but that still doesn't explain it all. Here's from
PackageManagerService.java:
public List<ApplicationInfo> getPersistentApplications(int flags) {
ArrayList<ApplicationInfo> finalList = new
ArrayList<ApplicationInfo>();

synchronized (mPackages) {
Iterator<PackageParser.Package> i =
mPackages.values().iterator();
while (i.hasNext()) {
PackageParser.Package p = i.next();
if (p.applicationInfo != null
&&
(p.applicationInfo.flags&ApplicationInfo.FLAG_PERSISTENT) != 0
&& (!mSafeMode || isSystemApp(p))) {

finalList.add(PackageParser.generateApplicationInfo(p, flags));
}
}
}

The "if" statement seems to check isSystemApp() but then again, there's
the !mSafeMode in an OR statement with it and since safe mode seems to
be disabled by default it would seem that all apps, whether system or
not, would pass this test. Then again, I might be looking at the wrong
snippet or the wrong codepath. Let me know what you see on your side.

Thanks,

--
Karim Yaghmour

CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour

>>> all times �

[Haisea]

When install an application, parse for ApplicationInfo, it has to be a system app to has the flag ApplicationInfo.FLAG_PERSISTENT
android.content.pm.PackageParser.parseApplication(Package, Resources, XmlPullParser, AttributeSet, int, String[])
        if ((flags&PARSE_IS_SYSTEM) != 0) {
            if (sa.getBoolean(
                    com.android.internal.R.styleable.AndroidManifestApplication_persistent,
                    false)) {
                ai.flags |= ApplicationInfo.FLAG_PERSISTENT;

>>>             all times �

[David Castillo Fuentes]

Hi Dianne,

Sorry for posting this too late, my team by mistake set the flag persistent=TRUE, and that is actually causing us crashes when we want to upgrade the application because the old app process is not killed during the upgrade process, the issues I'm getting is about resource not found exceptions and I need to make a force restart of the device to get the issues fixed. Is there a way to fix this issue by killing the app old process during the upgrade? Thanks a lot for your valuable feedback.