Tuesday, December 14, 2010

I saw this message for a while before investigating it. A couple of google search led me to nowhere. Basically, there were some questions on it but no answers. Given that there are probably a few ways to get into this, its probably better to figure out how to track it down.

So the message looks like the following:

Skipping entry 0x7f090003 in package table 0 because it is not complex!

A great message if there ever was one. Anyway, the first thing to do is look at the generated output. In eclipse, its under <project>/gen/<pkgname>/R.java. The R.java file looks like the following:

/* AUTO-GENERATED FILE. DO NOT MODIFY.
*
* This class was automatically generated by the
* aapt tool from the resource data it found. It
* should not be modified by hand.
*/

package fi.eye.android;

public final class R {
public static final class anim {
public static final int boxanimation=0x7f040000;
public static final int fade_in=0x7f040001;
public static final int fade_out=0x7f040002;
public static final int home_grid_fade=0x7f040003;
public static final int slide_left=0x7f040004;
public static final int slide_right=0x7f040005;

continues for a long time......

So its easy to just search for the offending value to determine what value to look for. In my case, it was a style attribute. Some items require a style with a one or more specific items defined. So in the your res/values/styles.xml file you might have something like:

The 'value' is the important bit. some item names refer to more complicated values, such as android:textViewStyle. So you can either define another style with the set of common values or replace it with a specific value such as <item name="android:textSize">14sp</item>.

Thursday, November 4, 2010

There are lots of little things that can be rather...headache worthy. ScrollView is a great little widget that with one simple entry, you get scrolling. However, depending on what you put in it, can lead to some interesting results. For instance, don't stick things like Lists in it. In my case, it was a simple EditText box that caused some issues.

Upon launch, EditText grabbed the focus causing the virtual keyboard to come up. This was due to having no available focuses, it chose my EditText box. Digging into it, the obvious solution that has many posts android:focusable="false" and the android:focusableInTouchMode="false". Of course, that doesn't help if you really want to focus on it.

The end result was to set these to false and upon click, change the modes. All to get around the issue with focus firing on this text box. Something like:

Sunday, July 4, 2010

A quick note for developers updating to Froyo 2.2. After upgrading my Nexus One to version 2.2 (FRF91), the Android Device Chooser that pops up when you try to debug your application indicates the device is an unknown target rather than version 2.2.

The Android SDK and AVD manager will indicate all has been updated (assuming you did that). The solution is to make sure you upgraded Eclipse with the latest version of the adb/ddms plugin. In Eclipse, go to Help->Check For Updates should take care of the issue.

An easy thing to overlook and my first check on Google didn't pull up anything. So maybe this will help someone else.

UPDATE: One caveat, only one usb port actually works for this. Nothing worked while trying to get the other USB ports working. I'll have to dig up another usb cable to try. There have been reports of some dodgy cables.

Tuesday, May 11, 2010

In continuing my journey into Android territory, I decided it would be useful to understand the NDK development kit. Given I want to transfer some files and possibly do a couple of other projects requiring low level work, I selected the cURL kit to port. I've used cURL for a number of projects and it is my hope it runs well under Android. The project, curltest, was run under Android 2.1 but it should work for other versions as well. Given that most Android phones will be getting upgrades rolled out over the next couple of months to version 2.1, seems like a reasonable target. I will be added HTTPS capability as soon as I port openssl, for now, this is strictly unsecured transfers.

I did see some examples of partial porting and even in the curl library source there is an Android.mk which describes how to set it up although not in enough detail. Both were helpful but didn't actually get me to the holy land of a usable test application. (http://www.mail-archive.com/curl-library@cool.haxx.se/msg03433.html was helpful but didn't work for me.)

I found it worth the exercise of downloading the full android sources and building them. Look at the build process, the bionic library, and well as what's in external. The external directory is where you would add repositories to do things like run configure to generate config.h and Makefiles.

You won't actually need Linux since I have included the config file here but in case you want to follow way it was created, I've included it.

Summary of the steps to take for this port:
- Lots of searches and view the current state of curl porting
- Setup source repository (I used Linux, you could try windows using cygwin)
- Create curl_config.h under the full android source tree
- Untar curltest.tar.gz under $NDKROOT or Create NDK JNI App on Windows
- Cross-link or add to eclipse project to build Java front-end
- Unpack cURL into $NDKROOT/apps/curltest/jni/curl
- Copy curltest/jni/curlbuild.h to curltest/jni/curl/include/curl
- Copy curltest/jni/curl_config.h to curltest/jni/curl/lib
- Build and test

Setup source repository on Linux

It's one thing to describe doing X, quite another to actually do it. Anyway, I ended up creating my own android repository to start the process. While I was using Windows 7 for my NDK development, I switched to Linux to create the curl_config.h file needed in the build. What this means it that you run a couple of scripts. First up, repo. Created a directory and cd to it. Download the repo script 'wget https://android.git.kernel.org/repo'. Move repo script to somewhere in your path and issue 'repo init -u git://android.git.kernel.org/platform/manifest.git' then after run 'repo sync'. These two should get you all the goodies. I had some stalls where I had to restart the sync process but after a long while it completed successfully.

Create curl_config.h under the full android source tree

Next, I created a script to call the configure command to generated the curl_config.h. CD to $ANDROID_ROOT/external. Untar curl libraries, I renamed my from curl-7.20.1 to just curl. cURL has an Android.mk inside of it. In the file were some instructions for generating the curl_config.h. I found them helpful as a start but ultimately I had to fiddle with a number of things to get this to actually work. Here is the script I used:

Run the script in the top curl directory (where configure resides) and it should go through many tests before ultimately creating the lib/curl_config.h file.

Create NDK JNI App on Windows

Untar curltest.tar.gz under $NDKROOT. This has the Java side application already created. Or you can simply create a new Application under Eclipse which will generated the src &amp; res directories that will need to be modified. I'm not going into App generation except that you will target $NDKROOT/apps/curltest/project as your directory tree.

Once that is done, cd to project and create your standard Java AndroidManifest.xml file. If you created an App from Eclipse you'll need to modify this file. Make sure to give it INTERNET permissions. The rest depends on what's in your Java code.

Then cd to jni and create the Android.mk file. This is where the one from cURL would go. However, I didn't use it as anything more than a reference.

Now for the actual JNI interfacing. There are lots of complaints here because everything needs to be specified up front and you need different packages for different hardware. Except for some dynamic registration mechanism, I'm not sure you can get away with writing to hardware AND getting independence from it. Actually, I am sure, you can't.

Finally, it's time to setup Eclipse to build. There are some assumptions here, like having a functioning Eclipse build environment. In order to get your environment over to Eclipse, you can use File-&gt;Import then select 'Existing Projects into Workspace' function.

Unpack cURL into $NDKROOT/apps/curltest/jni/curl. Move the curl_config.h file created above to $NDKROOT/apps/curltest/jni/curl/lib.

Finally, we create the Android.mk file in curltest/jni and build it. The Android.mk use is as follows:

Going back to your $NDKROOT you should be able to build the library with 'make APP=curltest -B V=1'. The -B means rebuilt it all and V=1 makes it verbose.

After this, you should be able to build the application. When I get back to Eclipse I'll hit F5 to refresh the files as a habit although likely not necessary. Another interesting thing is that some people have indicated that you need to do an 'adb push' to the emulator so the library is there. I haven't found this is the case. Basically, if it doesn't find your library the interface name or some other part is broken and you need to find the issue.

Thursday, April 29, 2010

As a foray into Android development it seemed a simple task to take my previous Palm Pre map application and "port" it to this environment. Given the development environments are completely different, only little bits could actually be used. Android is Java-based.

So the first step is simply getting the basic app framework going that receives GPS data. In this case, from a mock location provider that can be updated via DDMS which is the basic debugger that communicates with the emulator. I haven't touched Java in years and didn't do much with it when I did. It has the typical object oriented approach and syntax is something close to C++ so very easy to pick up. One particular irritating part of Java is the one public class/one file approach. The Java religion seems to like this aspect of the language; that of defining your organization as part of the language implementation.

It didn't take long to craft the first draft and promptly run into issues. A simple one; no mock location data. Searching the web didn't net much except that I added the Google APIs along with the standard Android ones when creating the emulator image. Once I did that, I ended up with the "Not updating R.layout.main" error after updating the project with the right API set. After cleaning, building, building, searching, eventually the solution was to delete all the import libraries and re-add them.

Ok, back to the mock location issue. The short solution - when you launch the image, click the "wipe user data" box. For whatever reason, there is some history that prevented location info from working. Possibly using a previous version of the emulator, not sure and at this point, don't care. After that, sending GPS locations via GPX, KML, or single fixes worked great. Google maps also started working again. I'll run through the steps in gory detail for the rest of the app soon. Hopefully, much sooner than my last post so long ago.