Android Material

"Android is a software stack for mobile devices that includes an operating system, middleware and key applications."  OR  "Android is software platform for mobile devices based on the Linux Operating System and developed by Google and the open Handset Alliance." INFO: The Android SDK provides the tools and libraries necessary to begin developing applications that run on Android-powered devices. It supports: Operating System: Linux Kernel - Version 2.6 Emulator: on Mac, Windows, Linux Hardware Support:  1. GSM Telephony 2. Bluetooth, 3G, Wi-Fi 3. Camera, GPS, compass and Accelerometer ARCHITECTURE: 1. Applications: Android applications are written in the Java programming language, and they run within a virtual machine (VM). It's important to note that the VM is not a JVM as we might expect, but is the Dalvik Virtual Machine, an open source technology. Each Android application runs within an instance of the Dalvik VM, which in turn resides within a Linux-

We’re almost ready to sign your application, but first you need to create an unsigned version that you can sign with your signature certificate. To do that, in the Package Explorer window of Eclipse, right-click on your project name. You’ll get a long popup menu; toward the bottom, click on Android Tools. You should see another menu that includes the item you want: “Export Unsigned Application Package...”. This item takes you to a File Save dialog box, where you can pick the place to save the unsigned version of your apk file. It doesn’t matter where you put it—just pick a place you can remember. Now that you have an unsigned version of your apk file, we can go ahead and sign it using jarsigner. Open a terminal or command window in the directory where you stored the unsigned apk file. Here’s the line we used to sign MJAndroid, using the key we generated earlier in the keystore microjobs.keystore: $ jarsigner -verbose -keystore microjobs.keystore MJAndroid.apk mjkey Congratulations! Y

When you’re creating and debugging your application that uses a MapView, or when you’re running a demo application like MJAndroid, you still need a valid Map API Key to get map tiles from Google Maps, and you need the fingerprint of your debug signing certificate to obtain a Map API Key. You can’t just use the apiKey that we have coded into the MJAndroid source files, because it is tied to the signing certificate that was generated by our debug environment. Your debug environment will generate its own, different signing certificate for you to use, so you need to obtain a Map API Key to match. There are two steps to getting the key: 1. Get a copy of the MD5 fingerprint for your Debug signing certificate. 2. Use that fingerprint to obtain a valid Map API Key from Google and enter it into AndroidManifest.xml. Getting the MD5 fingerprint of your Debug signing certificate When the Android SDK automatically generates a Debug signing certificate for you, it places it in a keystore called de

Virtually every application that you download onto a desktop or notebook computer will contain an End User License Agreement. You should seriously consider whether you want to attach such a license to your application and have users agree to it before they install the application on their phone. Typically it limits what users are allowed to do with the application, defines whether it can be used for commercial purposes, specifically does not allow reverse engineering, and tries to protect you, the author, should something go wrong and someone has reason to bring a lawsuit against you. There are many such EULAs available on the Internet. You can either adopt one of those as your own or hire a lawyer to create a unique one for you, but the use of a EULA is strongly advised. Create and Attach an Icon and Label When your application is installed (on either the emulator or a real device), an icon and a label are placed on the Application Launcher that is part of your Android Desktop. This

Writing and running Android applications for your own amusement is all well and good, but the point of creating new applications is to share them with others, whether you charge money for them or give them away for free. Google has created Android Market just for that purpose. Anyone with a connected Android phone can open the Android Market application and immediately download any of hundreds (soon to be thousands) of applications expressly designed for Android. These applications range from the very practical (Navigation, Timesheets, File Managers, etc.) to the downright silly (applications that make rude noises for the fun of it). There are a number of steps any application developer will go through in preparing and submitting an application to Android Market: 1. Thoroughly test the application—at least with the Android emulator, but also with as many actual Android devices as you can lay your hands on. There is no substitute for testing applications on real phones under real mobil

To sign your application, you are going to create an encrypted signing certificate and use it to sign your application. You can sign every Android application you develop with the same signing certificate. You can create as many signing certificates as you want, but you really need only one for all your applications. And using one certificate for all your applications lets you do some things that you couldn’t do otherwise: Simplify upgrades Signing certificates are tied to the application package name, so if you change the signing certificate you use with subsequent versions of your application, you’ll have to change the package name, too. Changing certificates is manageable, but messy. Multiple applications per process When all your applications share the same signing certificate, they can run in the same Linux process. You can use this to separate your application into smaller modules (each one an Android application) that together make up the larger application. If you were to do

Devices equipped with Bluetooth technology support wireless point-to-point connections, as well as wireless access to LAN, mobile phone network, the Ethernet and home networking. The connectivity between two Bluetooth equipped devices is carried out as serial communication. Bluetooth technology delivers the received data and receives the data to be transmitted to and from a host system through a host controller interface (HCI). The most popular host controller interface today is either a UART or a USB link. Now, even though we can use USB or UART, the most commonly used HCI is UART because of following reasons: ◦If UART is used software overhead is very less ◦Its highly cost effective. A Universal Asynchronous Receiver and Transmitter (UART) is used for communication with serial input and serial output devices. Serial transmission reduces the cost and complexity of the wirings at the expense of speed, and for many applications this is a desired trade-off. The UART takes bytes of da

When you are porting Android, one important feature to check is SD card mount. Needless to say this feature is needed for many functions to operate correctly. Couple of such examples are Bluetooth OPP and FTP profiles. SD card boot up sequence is as follows : mmc/sd driver recognises the inserted card, makes device object for every partitions with unique combination of MAJOR:MINOR numbers and generate uevent. uevent comes to user-level via kernel socket NETLINK_KOBJECT_UEVENT. vold handles this uevent in uevent.c::handle_block_event(). vold reads boot sector to determine, how many partitions remains on storage. If all partitions are found, vold will start "mount" procedure. If mount is successfully finished, vold sends "volume_mounted:/sdcard" to com.android.server.MountListener. com.android.server.MountListener dispatches message to com.android.server.MountService by handleEvent() method. com.android.server.MountService provides to framework the logi

Following is configuration needed to be done to run Bluetooth on fresh android machine(after porting). 1 . set_bluetooth_power(1) – rfkill i.e. set power i.e. write 1 to /sys/class/rfkill/rfkill0/state this can be done by command line or in bluetooth.c file   Make the changes in Bluetooth.c of (system/Bluetooth/bluedroid).Change the state of the rfkill0 to zero before enabling the power to Bluetooth (these changes are specific to chipset). In bt_enable function copy following (relative to existing code - 3rd line) if (set_bluetooth_power(0) < 0) goto out; usleep(1000000); // 1000 ms retry delay if (set_bluetooth_power(1) < 0) goto out; // This line will is usually present usleep(1000000); // 1000 ms retry delay 2.Starts Hciattach daemon- Either from command line or Init.rc as service. #hciattach -s 115200 /dev/s3c_serial1 any 115200 flow I was using samsung s3c6410 board with broadcom chipset in it. Note the baud rate and initial speed.The above will be through comma

AIDL is functionality in Android to communicate with  other processes and share the data. Though there are many IPC mechanisms Aidl is often chosen because: Remote procedure calls (RPC) using Android’s inter-process communications largely replace the use of the Java Native Interface (JNI) in Android. In almost all cases, a remote procedure call is efficient enough to make it a superior alternative to loading a library—especially one that dynamically allocates a significant amount of memory—into the Java virtual machine’s address space. And if a process exposing an RPC interface fails, it is less likely to bring down the Android UI with it. Android inter-process communication behaves a lot like JNI: the caller’s thread is blocked until the result is returned. Marshalling data across the IPC boundary is about the same amount of work as data conversions in JNI. But Binder-based remote procedure calls have a significant advantage over JNI: if non-Java code crashes or runs out of memory,