PocketMagic

May 12, 2009

Android C native development – take full control!

Filed under: Android, Research, Software, Windows Mobile — Tags: , , , — radumotisan @ 2:32 pm

A recent project I’ve been working on required Bluetooth programming on the Android.
Having a quick look over the latest 1.5 Android SDK, I could see that bluetooth support was missing. Later research pointed out that Google expressively excluded Bluetooth APIs blaming lack of time.

On the other hand, I’m not a big Java fan, to say the least. I find Java unfriendly, and I don’t like the look and feel of Java apps. Sorry, I prefer C/C++ since it provides better control and flexibility. So it’s time to start doing C/C++ native applications for the Google Android.

How run a C program on Google Android?
First thing I’ll show here, is to compile a simple C program for the Android.


#include <stdio.h>
int main()
{
printf("Hello Google Android world!\nwww.pocketmagic.net\n");
return 1;
}

Save this program as test.c. In the next steps we’ll be compiling this sample for the Google Android using gcc.

The tools

1. Download ubuntu linux. I currently use Desktop edition 9.04 in a virtual machine.
Attention: You’ll need to install Ubuntu on a machine with at least 1.5GB Ram, 10GB ext2 partition and 2GB Swap partition or you won’t be able to use this tutorial’s info (less then the minimum requirements will result in the impossibility of compiling the Android Code and we need that for the libraries).

2. Once Ubuntu is installed, download the Android Source code. On your linux box install additional packages:
$ sudo apt-get install git-core gnupg sun-java5-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev
$ sudo apt-get install valgrind
$ sudo apt-get install lib32readline5-dev

3. Install Repo
Create a ~/bin directory in your home directory, and check to be sure that this bin directory is in your path:

$ cd ~
$ mkdir bin
$ echo $PATH

To add it to the Path, you can use:

$ PATH=$PATH:~/bin/

Download the repo script and make sure it is executable:

$ curl http://android.git.kernel.org/repo >~/bin/repo
$ chmod a+x ~/bin/repo

4. Initializing a Repo client
Create an empty directory to hold your working files:

$ mkdir mydroid
$ cd mydroid

Run repo init to bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest:

$ repo init -u git://android.git.kernel.org/platform/manifest.git
$ repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake

When prompted, configure Repo with your real name and email address. If you plan to submit code, use an email address that is associated with a Google account.
A successful initialization will end with a message such as

repo initialized in /mydroid

Your client directory should now contain a .repo directory where files such as the manifest will be kept.

5. Getting the files
To pull down files to your working directory from the repositories as specified in the default manifest, run

$ repo sync

For more about repo sync and other Repo commands, see Using Repo and Git.
The Android source files will be located in your working directory under their project names.

6.Verifying Git Tags
Load the following public key into your GnuPG key database. The key is used to sign annotated tags that represent releases.

$ gpg --import

then paste the key(s) below, and press Control-D to end the input and process the keys. After importing the keys, you can verify any tag with

$ git tag -v tagname


key 9AB10E78: "The Android Open Source Project "

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV
lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7
8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD
u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z
wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq
/HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5
jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4
MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9
b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv
aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k
cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX
gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI
2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl
QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up
hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk
C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX
LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+
OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M
pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s
KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb
N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA
vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo
G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ
hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l
EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=
=Wi5D
-----END PGP PUBLIC KEY BLOCK-----

7. Building the code
The Android code contains a bug that hasn’t been solved up to the date of this article.
So before you start compiling the code, you’ll need a few modifications, or the build will fail (after consuming some of your time and patience). The error is:

external/qemu/sockets.c: In function 'sock_address_init_resolve':
external/qemu/sockets.c:637: error: 'EAI_NODATA' undeclared (first use
in this function)
external/qemu/sockets.c:637: error: (Each undeclared identifier is
reported only once
external/qemu/sockets.c:637: error: for each function it appears in.)
make: *** [out/host/linux-x86/obj/EXECUTABLES/emulator_intermediates/
sockets.o] Error 1

To fix this, before compiling the android code, open ~/mydroid/external/qemu/sockets.c and add

#define __USE_GNU

just before the #include <netdb.h>

Now you can build the files. Run make from within your working directory:

$ cd ~/mydroid
$ make

On my virtual machine running ubuntu, the build process took several hours. The host PC is a 2.6GHz P4.

Compile test.c with gcc for the Android platform
Android uses a simplified version of libc, called bionic. We need to compile using Android’s prebuilt cross-compiler arm-eabi-gcc, and use the bionic library on the phone.
The easy way to do this is to use the agcc perl wrapper. You can download the original file here, and modify

my $TOOLCHAIN = "$DROID/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1";

to

my $TOOLCHAIN = "$DROID/prebuilt/linux-x86/toolchain/arm-eabi-4.3.1";

Or download this updated version directly.

Copy agcc to your home directory, and chmod it:

chmod +x agcc

then set the PATH to the bionic libs and the agcc location:

$ PATH=$PATH:~/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin:~/:~/mydroid/

Now you can compile the test.c file:

agcc test.c -o test

Take the resulting test binary and upload it to your android using:

adb push test /data/local/test

Then run it:

adb shell
chmod 775 test
./test

See the pics for more details:

Next thing to do is to try to control the bluetooth functionality using native C code and the android toolchain.

More on native C apps for Android here.

Best regards,
Radu Motisan

September 11, 2008

Changing the Pocket PC screen resolution

Filed under: Windows Mobile — Tags: , , , — radumotisan @ 9:29 pm

While there are quite many nice alternatives for doing this and I would mention the RealVGA or the excellent OzVGA , here is another article discussing this subject. The reason for this is that it’s always good to know a little insight about the things we use.

To change the Pocket PC screen resolution, you only need a registry editor. If you are comfortable using little tools to do that it’s ok, but if you don’t have those around, or want to do it yourself with “bare hands”, there is an easy solution for this.

For my tests I’ve used an HTC Universal. Here is the original look of my today screen:

Those of you familiar with screen resolution changes, might know that this is the 192×192 “Logical resolution” or for my device, 640×480 pixels in landscape mode.

To change it, you need to open your registry editor and modify the keys LogicalPixelsX and LogicalPixelsY located under:

HKEY_LOCAL_MACHINE\Drivers\Display\GPE\

You can modify the default values to whatever suits you best. That’s right you can enter a wide range of values. After the new values are entered, you need to soft reset the device.

On my device, entering 384 for both LogicalPixelsX and LogicalPixelsY, equals a resolution of 320×240 in landscape mode. Here is a screenshot with my registry editor, and then with the pocket pc new resolution:

I’ve also tried to make the pixel resolution bigger. Putting 48 for both LogicalPixelsX and LogicalPixelsY, resulted in a lot of screen space, and tiny font / images

48 logical resolution, means 2560 * 1920. Wow, not even my desktop computer has such a huge resolution.

How to calculate this?

It’s easy. The original “logical resolution” was 192×192, that is 640×480 pixels.
384×384, is double the original one (192×192), but everything gets bigger. So the actual screen resolution, gets half of 640×480. That would be 640/2=320 x 480/2=240 where 2 = 384/192.

For 48×48, we can follow the same idea.

48 / 192 = 1/4 .

640 / 1/4 = 640 * 4 = 2560 .

480 / 1/4 = 480 * 4 = 1920.

You don’t need to enter equal values for LogicalPixelsX and LogicalPixelsY. If these values are not equal, the normal proportion between horizontal and vertical axis will change.

Here’s a last sample with 512 for LogicalPixelsX and 128 for LogicalPixelsY. The screen resolution on landscape is 640 / (512 / 192) = 240 , 480 / (128/192) = 720.

Remember to reset your device after changing the registry keys. It might be a good idea to power off the device by pressing the power button before pressing the reset, so the registry would be flushed (saved to storage). Be careful not to press Power button together with reset, as on some devices this can do a hard reset (first press power off, THEN release it, THEN do a reset).

September 2, 2008

Controlling the Radio Devices

Filed under: Windows Mobile — Tags: , , , , , — radumotisan @ 2:55 am

Introduction


The number of mobile devices manufacturers is quite big at the moment, so for the developers there are many platforms out on the market and their software must function properly on each of them.
Most of the programming aspects are covered by the available APIs. General things like drawing a fancy interface or having a minimum of functionality will work without any issues on all the Windows Mobile platforms. But if we need to control the Hardware installed, its a totally different story. Each manufacturer works with his own providers of electronic components. Each electronic module has some particularities, some parameters that one should know if he is supposed to work with that equipment.
For this article we will focus on a way of controlling the Radio Devices. Currently, most Mobile Devices contain a Bluetooth module, a Phone module and a Wireless Lan module (WiFi). I could say we are lucky that a general solution was provided by Microsoft, but again, that solution lies buried in the ossvcs.dll file.

Getting into details

Usually we need to toggle on or off a particular Radio Device. We would need this for a Profiler software, for a Battery saver, or for many other reasons. Also we would need to know the status of a particular Radio Device.
What many don’t know is that ossvcs.dll exports functions by ordinal numbers, NOT by names. For this article we will use the following exports:

#define GetWirelessDevice_ORDINAL 276
#define ChangeRadioState_ORDINAL 273
#define FreeDeviceList_ORDINAL 280

The ordinal numbers and the prototype of the exported functions are the biggest concern, because the ossvcs.dll is in the ROM and is usually a hard job to obtain this data.

Here are the prototypes of the functions that we need

//imports from ossvcs.dll
typedef LRESULT (CALLBACK* _GetWirelessDevices)(RDD **pDevices, DWORD dwFlags);
typedef LRESULT (CALLBACK* _ChangeRadioState)(RDD* pDev, DWORD dwState, SAVEACTION sa);
typedef LRESULT (CALLBACK* _FreeDeviceList)(RDD *pRoot);

So after we load the ossvcs.dll with LoadLibrary, and prepare the prototype of the functions we can start controlling the Radio Devices.

BOOL InitDLL()
{
g_DllWrlspwr = LoadLibrary(TEXT(“ossvcs.dll”));
if (g_DllWrlspwr == NULL)
return FALSE;
pGetWirelessDevices = (_GetWirelessDevices)GetProcAddress(g_DllWrlspwr,MAKEINTRESOURCE(GetWirelessDevice_ORDINAL));
if (pGetWirelessDevices == NULL)
return FALSE;
pChangeRadioState = (_ChangeRadioState)GetProcAddress(g_DllWrlspwr,MAKEINTRESOURCE(ChangeRadioState_ORDINAL));
if (pChangeRadioState == NULL)
return FALSE;
pFreeDeviceList = (_FreeDeviceList)GetProcAddress(g_DllWrlspwr,MAKEINTRESOURCE(FreeDeviceList_ORDINAL));
if (pFreeDeviceList == NULL)
return FALSE;
return TRUE;
}

To get the current status a simple query would be:

DWORD dwWifi, dwPhone, dwBT;
GetWDevState(&dwWifi, &dwPhone, &dwBT);
// For dwBT == 1 or dwBT == 2 The Bluetooth Radio is ON
// For dwPhone == 1 The Phone Radio is ON
// For dwWifi == 1 The WiFi Radio is ON

GetWDevState works by calling the pGetWirelessDevices, parsing the output provided, item by item, and then deallocating the used memory with pFreeDeviceList, as you can see in the sample. A memory leak of 8KB results from this process, indicating that pFreeDeviceList is not functioning properly. I would be happy if any of the readers of this article figures out the cause of this.
For changing the state of a particular Radio Device use SetWDevState:

//0 for stop, 1 for start
SetWDevState( RADIODEVICES_BLUETOOTH, 0);
SetWDevState( RADIODEVICES_PHONE, 0);
SetWDevState( RADIODEVICES_MANAGED, 0);

SetWDevState uses pGetWirelessDevices, pChangeRadioState and pFreeDeviceList.

As usual, I have also prepared a sample, for a better understanding of what this article descriebes:

C++ Sample

C++ Sample

radiodevices sample files.

Your feedback is most welcomed.

Radu Motisan

The Silver is the New Black Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.