Hal Introdution: the existence of Hal (hardware action layer) aims to make the android framework and Linux
Device driver is separated. Upper-layer applications use Dalvik Vm and core services [runtime] (such as sensor
Service, camera service, etc.) to load the dynamic library file (*. So), here the so file refers to the implementation of Hal, Core
The service calls the interface provided by the Hal layer through the JNI interface, so that the Android Application can perform hardware operations. In the android source code, Hal is mainly implemented under the hardware/directory. The old and new implementation versions coexist, the old Hal implementation is through the JNI layer direct loading of dynamic link library, as shown in: Figure reference from: http://www.jollen.org/blog/
The new Hal implementation still communicates with the Linux Device Driver by loading the dynamic link library. However, libhardware shields the specific loading details. Each application is presented to the JNI layer using the Hal stub concept, A Hal stub is compiled into a dynamic link library file, as shown in the structure: Figure reference from: http://www.jollen.org/blog/ porting a new Hal implementation requires developers to write Hal module (stub ), upper-layer applications obtain Hal through libhardware
A series of callback functions (callback OPS) of module, which are directly related to the underlying Linux Device
Driver communication (usually through reading and writing device files ). Currently, Hal cannot be completely independent from hardware on the upper layer. It is often necessary for manufacturers to change the corresponding Runtime (service) implementation to add their own hardware devices, generally, the following Hal functions are required for Android phones:
- Camera
- GPS
- RIL
- WLAN
- Bluetooth
- Sensor
- Vibrator
Hal Implementation of GPS:
The GPS Hal instance discussed here adopts the old Hal implementation method. The main implementation code is as follows:
- Frameworks/base/location/* (client)
Frameworks/base/CORE/JNI/android_location_gpslocationprovider.cpp (JNI)
Frameworks/base/services/Java/COM/Android/serverlocationmanagerservice
. Java (service)
Hardware/libhardware_legacy/GPS/* (HAL)
First, we will introduce several important data structures:
/** Callback with location information. */
typedef void (* gps_location_callback)(GpsLocation* location);
/** Callback with status information. */
typedef void (* gps_status_callback)(GpsStatus* status);
/** Callback with SV status information. */
typedef void (* gps_sv_status_callback)(GpsSvStatus* sv_info);
/** GPS callback structure. */
typedef struct {
gps_location_callback location_cb;
gps_status_callback status_cb;
gps_sv_status_callback sv_status_cb;
} GpsCallbacks;
/* GPS interface */
Typedef
Struct
{
/**
* Opens the interface and provides the callback routines
* To the implemenation of this interface.
*/
Int
(
*
Init)
(
Gpscallbacks *
Callbacks)
;
/** Starts navigating. */
int
(
*
start)
(
void
)
;
/** Stops navigating. */
int
(
*
stop)
(
void
)
;
/** Closes the interface. */
void
(
*
cleanup)
(
void
)
;
/** Injects the current time. */
int
(
*
inject_time)
(
GpsUtcTime time
,
int64_t
timeReference,
int
uncertainty)
;
/** Injects current location from another location provider
* (typically cell ID).
* latitude and longitude are measured in degrees
* expected accuracy is measured in meters
*/
int
(
*
inject_location)
(
double
latitude,
double
longitude,
float
accuracy)
;
/**
* Specifies that the next call to start will not use the
* information defined in the flags. GPS_DELETE_ALL is passed for
* a cold start.
*/
void
(
*
delete_aiding_data)
(
GpsAidingData flags)
;
/**
* fix_frequency represents the time between fixes in seconds.
* Set fix_frequency to zero for a single-shot fix.
*/
int
(
*
set_position_mode)
(
GpsPositionMode mode,
int
fix_frequency)
;
/** Get a pointer to extension information. */
const
void
*
(
*
get_extension)
(
const
char
*
name)
;
}
GpsInterface;
|
The main task of implementing the Hal of GPS is to fill in
Gpsinterface structure, Android Application startup
When location_service is enabled, the system checks whether GPS applications are supported. If GPS is supported,
Gpsinterface structure, and then send GPS information to the framework layer through the callback function of the JNI layer. The call process is as follows:
After gpsinterface-> Start, enable the read thread to check the file status of the GPS device through epoll. If the data is received, the read data is from the. After the data is parsed, The gpsstatus is filled according to the parsed data,
Gpslocation and gpssvinfo structures, and then call the callback function passed in at the JNI layer during init. The service code automatically updates the GPS information.
