Notion Ink, a Hyderabad-based technology start-up, has developed the first touchscreen tablet which uses Google’s open source operating system Android, Nvidia’s yet-to-be launched Tegra processor chips and a power-saving display screen from the US-based fabless developer Pixel Qi.
The tablet PC developed by six IITians and an MBA will be showcased for the first time at the Las Vegas Consumer Electronics Show in January 2010.
“After the evolution of desktops, laptops and notebooks, the next innovation is going to be a complete touchscreen you can write on. And, we thought we needed to take the first step. It took us a year to come up with the design, requirements and proposed technologies to make this device a reality,” says Rohan Shravan, founder and director (creatives) of Notion Ink. The company was floated in February 2009.
Called Notion Ink, the new tablet has a 10.1-inch touchscreen. In terms of portability, it is powered by Nvidia’s Tegra processor chip, weighs 770 grams and offers features like Bluetooth, a 3-megapixel digital camera with autofocus, video recording and 32GB data storage.
“Theoretically, it can work for 25 days if one just listens to music. To be precise, it has 48 hours of standby, eight hours of high-definition video and 16 hours of Wi-Fi internet surfing usage time,” claims Shravan.
For designing the device, the company collaborated with Bangalore-based National Institute of Design. “We wanted to adopt an operating system which would make our device ‘talk’ to any other device. And we chose Google’s Android. But India doesn’t have people working on Android and those who have, charge Rs 1 lakh per resource per month (like Tata Elxsi or Sasken). So, we opted to train 46 students from the Hyderabad-based information technology institute BVR IT who are now working full time with us,” he adds.
Notion Ink has filed two patents — one for the design and the other for technology — in India, Taiwan and China, which makes it easy to tie up with an original equipment manufacturer (OEM) in Taiwan. It is yet to file 67 patents, most of which are for user interface, hardware changes and software optimisation . It is also working on creating digital books, songs, movies and media content for the device.
Four Taiwanese companies have already evinced interest to manufacture the device. “We have global ambitions, so the US is a very important market for us, and that needs networking. For this reason, we are going to showcase our product in Las Vegas,” Shravan says, adding they are planning to launch the smartpad commercially in June 2010.
The company would adopt a complete service model, wherein the Taiwanese OEM will have 90 days to manufacture and Notion Ink another 90 days to pay them back after selling the devices. It is targeting to sell 1.5 million units of the tablet PC in the first year of launch. The device is tentatively priced at below $400 (Rs 18,800) in the US and below $300 (Rs 14,100) in India (with subsidy from telecom operators).
“The device will be bundled with internet services by telecom operators. Already 10 telcos in the US and four in India, which offer 3G services, have shown interest. We will be finalising one telco for the US and one for India during the four-day Mobile World Congress, which is scheduled to be held at Barcelona, Spain, from February 15, 2010,”
Monday, December 28, 2009
Saturday, December 19, 2009
First Android Phone Anniversary with 50 Already Planned
First Android Phone Anniversary with 50 Already Planned
Today marks the one year anniversary of the first publicly available Android phone the HTC Dream T-Mobile G1 as it made its debut on October 22nd, 2008.
I have been talking about Android for well over a year as I presented and spoke on panels at SMX Advanced, PubCon, BarCamps, Google User Technology Groups, SMX East as well a recent Cornell University study.
I enjoyed seeing the evolution in awareness and respect Android has received since I first spoke about it at conferences as people would initially scoff that it would never make any real inroads into the smartphone market nevermind ultimately supplanting the mighty iPhone.
Earlier this month I spoke at SMX East in New York City and provided an update with Cindy Krum on Android for WebProNews with the video below:
I been keeping an updated list of all the current & upcoming Android mobile phones both rumored and confirmed as it totals 50 on this one year mark.
BOLD if available now / ITALICS is rumored release date
1. Acer Liquid – A1 – November 28th
2. Compulab Exeda
3. Dell Ophone mini3i – Benzine
4. Geek Phone One
5. General Mobile DSTL1
6. Haier H7
7. HKC Pearl
8. HighScreen PP5420
9. HTC Click – Fiesta – Tattoo
10. HTC Desire 6200 – November
11. HTC Dragon – Zoom 2
12. HTC Dream – T-Mobile G1
13. HTC Hero – G2 Touch
14. HTC Lancaster
15. HTC Magic – Sapphire – T-Mobile myTouch 3G – Google Ion – Dopod A6188
16. HTC Passion
17. HTC Predator
18. Huawei U8220 – T-Mobile Pulse
19. Huawei U8230
20. Innocomm Skate
21. Kogan Agora
22. Koolu Freerunner – Openmoko GTA02
23. Lenovo O1 Ophone
24. LG Etna
25. LG GW620 Eve – November 2009
26. LG GW880
27. Motorola Calgary
28. Motorola Devour
29. Motorola Droid – Sholes – Tao – November 7th
30. Motorola Heron
31. Motorola MB200
32. Motorola MB300
33. Motorola Morrison – Cliq – DEXT
34. Motorola Motis – 2010
35. Motorola Sholes Tablet – 2010
36. Motorola Zeppelin – 2010
37. Philips V808
38. Qigi i6
39. Samsung Behold 2 T939 – November 18th
40. Samsung Bigfoot
41. Samsung Galaxy i7500
42. Samsung Galaxy Lite i5700 – Spica – 2010
43. Samsung Houdini
44. Samsung m850 Q
45. Samsung Moment – InstinctQ m900 – November 1st
46. Sciphone N12
47. Sony Ericsson XPERIA X3 / x10 Rachael – January 2010
48. Sunno S880
49. Tiger G3
50. ZTE Android
I am curious to the expansion of this number at the next anniversary of the G1.
Today marks the one year anniversary of the first publicly available Android phone the HTC Dream T-Mobile G1 as it made its debut on October 22nd, 2008.
I have been talking about Android for well over a year as I presented and spoke on panels at SMX Advanced, PubCon, BarCamps, Google User Technology Groups, SMX East as well a recent Cornell University study.
I enjoyed seeing the evolution in awareness and respect Android has received since I first spoke about it at conferences as people would initially scoff that it would never make any real inroads into the smartphone market nevermind ultimately supplanting the mighty iPhone.
Earlier this month I spoke at SMX East in New York City and provided an update with Cindy Krum on Android for WebProNews with the video below:
I been keeping an updated list of all the current & upcoming Android mobile phones both rumored and confirmed as it totals 50 on this one year mark.
BOLD if available now / ITALICS is rumored release date
1. Acer Liquid – A1 – November 28th
2. Compulab Exeda
3. Dell Ophone mini3i – Benzine
4. Geek Phone One
5. General Mobile DSTL1
6. Haier H7
7. HKC Pearl
8. HighScreen PP5420
9. HTC Click – Fiesta – Tattoo
10. HTC Desire 6200 – November
11. HTC Dragon – Zoom 2
12. HTC Dream – T-Mobile G1
13. HTC Hero – G2 Touch
14. HTC Lancaster
15. HTC Magic – Sapphire – T-Mobile myTouch 3G – Google Ion – Dopod A6188
16. HTC Passion
17. HTC Predator
18. Huawei U8220 – T-Mobile Pulse
19. Huawei U8230
20. Innocomm Skate
21. Kogan Agora
22. Koolu Freerunner – Openmoko GTA02
23. Lenovo O1 Ophone
24. LG Etna
25. LG GW620 Eve – November 2009
26. LG GW880
27. Motorola Calgary
28. Motorola Devour
29. Motorola Droid – Sholes – Tao – November 7th
30. Motorola Heron
31. Motorola MB200
32. Motorola MB300
33. Motorola Morrison – Cliq – DEXT
34. Motorola Motis – 2010
35. Motorola Sholes Tablet – 2010
36. Motorola Zeppelin – 2010
37. Philips V808
38. Qigi i6
39. Samsung Behold 2 T939 – November 18th
40. Samsung Bigfoot
41. Samsung Galaxy i7500
42. Samsung Galaxy Lite i5700 – Spica – 2010
43. Samsung Houdini
44. Samsung m850 Q
45. Samsung Moment – InstinctQ m900 – November 1st
46. Sciphone N12
47. Sony Ericsson XPERIA X3 / x10 Rachael – January 2010
48. Sunno S880
49. Tiger G3
50. ZTE Android
I am curious to the expansion of this number at the next anniversary of the G1.
A closer look at the Android project build system intial
In this two part post we will take a closer look at the structure of the build system for native functionality. The build system is based on make and resides in the build folder in the project. The first part will look at what is found in this folder while the second part discusses the Android.mk file and options.
envsetup.sh
There is one important file in build directory itself. That is the envsetup.sh file. This shell script contains a lot of functionality that is nice to have when working with Android. To invoke it type
. build/envsetup.sh
in the android root directory. This will allow you to use a number of new commands including:
m - make from the top of the tree
mm - builds all modules in the current directory
cgrep - grep in all c-files
jgrep - grep in all java-files
mgrep - grep in all makefiles
lunch - choose build target
These shell commands are very useful when working with the platform. Whether you are looking for something specific in a source file or you just want to build the current module for a test.
build/target
The target directory contains make configurations for different boards and products. The target directory is where new products can be added as needed by a hardware manufacturer. In the current release there is a generic product description, and sdk product and some other files. The available boards are the emulator, a generic board and the simulator.
The board makefiles describe the hardware platform level and can be shared among a number of products. For example you can build both the generic product and the generic_with_google product to run on in the emulator.
The makefiles for different products are listed in the file AndroidProducts.h. To add a new product put the makefile in the build/target/product folder and add the product to AndroidProduct.h. It is possible for product makefiles to inherit from each other to reduce the need for copying. The generic_with_google products inherits the generic product that inherits the core product to make up a three level product specification.
build/core
The core folder is the location of the build system files. These files are used to set up the build system and to build all the different modules as configured in the individual Android.mk files. The main.mk file is the entry point to the build system and it is this files that is included in the top level makefile in the project root directory. The build system can also be invoked by the shell command mm with at subset of the makefiles
The include order and hierarchy of the makefiles is rather complicated but an attempt of illustration can be found in this figure.
Most of the build configuration is set in the config.mk file and the definitions.mk file contains the functions to be invoked for the different source types. In the above figure the build system is invoked to build a shared library. The Android makefile uses the BUILD_SHARED_LIBRARY variable set in the config.mk file. This will set the build chain for building a shared library in a number of steps using several other files.
envsetup.sh
There is one important file in build directory itself. That is the envsetup.sh file. This shell script contains a lot of functionality that is nice to have when working with Android. To invoke it type
. build/envsetup.sh
in the android root directory. This will allow you to use a number of new commands including:
m - make from the top of the tree
mm - builds all modules in the current directory
cgrep - grep in all c-files
jgrep - grep in all java-files
mgrep - grep in all makefiles
lunch - choose build target
These shell commands are very useful when working with the platform. Whether you are looking for something specific in a source file or you just want to build the current module for a test.
build/target
The target directory contains make configurations for different boards and products. The target directory is where new products can be added as needed by a hardware manufacturer. In the current release there is a generic product description, and sdk product and some other files. The available boards are the emulator, a generic board and the simulator.
The board makefiles describe the hardware platform level and can be shared among a number of products. For example you can build both the generic product and the generic_with_google product to run on in the emulator.
The makefiles for different products are listed in the file AndroidProducts.h. To add a new product put the makefile in the build/target/product folder and add the product to AndroidProduct.h. It is possible for product makefiles to inherit from each other to reduce the need for copying. The generic_with_google products inherits the generic product that inherits the core product to make up a three level product specification.
build/core
The core folder is the location of the build system files. These files are used to set up the build system and to build all the different modules as configured in the individual Android.mk files. The main.mk file is the entry point to the build system and it is this files that is included in the top level makefile in the project root directory. The build system can also be invoked by the shell command mm with at subset of the makefiles
The include order and hierarchy of the makefiles is rather complicated but an attempt of illustration can be found in this figure.
Most of the build configuration is set in the config.mk file and the definitions.mk file contains the functions to be invoked for the different source types. In the above figure the build system is invoked to build a shared library. The Android makefile uses the BUILD_SHARED_LIBRARY variable set in the config.mk file. This will set the build chain for building a shared library in a number of steps using several other files.
A closer look at the Android project build system
This is the second post on the build system where we will take a closer look at the Android.mk file and what options are available. An Android.mk file describes the build for any native module that should go in the platform. We will start by looking at the makefile for the external ping facility found in external/ping.
ifneq ($(TARGET_SIMULATOR),true)
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= ping.c
LOCAL_MODULE := ping
LOCAL_STATIC_LIBRARIES := libcutils libc
include $(BUILD_EXECUTABLE)
endif # TARGET_SIMULATOR != true
The first line is just a check if we are building for the (obsolete?) simulator. The next line sets the local path to the current directory (the directory of this Android.mk file). This is handled by a function called mydir that can be found in the definitions.mk file in the build system.
The next step is to include a makefile that will clear all local variables with the line include $(CLEAR_VARS). CLEAR_VARS is set in the build configuration in config.mk and will include the clear_vars.mk file at this point. The main purpose of this include is to make sure that we do not use any local variables set by another module.
After the two initial lines that basically prepares the build system to start with this module we set the build variables. These are
LOCAL_SRC_FILES - the source files that make up this module
LOCAL_MODULE - the name of the module
LOCAL_STATIC_LIBRARIES - libraries to statically link to this module
Since ping will be an executable command placed in /system/bin in the Android file system the make file for building an executable should be used. This done with the line:
include $(BUILD_EXECUTABLE)
There are makefiles available in the build system that can be used to build a number of different types of module. To include them you may use one of the variables set in the config.mk file. A few important ones are:
BUILD_EXECUTABLE - Build an executable module
BUILD_SHARED_LIBRARY - Build a shared library
BUILD_STATIC_LIBRARY - Build a static library
BUILD_PREBUILT - Add prebuilt components
There is also a number of local variables that are recognized by the build system and that needs to be set in order to build your module.
LOCAL_C_INCLUDES - path to include files needed by your module, e.g. ($KERNEL_HEADERS)
LOCAL_CFLAGS - Any additional flags to pass to the compiler
LOCAL_LDFLAGS - Any additional flags to pass to the linker
LOCAL_SHARED_LIBRARIES - Shared libraries that the module directly links against
LOCAL_SRC_FILES - The source files to compile
LOCAL_STATIC_LIBRARIES - Static libraries to include in the module
You may use one Android.mk to build several items. It is possible to build both a library and an executable using the same makefile. To illustrate how to write a makefile for some native functionality we will look at another example. This makefile will build a shared library and an executable. It links to a couple of shared libraries in the system.
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
#Name of target to build
LOCAL_MODULE:= libmylibrary
#Source files to compile
LOCAL_SRC_FILES:= mysrcfile.c mysothersrcfile.c
#The shared libraries to link against
LOCAL_SHARED_LIBRARIES := libcutils
#No special headers needed
LOCAL_C_INCLUDES +=
#Prelink this library, also need to add it to the prelink map
LOCAL_PRELINK_MODULE := true
include $(BUILD_SHARED_LIBRARY)
#Clear variables and build the executable
include $(CLEAR_VARS)
LOCAL_MODULE:= myinfocmd
LOCAL_SRC_FILES:= mycmdsrcfile.c
include $(BUILD_EXECUTABLE)
The output of the build system is put in the out folder in the Android project. Build output is directed to a subfolder based on the product. A default build is for the generic product and will output everything target related to that folder. A shared library ends up in /out/target/product/generic/system/lib. In the same way an executable will end up in /out/target/product/generic/system/bin. The object files and intermediates are kept in the obj folder. The root, system, and data folders will be used to generate the file system images needed for Android in the last build step.
ifneq ($(TARGET_SIMULATOR),true)
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= ping.c
LOCAL_MODULE := ping
LOCAL_STATIC_LIBRARIES := libcutils libc
include $(BUILD_EXECUTABLE)
endif # TARGET_SIMULATOR != true
The first line is just a check if we are building for the (obsolete?) simulator. The next line sets the local path to the current directory (the directory of this Android.mk file). This is handled by a function called mydir that can be found in the definitions.mk file in the build system.
The next step is to include a makefile that will clear all local variables with the line include $(CLEAR_VARS). CLEAR_VARS is set in the build configuration in config.mk and will include the clear_vars.mk file at this point. The main purpose of this include is to make sure that we do not use any local variables set by another module.
After the two initial lines that basically prepares the build system to start with this module we set the build variables. These are
LOCAL_SRC_FILES - the source files that make up this module
LOCAL_MODULE - the name of the module
LOCAL_STATIC_LIBRARIES - libraries to statically link to this module
Since ping will be an executable command placed in /system/bin in the Android file system the make file for building an executable should be used. This done with the line:
include $(BUILD_EXECUTABLE)
There are makefiles available in the build system that can be used to build a number of different types of module. To include them you may use one of the variables set in the config.mk file. A few important ones are:
BUILD_EXECUTABLE - Build an executable module
BUILD_SHARED_LIBRARY - Build a shared library
BUILD_STATIC_LIBRARY - Build a static library
BUILD_PREBUILT - Add prebuilt components
There is also a number of local variables that are recognized by the build system and that needs to be set in order to build your module.
LOCAL_C_INCLUDES - path to include files needed by your module, e.g. ($KERNEL_HEADERS)
LOCAL_CFLAGS - Any additional flags to pass to the compiler
LOCAL_LDFLAGS - Any additional flags to pass to the linker
LOCAL_SHARED_LIBRARIES - Shared libraries that the module directly links against
LOCAL_SRC_FILES - The source files to compile
LOCAL_STATIC_LIBRARIES - Static libraries to include in the module
You may use one Android.mk to build several items. It is possible to build both a library and an executable using the same makefile. To illustrate how to write a makefile for some native functionality we will look at another example. This makefile will build a shared library and an executable. It links to a couple of shared libraries in the system.
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
#Name of target to build
LOCAL_MODULE:= libmylibrary
#Source files to compile
LOCAL_SRC_FILES:= mysrcfile.c mysothersrcfile.c
#The shared libraries to link against
LOCAL_SHARED_LIBRARIES := libcutils
#No special headers needed
LOCAL_C_INCLUDES +=
#Prelink this library, also need to add it to the prelink map
LOCAL_PRELINK_MODULE := true
include $(BUILD_SHARED_LIBRARY)
#Clear variables and build the executable
include $(CLEAR_VARS)
LOCAL_MODULE:= myinfocmd
LOCAL_SRC_FILES:= mycmdsrcfile.c
include $(BUILD_EXECUTABLE)
The output of the build system is put in the out folder in the Android project. Build output is directed to a subfolder based on the product. A default build is for the generic product and will output everything target related to that folder. A shared library ends up in /out/target/product/generic/system/lib. In the same way an executable will end up in /out/target/product/generic/system/bin. The object files and intermediates are kept in the obj folder. The root, system, and data folders will be used to generate the file system images needed for Android in the last build step.
Zygote System Process
The important processes in the system appear to be zygote (which is the app_process binary), and runtime. These are both started up by the init process. The following fragment of init.rc is relevant. It is important to note that these services have the autostart 1 attribute, indicating they are restarted if they quit.
zygote {
exec /system/bin/app_process
args {
0 -Xzygote
1 /system/bin
2 --zygote
}
autostart 1
}
runtime {
exec /system/bin/runtime
autostart 1
}
If we go and kill either the zygote, or runtime process something interesting happens. Firstly the other process seems to kill itself, and then the whole system seems to restart.
Changing the ramdisk image
I want to get a bit more control of what things are starting up when. To do this I need to modify the init.rc file. To do this I first extracted the the ramdisk to the fileystem so that I can modify it (gnucpio -iz -F ramdisk.img).
After this I simply commented out the line from init.rc. Then we can recreate it: (gnucpio -i -t -F ../ramdisk.img | gnucpio -o -H newc -O ../rootfs.img).
Note if you are using Mac OS X, you will need to download and install gnucpio, becuase the built-in cpio doesn't support newc.
We can then use the emulator -ramdisk option to load our new ramdisk.
Manual startup
Now we can start things up manually. First we start up the zygote process. As # app_process -Xzygote /system/bin --zygote. When we do that there is no output either on the console, or on the LCD. Next we start the runtime process ( # runtime), and now things start to happen!
Once both processes start we get the cylon image, and we also end up with some console output:
Prepping: /system/app/AlarmProvider.apk:/system/app/Browser.apk:/system/app/Ca
lendar.apk:/system/app/Camera.apk:/system/app/Contacts.apk:/system/app/Developm
ent.apk:/system/app/GDataFeedsProvider.apk:/system/app/Gmail.apk:/system/app/Gm
ailProvider.apk:/system/app/GoogleApps.apk:/system/app/GoogleAppsProvider.apk:/
system/app/Home.apk:/system/app/ImProvider.apk:/system/app/Maps.apk:/system/app
/MediaPickerActivity.apk:/system/app/MediaProvider.apk:/system/app/Phone.apk:/s
ystem/app/PimProvider.apk:/system/app/ApiDemos.apk:/system/app/SettingsProvider
.apk:/system/app/Sms.apk:/system/app/SyncProvider.apk:/system/app/TelephonyProv
ider.apk:/system/app/XmppService.apk:/system/app/YouTube.apk
File not found: /system/app/AlarmProvider.apk
File not found: /system/app/Calendar.apk
File not found: /system/app/Camera.apk
File not found: /system/app/GDataFeedsProvider.apk
File not found: /system/app/Gmail.apk
File not found: /system/app/GmailProvider.apk
File not found: /system/app/MediaPickerActivity.apk
File not found: /system/app/PimProvider.apk
File not found: /system/app/ApiDemos.apk
File not found: /system/app/Sms.apk
File not found: /system/app/SyncProvider.apk
File not found: /system/app/YouTube.apk
Prep complete
It might give some clue of which Google applications will be available in the future. :)
The output from runtime looks like this:
+++ post-zygote
There is also some interesting output from the kernel. In particular the binder_open log. We can look at these in more detail later.
binder_open(c086f300 c0832160) (pid 462) got c5cea000
binder_open(c086f300 c095ec40) (pid 475) got c4e8b000
binder_open(c086f300 c095ef40) (pid 476) got c46f8000
android_power: auto off timeout set to 604800 seconds
Descriptor2Node failed secondary: desc=4, max=32, node=c4e8c350, weak=0
binder_open(c086f300 c4008d60) (pid 513) got c473a000
binder_open(c086f300 c4008760) (pid 512) got c39fc000
binder_open(c086f300 c4008260) (pid 531) got c35e3000
That is about enough detail for this entry, next time I'll be using strace to try and get a bit more information about these processes.
zygote {
exec /system/bin/app_process
args {
0 -Xzygote
1 /system/bin
2 --zygote
}
autostart 1
}
runtime {
exec /system/bin/runtime
autostart 1
}
If we go and kill either the zygote, or runtime process something interesting happens. Firstly the other process seems to kill itself, and then the whole system seems to restart.
Changing the ramdisk image
I want to get a bit more control of what things are starting up when. To do this I need to modify the init.rc file. To do this I first extracted the the ramdisk to the fileystem so that I can modify it (gnucpio -iz -F ramdisk.img).
After this I simply commented out the line from init.rc. Then we can recreate it: (gnucpio -i -t -F ../ramdisk.img | gnucpio -o -H newc -O ../rootfs.img).
Note if you are using Mac OS X, you will need to download and install gnucpio, becuase the built-in cpio doesn't support newc.
We can then use the emulator -ramdisk option to load our new ramdisk.
Manual startup
Now we can start things up manually. First we start up the zygote process. As # app_process -Xzygote /system/bin --zygote. When we do that there is no output either on the console, or on the LCD. Next we start the runtime process ( # runtime), and now things start to happen!
Once both processes start we get the cylon image, and we also end up with some console output:
Prepping: /system/app/AlarmProvider.apk:/system/app/Browser.apk:/system/app/Ca
lendar.apk:/system/app/Camera.apk:/system/app/Contacts.apk:/system/app/Developm
ent.apk:/system/app/GDataFeedsProvider.apk:/system/app/Gmail.apk:/system/app/Gm
ailProvider.apk:/system/app/GoogleApps.apk:/system/app/GoogleAppsProvider.apk:/
system/app/Home.apk:/system/app/ImProvider.apk:/system/app/Maps.apk:/system/app
/MediaPickerActivity.apk:/system/app/MediaProvider.apk:/system/app/Phone.apk:/s
ystem/app/PimProvider.apk:/system/app/ApiDemos.apk:/system/app/SettingsProvider
.apk:/system/app/Sms.apk:/system/app/SyncProvider.apk:/system/app/TelephonyProv
ider.apk:/system/app/XmppService.apk:/system/app/YouTube.apk
File not found: /system/app/AlarmProvider.apk
File not found: /system/app/Calendar.apk
File not found: /system/app/Camera.apk
File not found: /system/app/GDataFeedsProvider.apk
File not found: /system/app/Gmail.apk
File not found: /system/app/GmailProvider.apk
File not found: /system/app/MediaPickerActivity.apk
File not found: /system/app/PimProvider.apk
File not found: /system/app/ApiDemos.apk
File not found: /system/app/Sms.apk
File not found: /system/app/SyncProvider.apk
File not found: /system/app/YouTube.apk
Prep complete
It might give some clue of which Google applications will be available in the future. :)
The output from runtime looks like this:
+++ post-zygote
There is also some interesting output from the kernel. In particular the binder_open log. We can look at these in more detail later.
binder_open(c086f300 c0832160) (pid 462) got c5cea000
binder_open(c086f300 c095ec40) (pid 475) got c4e8b000
binder_open(c086f300 c095ef40) (pid 476) got c46f8000
android_power: auto off timeout set to 604800 seconds
Descriptor2Node failed secondary: desc=4, max=32, node=c4e8c350, weak=0
binder_open(c086f300 c4008d60) (pid 513) got c473a000
binder_open(c086f300 c4008760) (pid 512) got c39fc000
binder_open(c086f300 c4008260) (pid 531) got c35e3000
That is about enough detail for this entry, next time I'll be using strace to try and get a bit more information about these processes.
Instaling & Deleting Applications from Android emulator Command Line
1. Go to the tools directory in command prompt – c:\>android\tools
2. Type adb shell
3. #cd /data/app (this takes you to the folder where all apk files are installed)
4. #ls (It will display all the .apk installed in your emulator)
5. #rm ***.apk (which you want to remove, all apk files)
6.#exit (exits from the adb shell)
NOTE: to start the emulator, you can start it from eclipse by right clicking an android project and “run as” an “application” or by going to tools directory at command prompt and typing “emulator –avd”
2. Type adb shell
3. #cd /data/app (this takes you to the folder where all apk files are installed)
4. #ls (It will display all the .apk installed in your emulator)
5. #rm ***.apk (which you want to remove, all apk files)
6.#exit (exits from the adb shell)
NOTE: to start the emulator, you can start it from eclipse by right clicking an android project and “run as” an “application” or by going to tools directory at command prompt and typing “emulator –avd
The Android boot process from power on
Since mobile platforms and embedded systems has some differences compared to Desktop systems in how they initially start up and boot this post will discuss the initial boot stages of an Android phone in some detail. Since we have used the Beagle Board as reference in some previous examples any specifics here are related to a similar system.
1. Power on and boot ROM code execution
At power on the CPU will be in a state where no initializations have been done. Internal clocks are not set up and the only memory available is the internal RAM. When power supplies are stable the execution will start with the Boot ROM code. This is a small piece of code that is hardwired in the CPU ASIC. For more information on boot ROM and configurations study the initalization chapter in
the Omap 3530 TRM.
* A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the asic. This is to determine where to find the first stage of the boot loader.
* B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.
2. The boot loader
The boot loader is a special program separate from the Linux kernel that is used to set up initial memories and load the kernel to RAM. On desktop systems the boot loaders are programs like GRUB and in embedded Linux uBoot is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders. The requirements on a boot loader for Linux running on an ARM system can be found in the Booting document under /Documentation/arm in the kernel source tree.
* A. The first boot loader stage will detect and set up external RAM.
* B. Once external RAM is available and the system is ready the to run something more significant the first stage will load the main boot loader and place it in external RAM.
* C. The second stage of the boot loader is the first major program that will run. This may contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.
* D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.
* E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.
3. The Linux kernel
The Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.
* A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.
* B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.
4. The init process
The init process is the "grandmother" of all system processes. Every other process in the system will be launched from this process or one of its descendants.
* A. The init process in Android will look for a file called init.rc. This is a script that describes the system services, file system and other parameters that need to be set up. The init.rc script is placed in system/core/rootdir in the Android open source project.
* B. The init process will parse the init script and launch the system service processes.
5. Zygote and Dalvik
The Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.
6. The system server
The system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth. Start up of each service is currently written directly into the run method of the system server. The system server source can be found in the file frameworks/base/services/java/com/android/server/SystemServer.java in the open source project.
7. Boot completed
Added this part to the post on 20090831 since it is very useful and something I should not have left out from the beginning. Once the System Server is up and running and the system boot has completed there is a standard broadcast action called ACTION_BOOT_COMPLETED. To start your own service, register an alarm or otherwise make your application perform some action after boot you should register to receive this broadcast intent.
1. Power on and boot ROM code execution
At power on the CPU will be in a state where no initializations have been done. Internal clocks are not set up and the only memory available is the internal RAM. When power supplies are stable the execution will start with the Boot ROM code. This is a small piece of code that is hardwired in the CPU ASIC. For more information on boot ROM and configurations study the initalization chapter in
the Omap 3530 TRM.
* A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the asic. This is to determine where to find the first stage of the boot loader.
* B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.
2. The boot loader
The boot loader is a special program separate from the Linux kernel that is used to set up initial memories and load the kernel to RAM. On desktop systems the boot loaders are programs like GRUB and in embedded Linux uBoot is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders. The requirements on a boot loader for Linux running on an ARM system can be found in the Booting document under /Documentation/arm in the kernel source tree.
* A. The first boot loader stage will detect and set up external RAM.
* B. Once external RAM is available and the system is ready the to run something more significant the first stage will load the main boot loader and place it in external RAM.
* C. The second stage of the boot loader is the first major program that will run. This may contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.
* D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.
* E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.
3. The Linux kernel
The Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.
* A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.
* B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.
4. The init process
The init process is the "grandmother" of all system processes. Every other process in the system will be launched from this process or one of its descendants.
* A. The init process in Android will look for a file called init.rc. This is a script that describes the system services, file system and other parameters that need to be set up. The init.rc script is placed in system/core/rootdir in the Android open source project.
* B. The init process will parse the init script and launch the system service processes.
5. Zygote and Dalvik
The Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.
6. The system server
The system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth. Start up of each service is currently written directly into the run method of the system server. The system server source can be found in the file frameworks/base/services/java/com/android/server/SystemServer.java in the open source project.
7. Boot completed
Added this part to the post on 20090831 since it is very useful and something I should not have left out from the beginning. Once the System Server is up and running and the system boot has completed there is a standard broadcast action called ACTION_BOOT_COMPLETED. To start your own service, register an alarm or otherwise make your application perform some action after boot you should register to receive this broadcast intent.
Subscribe to:
Posts (Atom)