Difference between revisions of "Android Interface"

From Lazarus wiki
Jump to navigationJump to search
m (→‎Architecture: spelling)
Line 12: Line 12:
 
To avoid these issues it was preferred to create instead a native executable for the Lazarus applications and let it communicate with the auxiliary Java application only for indispensable things.
 
To avoid these issues it was preferred to create instead a native executable for the Lazarus applications and let it communicate with the auxiliary Java application only for indispensable things.
  
Nothing of the drawing will pass through the Java helper applications, instead everything will be based on OpenGL and on the Lazarus Custom Drawn Controls, as explained in the image bellow.
+
Nothing of the drawing will pass through the Java helper applications, instead everything will be based on OpenGL and on the Lazarus Custom Drawn Controls, as explained in the image below.
 
A generic Java application will be created to launch the LCL application and to expose indispensable parts of the Java Android API to the LCL and both will communicate using pipes. The Lazarus user application will be built as a linux-arm executable and be attached to the generic Java encapsulating application.
 
A generic Java application will be created to launch the LCL application and to expose indispensable parts of the Java Android API to the LCL and both will communicate using pipes. The Lazarus user application will be built as a linux-arm executable and be attached to the generic Java encapsulating application.
 
The encapsulating Java program shouldn't need to be changed by Lazarus users, and no knowledge of Java will be necessary to develop Lazarus applications for Android. Of course Java knowledge will be necessary to implement the auxiliary Java application.
 
The encapsulating Java program shouldn't need to be changed by Lazarus users, and no knowledge of Java will be necessary to develop Lazarus applications for Android. Of course Java knowledge will be necessary to implement the auxiliary Java application.

Revision as of 12:23, 17 November 2010

Architecture

As of August 2010 (and Android 2.2), the Android platform can only execute Java Android applications, but these applications can load native libraries and can also run native executables.

Running the LCL application as a library and communicating with Java via JNI to create a native interface would generate several serious issues:

  1. The main project file would need to be different for Android apps
  2. Free Pascal has some issues with DLLs
  3. The Java Native Interface is very complex and very hard to work with. Worse even that it is totally geared to C++ and is very limited.
  4. The performance of sending data between the Java app and the LCL for every event and for every LCL command would be rather low.
  5. The so created LCL interface would be completely specific to Android, and therefore it's work would be lost in the event that the Android platform goes through serious changes or if Android looses market share.

To avoid these issues it was preferred to create instead a native executable for the Lazarus applications and let it communicate with the auxiliary Java application only for indispensable things.

Nothing of the drawing will pass through the Java helper applications, instead everything will be based on OpenGL and on the Lazarus Custom Drawn Controls, as explained in the image below. A generic Java application will be created to launch the LCL application and to expose indispensable parts of the Java Android API to the LCL and both will communicate using pipes. The Lazarus user application will be built as a linux-arm executable and be attached to the generic Java encapsulating application. The encapsulating Java program shouldn't need to be changed by Lazarus users, and no knowledge of Java will be necessary to develop Lazarus applications for Android. Of course Java knowledge will be necessary to implement the auxiliary Java application.

Android LCL Architecture.png

Roadmap

  1. Build the set of Lazarus Custom Drawn Controls
  2. Learn how to write simple FPC apps which use OpenGL in Android
  3. Implement the basic Java Android encapsulating application
  4. Extend the Java app to expose Android APIs
  5. Write the new customdrawn base widgetset
  6. Write the new opengl base widgetset
  7. Write the new android widgetset

Using the Android SDK

Downloading and installing the Android SDK is easy. One just needs to following this link: http://developer.android.com/sdk/index.html

Recognition of devices under Linux

Unlike in Windows, where one needs to install a new set of drivers for nearly every phone, in Linux the Android devices are recognized as generic Android devices (regardless of being a phone, a tablet or a notebook) and they are ready to be used without installing additional drivers. One issue, however, that offen appears is that devices are not fully recognized automatically and one receives the error message "?????? no permissions". In this case the command adb devices will look like this:

[felipe@localhost ~]$ cd Programas/android-sdk-linux_x86/tools/
[felipe@localhost tools]$ ./adb devices
List of devices attached 
????????????    no permissions

To solve this issue one can proceed with the following steps:

Step 1 - First read the tag of the device using lsusb run as root (or sudo):

[root@localhost Programas]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 04e8:681c Samsung Electronics Co., Ltd 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The tag in this case is 04e8

Step 2 - Now, still as root, edit the file /etc/udev/rules.d/51-android.rules

If the file doesn't exist yet, then create it. Add the following line to the file:

SUBSYSTEM=="usb|usb_device", SYSFS{idVendor}=="04e8", SYMLINK+="android_adb", MODE="0666"

Change the ID to correspond to the id of your device.

Step 3 - Restart the linux usb service (udev)

In Ubuntu this can be done with: sudo services udev restart

In Mandriva udev doesn't appear as a service, so the only way to get things working for me was restarting the computer.

After doing this, the device should be fully recognized and "adb devices" as well as "adb logcat" should work.

[felipe@localhost tools]$ ./adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached 
1000c31696b6    device

Using the Emulator

Installing the Emulator

Building an emulator image with sdcard support

Step 1: Run the application C:\Program Files\android-sdk-windows\tools\android.bat

Step 2: Create a new image, by clicking the New button as in the image bellow.

Android new image.PNG

Step 3: Set the name and properties of the image, the size of the SDCard and add hardware support for the sdcard, as seen on the image bellow.

Android new image dialog.PNG

Running an emulator image

Step 1: Run the application C:\Program Files\android-sdk-windows\tools\android.bat

Step 2: Select the image

Step 3: Click on the "start" button, as seen bellow.

Android run image.PNG

Copying files to the emulator

You can use a script similar to this one to copy files from your hard-drive to the emulator. Notice that the image must be running and that it must have sdcard support built inside itself.

c:
cd "Program Files"
cd android-sdk-windows
cd tools
adb push C:\Mypath\Somefile.extension /sdcard
pause

Installing applications in the emulator

Android apps should be packaged in the Android .apk file format. For more information about how to create an .apk file that you can install on an emulator/device instance, see Android Asset Packaging Tool (aapt). After packing a file, it can be installed in the emulator by using the following adb call:

c:
cd "Program Files"
cd android-sdk-windows
cd tools
adb install C:\Mypath\MyApp.apk
pause

Using the phones

Installing the drivers and getting a reliable way to transfer executables and debug software with all the different Android phone can be a challange in itself.

Installing a File Manager

Astunishingly, Android phones don't come with a file manager o.O One can however simply download one from the Android Market. I suggest the following instructions:

1. Connect the phone to a WiFi or Mobile network

2. Click in the "Market" icon in one of the Android desktops. It will be necessary to log into a Google Account to access it.

3. Click the search button and type "oi"

4. Locate and install the "OI File Manager" which is Free

Samsung Galaxy S

The first thing to do when using Samsung Galaxy S is not beliaving the Samsung instructions. They will say that one should install Kies, their horribly crappy PC suite which is 130MB large and fails to install because the first thing that it does is failling to connect to a server in Korea to download even more files. Instead of doing this, following these instructions:

1. Go in the phone menu Settings -> About Phone -> USB settings. Change from "KIES" to "Mass storage"

2. Download and install 19 MB of Samsung USB drivers from: http://drivers.softpedia.com/dyn-postdownload.php?p=96692&t=4&i=1

3. Connect the cable of the phone

4. Drag the top menu of the phone down and mount the sdcard