Application transplantation between BREW mobile phones of different brands

In view of the hardware differences of mobile phones, adaptive methods can be used in applications to reduce the workload of application transplantation. Each mobile phone has its own type ID-the platform ID. If the application dynamically loads resources based on the platform ID and the corresponding hardware information, it can achieve zero workload migration for some applications. One way to obtain the mobile phone platform identity and related hardware information is to use ishell_getdeviceinfo () and ishell_getdeviceinfoex ().

Ishell_getdeviceinfo () can be used to query information about the performance of the mobile phone at the aee layer, such as the supported Ram capacity, screen display, and other projects. To obtain the dwnetlinger and dwsleepdefer values in the aeedeviceinfo structure, before calling this function, wstructsize must be equal to sizeof (aeedeviceinfo ).

Ishell_getdeviceinfoex () is used to obtain specific information about the device (aeedeviceitem ). This function uses ID to specify the required information. When returned, it contains the corresponding information in the buffer. The meanings of these IDs are shown in Table 15-2.

ID
Description
 
Aee_deviceitem_chip_id
A string that identifies the chipset ID.
 
Aee_deviceitem_mobile_id
An ASCII string that identifies the mobile ID of a handheld device.
 
Aee_deviceitem_amr_vocoder_support
Whether the AMR (Adaptive multi-rate) Sound is supported
 
Aee_deviceitem_evrc_vocoder_support
Whether EVRC (Enhanced Variable Rate encoding) Audio is supported
 
Aee_deviceitem_is96_vocoder_support
No support for QCELP-IS96 (8 K) (Qualcomm code excitation linear predictive coding) Phonograph
 
Aee_deviceitem_is96a_vocoder_support
No support for QCELP-IS96A (8 K) (Qualcomm code excitation linear predictive coding) Phonograph
 
Aee_deviceitem_is733_vocoder_support
Support for QCELP-IS733 (Qualcomm code excitation linear prediction coding) acoustic
 
Aee_deviceitem_smv_vocoder_support
Whether the Enable mode is supported
 
Aee_deviceitem_sys_colors_disp1 aee_deviceitem_sys_colors_disp2 aee_deviceitem_sys_colors_disp3 aee_deviceitem_sys_colors_disp4
Returns the system color list associated with a specific display screen.
 
Aee_deviceitem_dispinfo1 aee_deviceitem_dispinfo2 aee_deviceitem_dispinfo3 aee_deviceitem_dispinfo4
Returns information about a specific display screen.
 
Aee_deviceitem_carrier_id
A uint32 value that identifies the carrier ID of the handheld device
 
Aee_deviceitem_sidhash
Returns a hash of the payment account of the handheld device. It can be used to determine whether a payment account has been changed, for example, when a Ruim card has been changed. Note that no specific account is returned, but the hash of an account string is returned.
 
Aee_devicestate_keys_pressed
Returns the value of the pressed button.
 
Aee_devicestate_flip_open
Returns true when the device is turned on. Otherwise, returns false.
 
Aee_devicestate_headphone_on
Returns true if the headset is enabled. Otherwise, returns false.
 
Aee_devicestate_keyguard_on
If the keyboard of the device is enabled, true is returned; otherwise, false is returned.
 
Aee_devicestate_speaker_on
Returns true if the speaker of the device is on; otherwise, returns false.
 
Aee_deviceitem_user
OEM defines the start point of a project
 

Table 15-2: specific device information that can be obtained using ishell_getdeviceinfoex ()

Based on the information in aeedeviceinfo and aeedeviceitem, the application can dynamically load resource files. Of course, the resource information can also be stored on the server, and the application obtains the resource data through network communication, so as to adapt an application to different mobile phones.

If some mobile phones do not support some interfaces, applications can determine whether the interfaces are successfully created to obtain the information. For example, if the memory is normal and the iposdet interface fails to be created, it is probably because the mobile phone does not support the location function. In this case, the application should not provide the location function, and thus become an LBS application that only supports browsing and querying.

If two mobile phones have different functions for the same interface (usually in iringermgr or iaddrbook), the application needs to do more work. For example, if a configuration file is used to define the domain in the address book or ringtone directory, the application reads the configuration file according to the mobile phone information at startup, in this way, we can further make up for the differences between mobile phones and achieve better transplantation.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/wireless_com/archive/2010/11/02/5981424.aspx