D-Bus support in future releases/version

[Jay]

Hi,

Pardon in case this is not an appropriate post for this forum. If not,
could someone pl suggest a more suitable forum/discussion group.

Does anyone know if DBus would continue to be supported in future
(upcoming) releases of Android? Or I should instead plan to develop
using Binder and not count on DBus if it will be removed or
unsupported in future.

I am kinda constrained to use native apps and was looking for possible
options to do IPC/RPC. This is a followup to my earlier post (http://
groups.google.com/group/android-ndk/browse_thread/thread/
d5099546b35c91f3) asking about Binder support in native apps where I
learnt it is not available via the NDK (and hence not for native
apps).

thanks
Jay

[Dianne Hackborn]

Neither Binder nor DBus are available as NDK APIs.  You can use Binder through JNI to the Java language APIs.  You can use other IPC mechanisms directly in the NDK -- pipes, shared memory areas, etc.

I would *strongly* recommend implementing IPC in Java.  There is a lot of support you need to really do this right.  For example, you need another process.  How do you get that?  The correct way to do this is to declare a service in your manifest that is specified to run in another process, and then use Context.bindService() to attach to it.  Likewise if you want to implement interactions between applications, you declare content providers, services, or broadcast receivers to do this.  These are all Java language APIs.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?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.

[Jay]

Thanks for the informational response; it was useful.

I think I will go with your recommendation.

However I would like to understand one thing better; perhaps more out
of curiosity than anything. Pardon my naivity here.

I notice presence of dbus sources and it being used by bluez and wpa
supplicant. Given than DBus is not available as NDK apis, how does one
characterize this DBus usage as? Like is it more like "Use it at your
own risk"
Meaning is there some minimal std libc like services for any native
app to use even when it is not using NDK? What I am trying to get at
is so long as a native app/lib develops some capabilities while
strictly adhereing to the officially supported libraries, either just
bare libc and/or NDK APIs, and then makes them available to other
native apps, is it ok? Could one place the DBus implementation in such
category? What kinds of issues this might cause.

Note I am not questioning yr recommendation that doing IPC in Java is
better but wanted to know.

thanks
Jay

> 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.- Hide quoted text -
>
> - Show quoted text -

[alan]

bluez and wpa supplicant are part of the system and therefore are able to use private APIs as they know exactly which version of private libraries are on the phone. your application can only reliably use public APIs because you don't know what libraries or versions are available on a user's phone

[Olivier Guilyardi]

On 05/16/2011 10:54 PM, Jay wrote:
> Note I am not questioning yr recommendation that doing IPC in Java is
> better but wanted to know.

You don't need Java for IPC. There many ways to do this natively, using sockets,
shared memory and such, as you would on a plain Linux system.

--
Olivier

[David Turner]

On Mon, May 16, 2011 at 10:54 PM, Jay <Jayan...@hotmail.com> wrote:

Thanks for the informational response; it was useful.

I think I will go with your recommendation.

However I would like to understand one thing better; perhaps more out
of curiosity than anything. Pardon my naivity here.

I notice presence of dbus sources and it being used by bluez and wpa
supplicant. Given than DBus is not available as NDK apis, how does one
characterize this DBus usage as? Like is it more like "Use it at your
own risk"

These are just implementation details of the Bluetooth and Wifi stack used in the AOSP source tree.

OEMs are generally not shy about replacing bluez or wpa_supplicant with something else, which means

there is absolutely no guarantee that DBus is going to be on every device. Heck, we could even decide to

remove it from the AOSP source tree in the future if we come up with something better and don't need it

anymore.

So in a nutshell, it's not "use at your own risk", but rather "it will break randomly so maybe you shouldn't lose too much of your time on this".