Archive

Archive for the ‘tools’ Category

Accessing resources in an AndroidTestCase

April 18, 2011 4 comments

I am currently writing some tests for low-level (not UI) classes, using AndroidTestCase. These tests need a variety of pre-configured input files, and I though it would be very convenient to provide these as assets packaged with the test application.

Adding the files as assets to the test application was the easy part, while getting access to them from a subclass of AndroidTestCase required a bit of work.

The base class, AndroidTestCase, has a method, getContext(), but it can’t be used to load assets from the test package, because that context refers to the package under test.

Checking the source for AndoridTestCase, I found these two very promising methods:

// AndroidTestCase
    /**
     * Test context can be used to access resources from the test's own package
     * as opposed to the resources from the test target package. Access to the
     * latter is provided by the context set with the {@link #setContext}
     * method.
     *
     * @hide
     */
    public void setTestContext(Context context) {
        mTestContext = context;
    }

    /**
     * @hide
     */
    public Context getTestContext() {
        return mTestContext;
    }

I only needed the getter method, actually, still – it’s marked with “@hide”, which means it can’t be called by applications.

The @hide marker is enforced by not including the method in Android.jar that applications are compiled with. So this method is present on the device, and does what is needed, but is intentionally made inaccessible to applications. I don’t know the reason why, especially considering the comment above the “set” method.

Ok, whatever the reason is… Time to use Java Reflection to access that context.

public class MessageProcessorTest extends AndroidTestCase {

	private final static String TAG = "MessageProcessorTest";

	private Context mContext;
	private AssetManager mAssets;

	@Override
	protected void setUp() throws Exception {
		super.setUp();

		try {
			Method m = AndroidTestCase.class.getMethod("getTestContext", new Class[] {});
			mContext = (Context) m.invoke(this, (Object[]) null);
		} catch (Exception x) {
			Log.e(TAG, "Error getting test context: ", x);
			throw x;
		}

		Log.i(TAG, "Own context: " + String.valueOf(mContext));

		mAssets = mContext.getAssets();
	}

	public final void test_MessageProcessor_1() {

		try {
			String[] list = mAssets.list("dirname");
			for (String s : list) {
				Log.i(TAG, "Source: " + s);
				InputStream stream = mAssets.open("dirname/" + s, AssetManager.ACCESS_STREAMING);
				runOneTest(stream);
				stream.close();
			}

			Log.i(TAG, "End of test");
		} catch (IOException x) {
			Log.e(TAG, "Exception during testing", x);
			fail();
		}
	}

	private static void runOneTest(InputStream stream) {
		// Run a test driven by the data in the stream
	}
}

And here it is. I can now put my data files under assets to supply a variety of data to the test function.

Advertisements
Categories: android, tools

Eclipse 3.6 SR2 is out

February 27, 2011 Leave a comment

Eclipse Helios 3.6 SR2 has been released. Get yours at the usual place.

The bug that was causing code assist freezes with large JavaDoc files is supposed to be fixed, but I would not know, because I got so used to having Android source installed! Great for exploring how things work, especially with Eclipse’s fast and easy way to open any Java class.

Try this (if you have the sources installed, pre my earlier posts): press Ctrl+Shift+T, enter “Activity”, and press Ok.

I’m already running this new Eclipse version, with the memory limit increased to 512 MB through eclipse.ini:

-startup
plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222
-product
org.eclipse.epp.package.java.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
512M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
512m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m

Still on my mental to-do list: to try 64-bit Java and Eclipse (I’m running Windows 7 64-bit). The rest of my specs: Intel i860 CPU, 4 Gb of RAM, and a Corsair V128 SSD.

Categories: android, tools

“Jump to declaration” in Eclipse with Android ADT 9.0

January 29, 2011 Leave a comment

ADT 9.0 has a new feature: it lets you jump to the Android declarations of various resources.

I really wanted to use it, and tried pressing “F3”, which is the standard Eclipse way of jumping to a Java declaration. Right? Wrong!

Next I checked a few other places where this feature could be, like the “Navigation” menu. Not there, either!

Ok, here is the trick. At the risk of sounding like Capt. Obvious:

Capt. says "Hold down Ctrl"

You’ve got to hold down Ctrl while hovering the mouse. This pops up a a nice little menu, which lets you choose between jumping to the Java declaration (which is not too useful for R.id values) or to the actual declaration in an Android-specific XML file.

Categories: android, tools

Installing Android sources into Eclipse for debugging

January 27, 2011 3 comments

A couple of weeks ago I installed Android sources into my Eclipse environment. My primary motivation was to get JavaDoc comments in code assist, but those sources were also picked up by the debugger.

The problem with mismatched Android version sources

It’s pretty common when developing for Android to build the application with one version of Android SDK and debug with another (typically earlier) version. My environment is no exception: I build with Android 2.2 SDK, and debug on a Motorola Milestone that runs 2.1update1 (which will never be updated to 2.2, but that’s another story). This means that the sources installed for JavaDoc and code assistance are, strictly speaking, not the right ones for debugging, as you can see in the screenshot below:

performLaunchActivity vs. startActivityNow

The debugger says the application is stopped inside performLaunchActivity, but the source window shows startActivityNow. Let’s fix that.

Getting the right sources (again)

My development phone is a Motorola Milestone running 2.1update1, so I needed to find the right (or close enough) version of the base Android framework in the repository here:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=summary

I found what looked like 2.1update1 for my Milestone at the bottom of that page; it was a branch called “eclair-sholes-release2” (“sholes” being the codename for Motorola Droid / Milestone architecture, and assuming that “eclair-sholes-release” was the first 2.1 release).

sholes-release-2 branch

In addition to the list of branches, the page also has a list of tags, which is another place to look for a particular version of Android.

Clicking on “eclair-sholes-release2” took me to this page:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=shortlog;h=refs/heads/eclair-sholes-release2

which doesn’t have a download link, so I replaced “a=shortlong” with “a=snapshot” in the URL:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=snapshot;h=refs/heads/eclair-sholes-release2

Source code from major release-specific branches can be downloaded like this:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=snapshot;h=refs/heads/froyo;sf=tgz

You can get other versions by changing the branch name (froyo) in the link above (to donut, gingerbread, etc.)

Extracting the sources

This is how I extracted the sources on my computer, nothing special:

Extracting the sources

Pointing the debugger at the sources

The debugger has its own setting for source code lookup, which is separate from the “source attachment” to android.jar used before. To set this, switch to the debug perspective, then right-click on your running application, and select “Edit Source Lookup”, then proceed as shown below.

The left screenshot below also shows a deliberate error I made in one of my layouts, by having a ScrollView with more than one child, thus making my application crash.

The right screenshot shows how to select the right folder where Android 2.1u1 sources were extracted.

Bringing up debugger source lookup

Selecting the sources directory

This completes the setup.

The right source code version shown after a crash

This is what I get now instead of the misaligned source code shown near the top of this page. Looks like a pretty significant improvement to me:

Matching sources and variables

Categories: android, tools

Fixing slow code assist for Android in Eclipse Helios – update 2 (and getting Android sources into Eclipse, too!)

January 15, 2011 5 comments

As you can see from my previous posts, getting code assist to work well for Android projects in Eclipse Helios can be done in one of two ways. You can either uninstall Android JavaDoc package and lose method and parameter descriptions in code assist, or install a patched eclipse JDT plugin.

There is a third way, and you get Android sources for easy referencing and debugging too. Best thing, it’s really simple and only takes three steps.

Update January 29, 2011: make sure to also check out this post, which shows how to build with one version of Android and debug with sources for another.

1 – Get Android framework sources

If you don’t build Andorid system images, and don’t have Git and repo tool, get the sources from http://android.git.kernel.org as a tarball.

This is the framework tarball for Froyo (108 Megabytes):

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=snapshot;h=froyo;sf=tgz

You can get other versions by changing the tag (froyo) in the link above (to donut, gingerbread, etc.)

2 – Extract a portion of the tarball into the right place

Eclipse wants sources in the right place, organized by package name, the same way the source code for your project is organized.

That right place is a “sources” directory that you should create under your android-sdk-windows\platforms\android-VERSION.

Open the tarball with your favorite program (I use WinRar) and navigate to core\java inside it. You will see a directory called “android”, which looks like this:

Now you need to extract the “android” folder inside the tarball into android-sdk-windows\platforms\android-VERSION\sources, so you get this:

3 – Verify the settings for Android.jar and hit refresh

Right click on android.jar in your project, and verify the location path:

After closing this dialog, refresh your project (press F5 in the project explorer or right-click on your project and choose Refresh).

And this is what we get from doing the above

JavaDoc in code assist

The ability to view Android framework sources right from Eclipse

… which also works in the debugger

And that’s it. With many thanks to http://android.opensourceror.org/2010/01/18/android-source/

Categories: android, tools

Fixing slow code assist for Android in Eclipse Helios – update

January 15, 2011 3 comments

The issue with JavaDoc causing code asssist freezes is indeed a problem in Eclipse Helios (not in Android JavaDoc files).

This is fixed for 3.7:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=329288

There is a back-port of this fix for Eclipse 3.6 SR1, discussed here:

http://groups.google.com/group/android-developers/msg/0f9d2a852e661cba

Applying the fix is easy, you just replace org.eclipse.jdt.core_3.6.1.v_A68_R36x.jar inside your Eclipse plugins folder with the file provided in the above message.

Here is a direct link:

http://adt-addons.googlecode.com/svn/patches/org.eclipse.jdt.core_3.6.1.v_A68_R36x.zip

I submitted a request for this fix to be released with 3.6 SR2 , coming at the end of February. I’m keeping my fingers crossed.

Update: fix is scheduled for Eclipse Helios SR2, coming February 25.

See here for more details

Categories: android, tools

Fixing slow code assist for Android in Eclipse Helios

January 14, 2011 Leave a comment

This applies to Eclipse Helios 3.6 SR1 and Android tools 8.0.1.

There are three causes for slow code assist, and here is how to fix them:

1. Eclipse looking for “sources” folders under platforms\android-VERSION. This was actually fixed in ADT 8.0.x, but I’m reporting it here for completeness.

The fix/workaround was to create empty directories called sources under platforms\android-VERSION. Apparently, with 8.0.x, it’s no longer necessary.

2. The widely mentioned issue with something called JAX-WS in the Java EE version of Eclipse.

The fix is to disable JAX-WS assist in the edit/advanced preference: Window->Preferences->Java->Editor->Content Assist->Advanced.

3. Finally, there is an issue when code assist uses JavaDoc files installed as part of a new Android SDK package, “Docmentation for Android SDK, API 9, revision 1“.

I decided to uninstall the Documentation package, and this fixed slow code assist for me. It also removed information from JavaDoc in code assist, but until there is a fix, that’s probably the best that can be done.

According to this post:

http://groups.google.com/group/android-developers/msg/a6d85ef283f21e0c

this is an issue in Helios, not in Android documentaiton.

Categories: android, tools