Cling as Android Service

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Cling as Android Service

Hugo
Hi, Im new to Android and I have been reading the docs regarding how services work, specially how services can be in an application process or in their own process, and in the case that its in an application process it can interact with only its own process or with any process. I think I understand how it works but I would like if someone could confirm my understanding of how the Cling service works so I can be sure.

As far as I can see Cling should be created in the same process as the application trying to bind to it, because Cling can only interact within its own process. I have seen that there is no aidl file and therefore the Binder class is directly defined in AndroidUpnpServiceImp class. To not block the main UI thread, Cling creates its own threads defined in the AndroidUpnpServiceConfiguration class. Correct?

If the above is correct, it means that if two applications running in different processes want to have upnp functionality, each of them is going to run its own upnp stack, effectively having cling running twice in the same device. Correct? It would seem that Cling Service would be a candidate to run in its own process and have the applications access it through an AIDL interface. Is there are reason to not have it this way? Or is it just the case that nobody has contributed the code? It seems the only downfall would be not being able to configure Cling independently by each application since all the application share the same Cling process, but the advantage of having a shared upnp stack in terms of energy because of less memory, cpu and network use seems worth it. Also, is Cling 2.0 any different in this regards or are there any plans in this direction?

Thanks in advance,

Hugo
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Christian Bauer
Administrator


> Or is it just the case that nobody has contributed the code?

This.

Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

bergstr
This post was updated on .
In reply to this post by Hugo
Hugo wrote
It would seem that Cling Service would be a candidate to run in its own process and have the applications access it through an AIDL interface
but why? The likelihood that you will have 2 or more apps installed that run on top of cling is very small, because there are only a few to choose from, and they usually will all be performing the same tasks.
Hugo wrote
less memory, cpu and network
the savings would be mostly  in memory footprint, rather little in CPU or network.
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Hugo
bergstr wrote
Hugo wrote
It would seem that Cling Service would be a candidate to run in its own process and have the applications access it through an AIDL interface
but why? The likelihood that you will have 2 or more apps installed that run on top of cling is very small, because there are only a few to choose from, and they usually will all be performing the same tasks.
Hugo wrote
less memory, cpu and network
the savings would be mostly  in memory footprint, rather little in CPU or network.
Maybe, but because of the savings you get and conceptually, Cling should live in its own process.

I dont know how difficult it would be to implement though, since I dont know the Cling code, but I suspect its not easy, since you probably need to pass several different objects between the processes.
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Christian Bauer
Administrator
Cling has a very clean model API representing devices, services, etc. All those classes are immutable and serializable easily. Then there is the ControlPoint and Registry APIs you'd have to adapt, those are interfaces so I don't think it would be particularly difficult.
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

bergstr
In reply to this post by Hugo
Hugo wrote
Maybe, but because of the savings you get and conceptually, Cling should live in its own process.
you get savings if you have several apps using the service, which is, for the mentioned reasdons, very unlikely. Even then, the savings would be minimal (only the eventing), because each app would be performing its operations individually.

conceptually, a remote service is only needed if there is a strong interest to make it available to more than one app - which there isn't, as I explained. It is conceptually completely valid to use a local service. As long as there is no decision by Google to incorporate UPnP (in the form of Cling) into the core Android library, things are good as they are IMO - both from a conceptual and from a resource standpoint.

Anyway, I dont want to keep you from contributing this to Cling, if you are inclined to do so. I just think that there are many more interesting and useful challenges. Like, for example, creating a UPnP renderer service which could turn any android-powered device into a UPnP-controllable renderer (audio and/or video). I'd be willing to contribute code that implements gapless audio playback (a feature missing from many "high-end" network audio players nowadays).
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Hugo
bergstr wrote
As long as there is no decision by Google to incorporate UPnP (in the form of Cling) into the core Android library,
Here we agree, if Google were to adopt Cling as a core library it would need for sure to be a service that has its own process.

bergstr wrote
, I dont want to keep you from contributing this to Cling, if you are inclined to do so. I just think that there are many more interesting and useful challenges. Like, for example, creating a UPnP renderer service which could turn any android-powered device into a UPnP-controllable renderer (audio and/or video). I'd be willing to contribute code that implements gapless audio playback (a feature missing from many "high-end" network audio players nowadays).
Nope, I have enough on my own right now. I am working now on the media server part. I have some free time and media renderer is in the list of TODO, but I dont know how far I will get in the time I have. If I have time to implement that part you can be sure I will take you on your offer.
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

bergstr
Hugo wrote
Nope, I have enough on my own right now. I am working now on the media server part.
media server is even better - I already have a (local) renderer in my app, but I am missing a server ...
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

rooster
I work on an Android media player that uses Cling, and we have encountered several reasons why it would be beneficial to run cling in a separate process.

Android apps are limited to 24mb, 48mb, or 96mb of memory, depending on platform. It's not hard to push up against these limits when you are loading dynamic graphics, as they must be stored as full bitmaps in memory. Cling uses several megs of memory too. Moving to a separate process would alleviate memory use and cut back on OOM conditions.

Also, we moved our audio playback code to a separate process to ease the burden on the whole system. This allows Android to kill our main app and reclaim most of our memory footprint for other apps, while music continues to play. If the code to move cling to a separate process were available today, we would have used it to have both our main app and audio engine talk to a single cling instance.

This task has not been a high enough priority for us to take on, but it is certainly not without benefit.


On Tue, Jan 22, 2013 at 10:54 AM, bergstr [via Mailinglists] <[hidden email]> wrote:
Hugo wrote
Nope, I have enough on my own right now. I am working now on the media server part.
media server is even better - I already have a (local) renderer in my app, but I am missing a server ...


If you reply to this email, your message will be added to the discussion below:
http://mailinglists.945824.n3.nabble.com/Cling-as-Android-Service-tp4025463p4025473.html
To start a new topic under Cling users and developers, email [hidden email]
To unsubscribe from Cling users and developers, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Hugo
How many people is working on similar stuff?

Rooster and/or bergstr, if your implementation is Open Source maybe we should talk and see if we can save each other some time by joining forces.
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Christian Bauer
Administrator

There is a mediaserver module on the roadmap for 2.0 and I have some ideas how to implement it. A major step was the new servlet-based transport, so one webserver instance can be used for Cling and the actual HTTP streaming. But there is already an old topic about this, I will make it sticky again.

Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

lightglitch
Like I said in the other thread I'm also willing to help, although the time is not much now.

My long term goal was to replace my ps3ms with something with the same (or more) features but without the spaghetti code and extensible.
lightglitch a.k.a Mário Franco
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Michael Pujos
In reply to this post by rooster
rooster wrote
Android apps are limited to 24mb, 48mb, or 96mb of memory, depending on
platform. It's not hard to push up against these limits when you are
loading dynamic graphics, as they must be stored as full bitmaps in memory.
Cling uses several megs of memory too. Moving to a separate process would
alleviate memory use and cut back on OOM conditions.
With the large heap option that you can declare in the manifest, this is less and less a problem.
Bitmaps must be managed super carefully, otherwise it is OOM guaranteed after some time.
Leaks on orientation change are also a huge cause of OOM in apps as they can cause memory leaks if not careful.
Anyway, long are gone the days where max heap was 16Mb.
Separating an app bewteen multiple processes uses more memory and overhead, not less. And I think the Android docs discourages it.

rooster wrote
Also, we moved our audio playback code to a separate process to ease the
burden on the whole system. This allows Android to kill our main app and
reclaim most of our memory footprint for other apps, while music continues
to play. If the code to move cling to a separate process were available
today, we would have used it to have both our main app and audio engine
talk to a single cling instance.
There's no real need for multiple processes. A foreground service will run as long as possible. Unused memory will be reclaimed by the garbage collector.
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

Draško
In reply to this post by Hugo
I have been working on a custom MediaServer for android and would be interested in an exchange.
I am also thinking about the best way to use the UPnP stack in multiple apks. In my case it is not so complicated as the required common service would be the MediaServer itself, and not a generic UPnP stack. Other then that, I am having a "great fun" with the MediaStore content provider and it's problem to keep in sync with the file system changes. In desperation I have programmed a local media parser which is providing grouping by album, artist and genre. The next step would be to use the google music content provider - I already noticed almost non-existent info about that API.  
Reply | Threaded
Open this post in threaded view
|

Re: Cling as Android Service

gubatron
In reply to this post by Hugo
"but why? The likelihood that you will have 2 or more apps installed that run on top of cling is very small, because there are only a few to choose from, and they usually will all be performing the same tasks. "

FrostWire is using cling and it's installed on several millions of android devices, even though we're not in the hundreds of millions, still the likelihood is pretty high to have a secondary app using the library.

This is a really good idea (having it as a unique service), this service would have to implement some sort of ClientConfigurationManager so that every app that wants to use it can modify it. It's still unclear to me what would happen in terms of resource usage, the service would have to be pretty strict and you would end up in conflicts on which some app maybe wants to have more threads than what another app needs. It's a pretty tricky problem to solve.

For now I'm having issues with thread churn and garbage collection, If I limit the number of threads to say 64 threads (which is already quite a lot for a phone) I'm seeing a lot of concurrent GC on adb logcat, and cpu/battery consumption through the roof. Then If I use something similar to the default configuration which allows for Integer.MAX_INT threads, after a long time running the app it seems that some threads never finish and you end up having Out of memory errors.

I'll be looking at what those threads are doing to see If I can contribute a patch to reduce the GC issue.