How to regenerate bionic/libc/common/kernel headers for linux kernel v2.6.30

by Elvis Dowson » Thu, 23 Jul 2009 20:35:50 GMT


Sponsored Links
 i,
I'm working on trying to port android to linux-omap-2.6.30
kernel version. I've managed to successfully compile the kernel image.
When performing the port to a new kernel version, the bionic/libc
headers also require an update to linux kernel 2.6.30.

I was wondering if someone would be able to validate the changes and
modifications that I have made so far, and suggest some better fixes,
for example, I've had to disable boot animation, to get the
compilation to proceed, due to a linker error. Since this is a first
iteration, at this port, I thought it was acceptable just to try to
see how far it goes. I haven't tested it yet, but was wondering if
someone would be interested in trying this out in parallel, and get
android 1.5 SDK running on android-2.6.30 kernel version.

The reason for attempting this is to update the kernel version for the
gumstix overo, to better take advantage of the power management
functionality currently under development in kevin hilman's linux-omap-
pm pm branch.

Best regards,

Elvis

Technote android-2.6.30-001: How to regenerate bionic/libc/common/
kernel headers for linux kernel v2.6.30

Overview

This document describes how to update the android/bionic/libc/kernel
headers to linux kernel v2.6.30.

Procedure

Step 01.00: Backup the existing android/bionic/libc folder.

You will need the following header files from the existing v2.6.29
linux kernel headers at a later step:

android-alarm.h
android-pmem.h
android_power.h
ashmem.h
binder.h
msm_adsp.h
msm_audio.h
msm_mdp.h
keychord.h

Step 02.00: Clean up the existing android/bionic/libc/kernel folder.

Delete the contents of the following folders

android/bionic/libc/kernel/arch-arm
android/bionic/libc/kernel/arch-x86
android/bionic/libc/kernel/common

Step 03.00: Copy the required linux kernel v2.6.30 headers to the
android/bionic/libc/kernel/original folder.

[TODO: Insert steps on how to clone linux-omap-2.6 git repository and
switch to the omap-2.6.30 branch].

Copy the contents of the following folder to the specific target
location:

linux-omap-2.6/include/asm-generic to android/bionic/libc/kernel/
original/
linux-omap-2.6/include/linux to android/bionic/libc/kernel/original/
linux-omap-2.6/include/mtd to android/bionic/libc/kernel/original/

Step 04.00: Generate the clean linux headers.

Run the tools/update_all.py script to generate the clean linux
headers.

$ cd android/bionic/libc/kernel
$ tools/update_all.py

This will generate the headers into the android/bionic/libc/kernel/
common folder.

Step 05.00: Copy the following headers from the backup v2.6.29 bionic/
libc/kernel/common/linux folder to the new android/bionic/libc/kernel/
common/linux folder.

android-alarm.h
android-pmem.h
android_power.h
ashmem.h
binder.h
msm_adsp.h
msm_audio.h
msm_mdp.h
keychord.h

Step 06.00: Copy the architecture-specific headers.

Copy the contents of the architecture-specific asm folders to the
following target location:

linux-omap-2.6/arch/arm/include/asm to android/bionic/libc/kernel/arch-
arm/
linux-omap-2.6/arch/x86/include/asm to android/bionic/libc/kernel/arch-
x86/

Step 07.00: Delete the contents of the android/out folder.


Step 08.00: Build the android sdk.

$ cd android
$ make -j4

Step 09.00: Apply the following patches for the errors that pop up
during the build process.


Fixes for errors that can come up during compilation




Other Threads

1. Best practices - looking for application design advice for a location aware app.

I am working on my first android application and am looking for some
advice on design decisions.
The main goal of the application is to display trails (like cycling/
hiking trails) near the users current location.
The user will first be presented with a mapview with markers
indicating the location of near by trails.
They can then select a trail and have it overlayed on the map.
The biggest problem right now are:
1) the database is not static - new trails will be added periodically
so a master database will be needed online.
2) trail data (gpx files) consume a lot of space, usually 50 - 300 kb
per trail, so storing all trails on the device may not be feasible.

The three main designs I see are the following:

1) Store light-weight data (like trail names, trail head location,
trail distance, etc) in a local SQLite db on the device.
   Store the light-weight data in a remote database (MySQL or DB2) as
well.
   Store heavy-data (the trail gpx files) remotely.
   New trails are added to the remote database.
   Periodically synchronize/update the local SQLite database with the
remote (master) database.
   When a gpx file is needed, transfer it and parse it to display the
overlay in mapview.
   Possibly store the 10 most frequently used trails (gpx files) on
the device to save bandwidth.

   PRO: Getting the list of nearby trails is fast and easy because it
simply queries the local SQLite database.
   PRO: Minimal amount of data is stored on the local device.
   CON: Transfering gpx files to the device + parsing them will be
time consuming and power draining.

2) Store all data remotely.
   Don't store individual gpx files - parse their data into the
database so all information needed in accessable through database
queries.
   Parsing is done on the server.

   PRO: The android app consumes little space and all processing is
done remotely.
   CON: High bandwidth use due to high number of queries and lots of
returned data (could introduce lag and be costly on the data plan).

3) Store all data (light and heavy) both locally and remotely.
   Don't store individual gpx files - parse their data into the
database so all information needed is accessible through database
queries.
   New trails are added to the remote (master) database.
   Parsing of new trail gpx files is done remotely.
   Periodically synchronize/update the local SQLite database with the
remote (master) database.

   PRO: All data is local so simply query the info needed. Good
performance and low bandwidth use.
   PRO: Synchronization can be done at any time when a WiFi connection
is available so no worry about data plan costs.
   CON: Will consume way too much space. 1000 trails could easily
consume over 100 MB.


Because the database is dynamic I see no way of avoiding having a
master database stored remotely so I image any design will have to
involve network access to a remote database at least for
synchronization purposes if nothing else.


Any advice, insight, or discussion is greatly appreciated.

Thanks!!

--~--~---------~--~----~------------~-------~--~----~

2. Text color problem in Multi Choise dialog

I got a text color problem when diaplaying a multi choise dialog. The
Theme of my app is set like this:

<application android:icon="@drawable/icon" android:label="@string/
app_name" android:theme="@android:style/Theme.Light">
....
</application>

When I pop up a dialog using AlertDialog, text's color in list is
white, and the color of multi select list is white too and I can't see
any of items in it. I'm not special the Theme attribute of the parent
activity who pop up dialog. How can I set text color to black in multi
choise dialog ?
Any help

--~--~---------~--~----~------------~-------~--~----~

3. print on a bluetooth printer

4. Eclipse issues

5. no route to host Exception on Socket

6. Background Task Result Reporting Hypothetical

7. Executing code after installation