Extending Android's HAL

365 views
Skip to first unread message

Karim Yaghmour

unread,
Jul 9, 2012, 9:54:27 PM7/9/12
to android...@googlegroups.com

Given the recent questions/discussions regarding how the HAL works
and/or how to extend it, I've written a blog post that explains this:
http://www.opersys.com/blog/extending-android-hal

Have a look within the blog for links to the related github code.

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

Karim Yaghmour

unread,
Jul 11, 2012, 7:45:02 AM7/11/12
to alvin...@gmail.com, android...@googlegroups.com

[repost, got an error while sending]

You can do that if you control the entire device obviously.

However, apps are lifecycle managed (they will get stopped and restarted depending on the system's needs) and if you need to keep consistent hardware state across the system's lifetime, apps are the wrong way to go. The other thing you can do is set an app's "persistent" flag to "true" in its manifest. The Phone app also provides a system service in this fashion. In that case, the app will always be kept up by the activity manager. If you plan on making many devices based on Android, though, the HAL approach is the "clean" way to do it. It's, obviously, all a case-by-case thing. Also, if you put your hw-driving code in an app, you'll also need to make sure privileges are properly set to the /dev/ entry to allow access only to that app, the "system service" paradigm is much better adapted for that.

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

On 12-07-10 11:19 AM, Alvin Wong wrote:
Is it possible to only expose `/dev/foo` from the driver and in the app it opens `/dev/foo` to perform read/write operations? This seems to be saving a lot of work.

Karim Yaghmour嚙踝蕭 2012嚙羯7嚙踝蕭10嚙踝蕭P嚙踝蕭嚙瘦UTC+8嚙磕嚙踝蕭9嚙踝蕭54嚙踝蕭27嚙踝蕭g嚙瘩嚙瘦

Karim Yaghmour

unread,
Jul 11, 2012, 7:38:14 AM7/11/12
to umitu...@gmail.com, android...@googlegroups.com

Hi Umit,

Variables of the opersyshw_device_t type are actually used in com_android_server_OpersysService.cpp, as you can see above. There isn't, however, a global "opersyshw_dev" in that file to hold the value being played with. Instead, the pointer returned by hw_get_module() is passed up to the Java layer and reused when passed later to read() and write().

Sure, you can use this sample with its driver on an actual device, it'll work just fine. The actual module though ought to be in device/manufacturer/product instead of sdk/emulator.

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

On 12-07-10 11:29 AM, Ümit Uzun wrote:
Hi Karim,

I think there is forgotton "opersyshw_device_t* opersyshw_dev;" variable on com_android_server_OperSysService.cpp unless I don't understand the meaning of that?

Do you think we can use this sample on actual device? I think we should implement opersyshw.h on libhardware like emulator based implemantation or not?

Thanks in advance.

10 Temmuz 2012 Salı 04:54:27 UTC+3 tarihinde Karim Yaghmour yazdı:
Reply all
Reply to author
Forward
0 new messages