There's not "generic" data passing possible. You need a new HAL type and a new system service. Have a look at this blog for a detailed discussion:
http://www.opersys.com/blog/extending-android-hal

Hope this helps,

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


On 12-07-04 03:30 AM, Thomas Moore wrote:
Thanks for all the help with this! If I understand correctly, any new HAL module needs to follow the defined interfaces between it and the Android services. I was thinking of cases where a new HAL for a new kernel driver would provide functions outside of what is expected usually in the Android services and therefore would probably not work when being loaded (like a biosensor that would return data diffrently to the usual light, temperature, humidity etc. sensors). Would this require modifications to the system server/services code to be able to handle the new interfaces or is there a way to pass generic data from a device to an app to allow it to be processed there?

Thanks,
Tom

------------------------------------------------------------------------
Date: Wed, 4 Jul 2012 09:56:06 +0530
Subject: Re: [android-porting] Adding a new driver to HAL
From: sujai.ant...@gmail.com
To: barnaby1...@hotmail.com
CC: android-porting@googlegroups.com

So you want to have a new HAL loaded for an existing driver Or you would like both a new driver written and its matching HAL?

I think we could install .so's and call dlopen's from NDK but all of that requires the device to be 'rooted' I couldnt think of a way where what you say is possible on a non-rooted device that is already in market. (I am not an expert BTW so not sure other experts may chime in).

thanks
Sujai.

On Tue, Jul 3, 2012 at 8:31 PM, Thomas Moore <barnaby1...@hotmail.com <mailto:barnaby1...@hotmail.com>> wrote:

    Perfect, thanks! That is a really great writeup.

    So if I wanted to implement some kind of device that doesn't
    follow the supported behavior or interfaces expected by the upper
    services (say for example a sensor that is not one of the types
    used in Android), can I load in a hardware library and interact
    with my device directly through the HAL from within an
    application? Would this be done through the NDK maybe?
    It seems like some of the applications for custom kernels must do
    something like this as from what I can tell their modded drivers
    have additional functionality than is expected by Android.

    Thanks,
    Tom

    On Tuesday, 3 July 2012 11:52:28 UTC+10, Sujai Antony wrote:

        Hi,
        For the high level stuff, I made a brief post around this topic.
        Please see if you find it useful:
        
http://sujaiantony.wordpress.com/2012/06/25/an-android-101-hardware-and-hal/



        The ti-wiki page I mentioned in the Reference section has a
        nice step by step explanation on writing a new driver.

        thanks
        Sujai.
        sujaiantony.wordpress.com <http://sujaiantony.wordpress.com>

        On Mon, Jul 2, 2012 at 6:42 PM, Thomas Moore
        <barnaby1...@hotmail.com <mailto:barnaby1...@hotmail.com>> wrote:

            Hi guys,

            I have a fairly high level question about the steps to go
            through when adding a new device driver. From what I can
            tell, drivers consist of a kernel portion and then a
            shared library in the AOSP that gets used by the HAL. What
            I am
            wondering is how the HAL accesses the *.so libraries. If I
            was to add a new camera driver for example, do I need to
            name it libcamera so that it gets picked up by the HAL or
            is there a way to specify a new name and link it in?

            Also can applications access the hardware directly or do
            they always need to go through the higher level services?
            For example, if I were to add a new kind of sensor, do I
            need to somehow add this in to the sensor service to use
            the APIs in my app
            or can I do a dlopen() and interact with the hardware that
            way?

            Thanks!

-- unsubscribe: android-porting+unsubscr...@googlegroups.com
            <mailto:android-porting%2bunsubscr...@googlegroups.com>
            website: http://groups.google.com/group/android-porting



-- unsubscribe: android-porting+unsubscr...@googlegroups.com
    <mailto:android-porting%2bunsubscr...@googlegroups.com>
    website: http://groups.google.com/group/android-porting


--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting


--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting

Reply via email to