I was involved into related activities lately, so there are a couple of things I would like to share.

I’m not going to tell the whole store here, as it is covered rather precisely in the official papers on the point:

• http://source.android.com/source/downloading.html
• http://source.android.com/source/initializing.html
• http://source.android.com/source/building.html
• http://source.android.com/source/using-eclipse.html

The purpose of the post is to make some notes on the setup process and to go a bit further. Major point on this way is to understand that at least basic literacy in Android development is required to pass through the process smoothly. You should not start platform investigation with building Android core from the source code. Android SDK itself provides the environment covering the entire life cycle of native application development. So make sure that you really need it, before you go.

Phase 1. Downloading the source code and building it.

Major point to consider is that xCode 3.x is required to build the whole source code. Build process fails, when building with xCode 4.x installed.

Phase 2. Preparing modified version of the stock application.

Let’s assume that disk image with Android source code lives at ANDROID_SOURCE directory. We are now ready to proceed to the most interesting part.

1. Clone the source code of the application you are interested in (or start a new project) and put it in ANDROID_SOURCE/packages/apps/YOUR_APP.
2. Change application label (see application:label tag in manifest file). Sometimes it is not enough to change application name on Home screen. Make sure that the activity with LAUNCHER category set does not contain label property itself. Note that application:name property corresponds to application class name not to home screen name.
3. Change application package name. This is the most important step. In the world of native Android applications package name means a lot. ADT plugin provides a helper to change package name in regular Android project. In case of stock app most of the steps will be performed manually (mostly by means of text replace tool). You have to change package name in application manifest file (see manifest:package and original-package:name tags).
4. In addition to that you will have to modify Android.mk file (see LOCAL_PACKAGE_NAME variable). This file exists in each directory with stock application source code and is used when building the app. Note that you will have to build the application with make tool. There is no easy way to tune Eclipse for this purpose.
5. And even that is not enough. You will have to update the source code. I strongly recommend to change package name of each source file so it corresponds to the package specified in the manifest. It is not critical requirement and it is possible to do it only partially, but this leads conflicts and confusion. When changing package name along the source code, make sure that you change references to sub-packages and to auto-generated R class in the code.
6. Next place to update is resource files. Sometimes XML layout definitions refer to concrete classes from the source code. You should update these references as well. As you can see most of these changes might be automated with text replace tool.
7. Make sure that you also update package name in string constants in the source code. It is application specific point. So you should be careful about that.
8. Add SDK version information to manifest file. By default the source is built to be run on the version, which corresponds to the source code revision. Most stock applications depend on the most recent features in the OS, but sometimes it is possible to specify minimal SDK version to lower level than current SDK source.

Note that tests project comes with all applications. It is located in /YOUR_APP/tests/ directory. You will have to perform all the steps above for that project as well to be able to build it. Note that it is not necessary to maintain that project. You can just remove tests directory for simplicity.

Phase 3.  Building and running modified version of the stock application.

Once all preparations are done, you will have to build the application with the help of the following command:

$ mmm packages/apps/YOUR_APP/

The command builds the source code and installs apk file into the emulator image, which was created when building Android source code. In order to install the application on emulator provided with the SDK, use the following command:

$ adb install -r /Volumes/Android/source/out/target/product/generic/system/app/YOUR_APP.apk

Note that the binary used above is already signed with debug signature. In order to distribute it, you need unsigned and unaligned version, which is located at

ANDROID_SOURCE/out/target/product/generic/obj/APPS/YOUR_APP/

Other tips

As it is mentioned above and in the original documentation, it is hard (impossible?) to configure Eclipse to build stock apps. However, it is possible to edit source code using Eclipse. Official documentation proposes to add YOUR_APP/src directory to Eclipse project (containing the entire Android source tree). In this case you will be able to make sure that you code compiles correctly before building it from command line. This approach does not allow you to edit other project related resources. So you can just create new Android project from source and specify YOUR_APP directory as project home. In this case you will most likely get lots of compilation errors but along with that you will get access to the entire project tree.

Eclipse is also helpful, when you are ready to run your app on emulator. Keeping Eclipse connected to emulator instance, you get a chance to view run logs in LogCat tab. It is really helpful as exception stack traces provide complete information on error.

Have a fun!

Tags: Android, source code, stock apps

Finally it has happened!!!
I was anxious and excited about this event. The story below says how much salt were eaten to make it live.

We started almost from scratch.

Then we discussed, what to do with what we had.

There were many contradictory opinions, so we agreed to do some research.

Not quite everything seemed very clear but we decided to proceed without a delay.

Prototyping was successful and we were sure that the deal is almost done, but we realized that we were not alone…

We were even more inspired after acquaintance with our new friends and one of us accidentally discovered new feature. We were not ready for this…

Later we realized that we should be more attentive to new friends. Not everything was as flawless as it seemed at first sight.

We discovered that even things we do every day like going to sleep and waking up might cause troubles. So we experimented…

Sometimes even simple things required extraordinary solutions.

But we were always satisfied with the result!!!

On the whole there were lots of fun.

And finally we did it!

Introducing!!! iRemote for Android!!!

PS
And when everybody was ready to go home, one of us brought some chocolate and there was a party!!!

PSS
And now the only question excites us. What is going on next?

Tags: Android, iRemote

From the perspective of ordinary developer Android seems to be really good platform. Those who cry about fragmentation, different devices, etc. etc. just never launched Eclipse in their life (and never wrote BlackBerry apps). Above is what I thought about this platform 20 minutes ago. And the fact that multitouch is really MULTI only in bounds of one view crosses out everything. I see that it works good (I mean precision of gestures translation into OS callbacks) on most devices and it makes me even more sad. How come? You (Android team, all and sundry) did so many things to make developers’ life easier and finally decided to spoil it. Everyone know how to implement it correctly, when you (platform in this case) operate with hierarchy of views. Just bind events to views with any sort of hit-testing approach and you are done. Remaining part is set of helpers to deliver only appropriate events to each view. I did it in a week, when I was working on input subsystem of OpenGL framework for multitouch-enabled devices. In our 10-maximum-fingers-world all above mentioned algorithms are fairly fast on 1GHz (almost dual-core) CPUs.

UPDATE: Android 3.0 (API level 11) seems to have this feature integrated (android:splitMotionEvents and android:windowEnableSplitTouch).
Now the question is when will Google announce its strategy on separation (or merging) of OS branches for phones and tablets. Currently Honeycomb is tablet-only platform.

Tags: Android, Multitouch

I know there is a guy, who can’t wait for this feature to become available for thousands of WP users. And by happy coincidence he has a birthday today!

Alternative content

Tags: Glympse

I decided to start my AppStore experience with iRemote because this utility most clearly shows the direction of my current research in software development from both technological and conceptual perspectives.

iRemote Suite official page gives detailed description on its functionality and features. In this post I’m going to touch architectural aspects and briefly describe application perspectives.

Stack of utilized technologis gives the best impression about core idea of iRemote/Remote PC architecture, from my point of view.

The mainstream of this project is the separation of platform dependent concurrency and networking tools. CommonKit library (which is now in process of active development) was used for building object, concurrent and networking model of both applications (iRemote for iPhone OS and Remote PC for Windows).

Here I’d like to share my plans on iRemote perspectives. Portability is mainstream tendency for now. And the first thing I’m going to do is to publish Remote PC for MacOS X. This is caused by high amount of Mac users among iPhone owners. The development of Linux version of this tool has rather low priority. What concerns iRemote, it is difficult to preffer any mobile platform. I consider the following candidates: Blackberry, Windows Mobile and Android. But I don’t know yet which one should be the first. I think that statistics, on which one of these platforms is the most widespread, does not matter in this case. Besides, I should note that I do not plan to publish desktop client for Remote PC. This is caused by a number of reasons. One of them is that the philosophy of my application stands too far from fully featured control over another workstation (from desktop, not from mobile device).

Of course, porting is not the only tendency of the solution evolution. In nearest time I’ll focus on extending functionality of iRemote for iPhone. Most likely is that iRemote Pro will appear wih extended feature set. These new features will be fundamental (not just a couple of new buttons, hot keys, etc.) but exclusively within application mainstream: remote control over workstation via mobile device based on custom protocol. This underlines the fact that I don’t plan to support any existing interaction protocol (like Remote Desktop or VNC).

Tags: iPhone, iRemote

Looking through the set of tools, APIs and advantages for developers of Research In Motion products it is difficult to disregard the care of the platform. Someone may ask: “Have you ever seen a developer who intentionally decreases potential attention to his product?” Of course, the answer is generally – “No”! But. After having a challenge round the iPhone development I can surely say that it is possible. No matter what the reason was but Apple intentionally locked a set of potentially interesting and popular features to regular developers. Thoughts?

• Paying attention to the quality of the software. Maybe they decided that they can control the quality of the software by giving rights for using private frameworks to individual groups? Wrong decision. It is much more efficient (but more difficult and expensive) to perform at least minimum stability evaluation at the side of content provider (Apple Application Store). Instead of preventing access to important framework they would better to confess and proclaim something like “Do not use Quartz for 2D game development! Use OpenGL!”. Or any other of tons of other confessions they should do.

• Overwhelming desire of getting as much profit as possible. You definitely can use embedded (but locked into private framework) map component if you become their friend. What you should do to achieve such a title? $?

• Anxiety about the future. Maybe they afraid to lose their endless stream of bright ideas. In this case they will probably integrate video calls, video recording, mms,… (other tons of things you would like to add goes here). Have you seen a picture illustrating differences between iPhone (2008) and stone (40,000 B.C.)? (Ask Google for “iPhone vs stone”).

Make sense?

In any case, platform understanding comes in at least mouth or two but even after first glimpse at BlackBerry platform I can express it as “I see what to do attract potential users and to occupy the niche”. Business smart phones in North America is more then just interesting ($) target group.

What really attracts attention from the development point is that the whole stack of technologies is based on existing standards. It looks really stable, reliable and safe. This is a really good example of achieving business benefits through architecture based approach. If you decide to build safe device you have to start with the development of safe platform. Someone may argue that it is too simple and obvious to even notice it. But why do so many of us (starting from platform vendors and finishing with developers) make so much wrong decisions, if so?

Tags: BlackBerry, iPhone

“It is always sorrowful to see a whale dying…” This phrase doesn’t exactly reflect my current state but similar thoughts involuntarily come with understanding that you should not deal with anything for the whole life to do it better than someone who has just got started. It often happens when the beginner cames with bright ideas, clear understanding of the situation and… when the beginner is Google…

Today I’ve reinvented Google Code for myself. After visiting some pages related to projects hosted by this resource I finally decided to create a mirror of Common Kit there. And as the result I’ve just published news at SourceForge on moving the project to Google Code. I’m not going to write a novel on differences between these resources but I want to point some major advantages of the service provided by Google:

• Easy to use
• Lightweight UI
• Complete lack of advertising
• SVN as a code version control system

It is difficult to tell whether the situation is similar to the one occurred with search engines (taking into account that SourceForge is 6 years older and the fact that it hosts approximately 180,000 projects). But at the moment I don’t see any reason to host a new project using this Titan. It is much more preferable to take advantage of Google alternative.

Tags: Code, Google, SourceForge

What is more important?? It’s up to you to decide… but it is indisputably that owners of 1.x iPhones would not be satisfied with firmware update while comparing their device with renewed one which is twice cheaper.

Key features of iPhone 2.0 presentation made by Apple CEO Steve Jobs (http://events.apple.com.edgesuite.net/0806wdt546x/event/index.html) at WWDC few days ago are listed below:

• 2.0 firmware release (with new features embedded in well known software).
• 3G iPhone with GPS onboard.
• Several comments of enterprise clients on platform successfulness were given.
• Several betas of third party software were presented by especially invited developers.
• Application distribution schemes (App Store, Enterprise, Ad hoc).
• MobileMe feature was introduced (this feature is not free(!), but “extremely” useful).
• New service which allows developers to avoid need in background processes.
• Maps application with GPS.

Most of these events, releases and features are timed to the 11th of July.

PS I’m practically sure that second (front) camera will be onboard in nearest future.. Not tomorrow, not next week but it must appear by July, 11.

Tags: 3G, Apple, GPS, iPhone, iPhone 2.0, iPhone OS, iPhone OS 2.0

I’ve recently mentioned the procedure of application uploading and launching on the device. I find this topic worthy of separate post. I involuntarily associate it with a puzzle of especially exotic kind. And what is much more interesting is that there are at least some members of my team who completely agree with me. So.. Let’s get started.

This guide is for launching your application on the iPhone or iPod Touch device. All steps from this guide divided into two groups on the following criteria: steps marked with letter A are performed by team administrators and those marked with C must be complied by your customers (or someone else to whom you would like to provide an opportunity to launch your applications on device during beta period).

I’m not going to describe here the meaning of all terms, software and other stuff. This is just step-by-spep guide for people who has direct access to the platform and is responsible to resolve such troubles.

1. A Add team member.

Follow Program Portal -> Team -> Manage -> Add to add new team member (full name and email address fields are required).

2. C Accept an invitation.

An invitation is being normally sent to your customer via email specified by admin during making request. Check your email and follow provided link to accept an invitation. Just press Submit button on the resulting page to complete invitation procedure.

3. C Request certificate.

Follow Program Portal -> Certificates and perform all required actions to request certificate. You should also notify your admin after you are done with this step to avoid delays.

4. A Approve certificate.

Follow Program Portal -> Certificates and approve new team member’s certificate.

5. C Download certificate.

Follow Program Portal -> Certificates to download certificate once it has issued status.

6. C Firmware upgrade.

You can download firmware for both iPhone and iPod touch from within you approved member’s account. Follow complete Apple guidelines on firmware upgrade (Program Portal -> Development -> Installing OS X iPhone).

7. C Send your device id to program administrator.

You are not able to register your device yourself because the limitation applied each account during beta period (only 5 devices are allowed to be attached to an account at the moment).

Connect your upgraded device and follow XCode -> Window -> Organizer to copy your unique device id. Email it to your admin. You should also specify the name of your device.

8. A Register customer’s device.

Follow Program Portal -> Devices -> Add to register customer’s device.

9. A Add customer’s device and account to corresponding provisioning profile.

You should also specify App Id you want to attach to this profile. You are allowed to associate each provisioning profile with one of your App Ids.

An App ID is a unique digital fingerprint that OS X iPhone uses to grant your application access to a portion of the Keychain and is one part of your Development Provisioning Profile. In order to install your application on an OS X iPhone based device, you will need to create an App ID for each application you are developing.

10. C Download and install provisioning profile.

Follow Program Portal -> Provisioning and download profile (the one with your device and certificate attached to). After you are done, copy profile to “/home/<user>/Library/MobileDevice/Provisons”. You’ll probably have to create these directories.

11. C Connect your device.

12. C Check whether the provisioning profile you’ve downloaded is correctly installed.

Launch XCode and open Organizer window. You’ll probably need to enable the profile you’ve just downloaded (see Provisioning section).

13. C Add application you want to launch to the device.

Press «+» button at Applications section to upload application to the device.

And now I’m going to describe the purpose of various most important steps.

• Achieving certificate. This step is required to have possibility to build your application for device. The certificate is being used on the stage of signing the code.
• Upgrading firmware. This step is required because significant changes can be found even between adjacent versions (beta’s) of iPhone SDK. And it is principally impossible to launch you app under 1.x firmware.
• App signing. This stage is actual only for developers. Customers should not carry about it. Application identifier is being created using administrative account and the project must be correctly configured to be launched on the device with correct provisioning profile installed.
• Provisioning profile. The profile unites information about set of devices, development certificates and application id. As it follows from the definition it is required to launch the application on the device.

And.. If just anything of this guide appears useful it means that I’m right and Apple has thought up a new quest.

Tags: Firmware Upgrade, iPhone, iPod Touch, Setup

I’ve spent last few weeks focusing on team leadership in the area of iPhone development. So I’d like to share some steps of platform submission formation from the point of view of cross-platform C++ developer:

• Everything is completely new and incomprehensible (this stage precedes the moment you launch XCode for the first time).
• The first impression on the development environment can be expressed in single question :”Where are the tabs??” From a position of last time I can tell that the rests can reconcile to all.
• Language syntax is unusual and shapes ambivalent attitude to it.
• Detailed acquaintance with API follows further (in my case it occurred in process of creating demonstration of simple 2D game and LBS application a little bit later) and brings some gusts of wind of change.

And so the verdict is… Impossible to estimate this platform uniquely. It s neither “good” nor “bad” in terms of software interfaces happily (I essentially do not shake the user interface). It is just different… No comments any more.

The only thing I’m going to add is that I was not kept and have built and run tesseract project under iPhone (http://code.google.com/p/tesseract-ocr/). As it follows from the list of supported platforms “the code should be running on Mac platform”. And it was actually so. There were no serious troubles except several small slips. And here I’ve met the next one moment of my genuine surprise. My colleague (not a developer, but true Mac fan) asked me “What is it?” pointing out the open terminal window. Many thoughts…

The next point of the discussion is involuntary analogy between Cocoa API and .Net Framework appearing at the first sight. And I mean not a set and functionality of program interfaces, but mostly a similarity of concepts, and possibilities given by a platform for construction of superstructures of higher level.

Going into historical background we can see that Microsoft has begun platform working out in the late 90-th, and the release of the first version has taken place in the beginning of 2002. Apple in turn has got NeXT in 1996 and as a result for today all high level frameworks of Mac OS and iPhone OS are implemented in Objective C (now it is already Objective C 2.0). So who is pursued? Does the transformation of a platform with the use of high level API with a doubtful indicator of convenience already becomes a norm?

It is difficult to estimate commercial success of the new platform (iPhone OS), however, hundreds of third-party applications are already published even before the official platform release (visit http://iphoneapplicationlist.com/ for more details).

Nowadays iPhone SDK (beta 6) is free and publicity available from apple.com. An extract from one of Apple press releases is given below:

Apple plans to release the final iPhone 2.0 software, including the iPhone SDK and new enterprise features, as a free software update for all iPhone customers by the end of June. Third party applications created for the iPhone will also run on the iPod touch, and iPod touch users will be required to purchase a software update to run these applications. The free beta iPhone SDK is available immediately worldwide and can be downloaded at developer.apple.com/iphone/program.

At the same time only US residents have possibility to receive the status of official developers for today (during beta period). And only those who has got it, know what that means to pass all stages of the guide on an application launch on the real device

Tags: Apple, iPhone, iPhone OS, Mac OS, Objective C, Software Development