Persistent applications

[Ubuntu guy]

Hi,

I was hoping to have a persistent app using a manifest option
( android:persistent=["true"] ), it has a service and an activity.

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.


However, i noticed that as soon as i moved it to background,
the oom value for the process moved from 0 to 10.
Wouldn't this make my app vulnerable to memory killer? If so, how
does the framework guarantee that my app remains running at all times?

[sudhir]

Even if the persistent app. is killed it will be spawned immediately.

[Dianne Hackborn]

You can only use this if your app is installed on the system image.

--
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.

[Ubuntu guy]

Thanks for the clarification, just verified oom score of persistent
system apps, being -12.
It would be nice for the documentation to make it clear that it
doesn't help 3rd party apps.
(ignored even if it set or something like that)

> hack...@android.com

[Cesar]

Dianne Hackborn <hackbod@...> writes:

>
>
> You can only use this if your app is installed on the system image.
> On Wed, May 2, 2012 at 10:20 PM, Ubuntu guy
<sam...@yahoo.co.in> wrote:Hi,
>  I was hoping to have a persistent app using a manifest option
> ( android:persistent=["true"] ), it has a service and an activity.
> 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.
>          However, i noticed that as soon as i moved it to background,
> the oom value for the process moved from 0 to 10.
>  Wouldn't this make my app vulnerable to memory killer? If so, how
> does the framework guarantee that my app remains running at all times?
> --
> 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-platform+unsubscribe
<at> googlegroups.com.

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

enginee...@android.comNote: 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.
>

Does the app actually have to be part of the system image or is it enough for it
to be signed with the system signature?

[Dianne Hackborn]

It has to be part of the system image.

It would be broken if it wasn't.  That means you could install an update, which would kill it, and that would no longer be a persistent process.

Please stay away from this unless you are writing very core system code that must be running forever from before any third party apps.  That is what this is for, nothing else.

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

[Dianne Hackborn]

On Mon, Jul 2, 2012 at 1:32 PM, Cesar <cesar.m...@gmail.com> wrote:

So, if I understand correctly, this means that the Phone app cannot be upgraded without replacing the system image. Is that right?

The "phone" application (which is actually the thing that talks to the RIL and implements all of the platform's core low-level telephony bits) can only be upgraded through a system update.  Like many other things.  Like, uh, the framework.  And the phone app is actually implementing the phone parts of the framework.

[Cesar]

Thanks again. I understand that the phone app is a special case. It seems to behave more like a service, but it is defined as an application. I have actually spent quite a bit of time trying to understand the telephony framework, all the way down to the "vendor ril" layer.
 
I guess I just want to make sure that if I am stupid enough to implement my own persistent app, the following would be true:
(1) The app will need to be included in the system image.
(2) Since the app cannot be killed (it will restart immediately), it will not be possible to update the app using the "normal" app update procedure, i.e. the system image will need to be rebuilt.

[ron.k...@gmail.com]

Sorry to revive old topic, but I'm encountering same issues with my app:

System-privileged app having android:persistent=true fails to update properly, crashes.

What I'm seeing is that the system installs the update while the current (system-installed) version is still running. During the update the system does not stop the process (either attempts to stop and fails or doesn't try at all). After the update completes, the app seems to undergo a "restart" - I'm seeing components being initialized such as Application::onCreate() being called. But this is happening on same process as before the update!

Consequently (upon launching some activity of the app), the app crashes with "weird" exceptions such as failing to cast class to itself:

Caused by: java.lang.ClassCastException: com.XX.YY.ZZ.ClassName cannot be cast to com.XX.YY.ZZ.ClassName

While investigating, I'm seeing the ClassLoader used after the update does not refer to the the path of the updated APK, but remains pointing to the path of the original version:

Expected classloader: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.app.package-1/base.apk"],nativeLibraryDirectories=[/data/app/com.app.package-1/lib/x86_64, /data/app/com.app.package-1/base.apk!/lib/x86_64, /system/lib64, /vendor/lib64]]]

Actual classloader: dalvik.system.PathClassLoader[DexPathList[[zip file "/system/priv-app/Appname.apk"],nativeLibraryDirectories=[/system/lib64/Start, /system/priv-app/Appname.apk!/lib/x86_64, /system/lib64, /vendor/lib64, /system/lib64, /vendor/lib64]]]

I'm assuming this is a result of not restarting the process during update.

Is it confirmed that there is not way to update such app via the normal update procedure (e.g. posting newer version on Google Play)? Or is there a way to update an app with persistent=true?