AbhinavDS / 0xdroid

Automatically exported from code.google.com/p/0xdroid
0 stars 1 forks source link

Implement generic WiFi HAL for Android #9

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
There is a primitive implementation for HAL in Android:
hardware/libhardware_legacy .  However, it is not complete and generic. In
the perspective of integrations, we should implement at least the following
functions in generic HAL: WLAN, BT, Camera, and GPS.

Original issue reported on code.google.com by jserv.tw@gmail.com on 12 Aug 2009 at 10:55

GoogleCodeExporter commented 8 years ago
code extracted from hardware/msm7k.

Original comment by jserv.tw@gmail.com on 18 Aug 2009 at 4:04

GoogleCodeExporter commented 8 years ago
Principle: Keep Interface Consistency

HAL attempts to support a consistent interface for upper applications.
That is, application programmers should be able to concentrate on
their business logic, rather than wrapping their heads around the
multitude of library or interprocess communication interfaces around.
Specifically, consistency is good paradigm, which is the reason we
ought to provide exactly one way to interact with the middleware.  The
term "middlewave" in HAL design document implies the existing
infrastructures provided by Android, Moblin, Qt Extended, etc.

While this may look like reinventing the wheel, it is an important
step towards middleware acceptance.  Instead,  we are actually reusing
the wheel and just covering the itchy details behind our IPC or
lightweight communications.

Existing serivces: bluez4, connman, wpa-supplicant, etc.

The middleware subsystems are split into higher-level services and
lower-level services. Initially, we look into the lower level
services:

 * Wireless communication: WiFi, Bluetooth, DVB (leverage to IP layer)
 * RIL
 * Camera
 * Audio
 * GPS
 * Power-aware interoperation
 * Other devices

The lowlevel device service manages peripheral control, such as
managing WiFi, BT, audio, LED/backlight brightness, vibrator,
accelerometer, and power control for devices without dedicated
controlling daemon. Also, it have to deal with charging notification
and RTC. On some systems it also forwards button events and notifies
about the system's idleness status.

There are two approaches to archive the integration:
 * Introduce specific PHDL (Platform Hardware Description Language)
for device oriented logic.  It is fairly straightforward to handle
BT-WLAN co-ex issues by the means of proper definitions and dedicated
state machine.  Finally, PHDL would generate the exact Java/C++ code
for Android.
 * Providing thin and flexible configurations for Android.  This can
be dynamically fit via system wide properties, such as setprop/getprop
in Android.

The events service processes rules that connects triggers via filters
to events. Depending on the rules, the events service glues to many
other subsystems.  Note that the events service is just a convenience
layer, full-fledged applications may handle most of these kind of
connections themselves.

Take WLAN-BT as example to demonstrate the laws of perspective.  We
ought to follow LWE (Linux Wireless Extension) as possible as we can,
and avoid the way to issue vendor specific low-level commands to
chipsets directly.  At least, we have to keep the API compatibility of
JNI (source: framework/base/core/jni).  Only dropped-in replacement
would be implemented in order to adapt our own HAL design.  The
essential program, wpa_supplicant, is heavily used by Android as the
WiFi communication manager.  The concept is simple and distinct.
However, the current JNI implementation lack system in Android's work.
 Both Java and JNI parts expose too much TI WLAN-BT specific
information.  So, we should directly let the information retrieve
actions pass by to the right place where our own thin HAL exists.

WLAN HAL requirement:
 * minimal/common LWE: mode of operation, ESSID ioctls, association
model, status report, range, Tx power
 * extended LWE standard: PM, WPA/WPA2, average quality (for user
space calibration)
 * vendor specific controls - for WLAN-BT co-ex, special power mode,
high performance operation mode, etc.

Original comment by jserv.tw@gmail.com on 24 Aug 2009 at 9:29

GoogleCodeExporter commented 8 years ago
To avoid duplicated work, I plan to check in my prototype work based on Donut 
instead of cupcake.  There are 
some changes made for WiFi already.

Original comment by jserv.tw@gmail.com on 16 Sep 2009 at 4:35

GoogleCodeExporter commented 8 years ago
ok, the latest release of beagle-cupcake was out, and we are migrating to 
beagle-donut.

Original comment by jserv.tw@gmail.com on 11 Oct 2009 at 6:18

GoogleCodeExporter commented 8 years ago
Depends on Issue 28:
    http://code.google.com/p/0xdroid/issues/detail?id=28

Original comment by jserv.tw@gmail.com on 22 Oct 2009 at 2:57

GoogleCodeExporter commented 8 years ago
Rebase to Eclair.  Minimize the work for WLAN-BT HAL.

Original comment by jserv.tw@gmail.com on 21 Dec 2009 at 12:29

GoogleCodeExporter commented 8 years ago
Let's merge the work done in android-x86 project.

Original comment by jserv.tw@gmail.com on 29 Apr 2010 at 1:55