If you are careful with the code (no leaks, no crashes, either its own thread or never taking long to perform work on a Handler in the main thread) you can have it run in the system process with little overhead. Just put it in an .apk, have the makefile sign it with the platform cert, and set the process and shared user id in the manifest to be the system. Have a look at the settings provider for an example. You can have it receive BOOT_COMPLETED to have your service start itself at boot so you don't need to modify anything in the system, or you can modify SystemServer.java to explicitly start it.
You can also modify SystemServer.java and add your code to services.jar to have it all built in... though the more changes you make to the platform code, the more work you will need to do to integrate your customizations to newer versions of the platform. On Fri, Jul 3, 2009 at 1:37 AM, Sun Jian <[email protected]> wrote: > Hi, > > We are porting Android to some device and a new service task needs to be > added. We are contemplating if we should make it a native daemon or a Java > service. From a software design perspective we'd like it to be Java, but we > are worried about the system overhead it adds (i.e. additional Dalvik > instance, etc.) The task is not going to be CPU-intensive (it should be > sleeping most of the time) and will use little RAM. It won't do much file IO > either. > > Does anybody have experience in this or have any data to share? > > Regards, > Sun Jian > > > > -- Dianne Hackborn Android framework engineer [email protected] 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. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
