Well, glad to see it is voled in the end.

So, after all that, the problem was to do with Flurry.

I wasn't using the correct context to set up the session for that activity. Was using 

FlurryAgent.onStartSession(this, <id>);

instead of 

FlurryAgent.onStartSession(ARActivity.this, <id>);

Gaah!

I'll try that when I have some more free time. I'm just going to tell the client that the Kindle can't run this complex an AR app for the moment.

I'm thinking it might have as much to do with Amazon's proprietary implementation of Android as anything else. Maybe they do something weird when setting up view heirarchies.

Thanks for all your help - hope I wasn't too annoying!

Yes, the last implementation looks correct;  

if you still see the issue, then there must be something else going wrong in the project; have you tried implementing the same technique starting from a fresh new Vuforia sample like ImageTargets or Frame Markers ? 

Ok, this time I think I got it.

	public void onResume() {
		super.onResume();
		if (mQCARView == null) {
			// search the QCAR view

			handler.postDelayed(new QCARViewFinderTask(), 1000);

		}
	}

handler posts on the UI thread in onResume;

and

	class QCARViewFinderTask implements Runnable {

		@Override
		public void run() {
			if (!QCAR.isInitialized())
				return; // wait for QCAR init
			if (mQCARView != null)
				return;// already found, no need to search
			// else search
			View rootView = ARActivity.this.findViewById(android.R.id.content);
			QCARUnityPlayer qcarView = findQCARView(rootView);
			// if QCAR view has been found, add some android view/widget on top
			if (qcarView != null) {
				...

			}
		}

the search is run in a Runnable.

Still same symptoms - HTC One is fine, Kindle finds no qcarView

No, what I mean is:

- do not use the Thread class (and if you have now removed it, that's fine)

- use the Handler and remove the Timer / TimerTask 

In your latest code you are using the Handler inside the TimerTask; this is not correct (just get rid of the TimerTask)

In the prvious version of your code, you were using the Thread class for some reasons (do not use the Thread class).

Sorry I misinterpreted - I thought you meant remove the Timer stuff completely when implementing the Handler.

So now I have,

	public void onResume() {
		super.onResume();
		if (mQCARView == null) {
			// search the QCAR view
			viewFinderTimer = new Timer();
			viewFinderTimer.scheduleAtFixedRate(new QCARViewFinderTask(), 1000l, 1000l);
			
		}
	}

and 

	class QCARViewFinderTask extends TimerTask {
		@Override
		public void run() {
			handler.postDelayed(new Runnable() {
				
				@Override
				public void run() {
					if (!QCAR.isInitialized())
						return; // wait for QCAR init
					if (mQCARView != null)
						return;// already found, no need to search
					// else search
					View rootView = ARActivity.this.findViewById(android.R.id.content);
					QCARUnityPlayer qcarView = findQCARView(rootView);
					// if QCAR view has been found, add some android view/widget on top
					if (qcarView != null) {

						...

					}
				}
			}, 1000);
		}

and I still have the same symptoms - runs fine on HTC One, but fails on Kindle with no QCarUnityPlayer child.

Ok, thanks for sharing the code; actually the problem is that you are using the Thread class:

new Thread(new QCARViewFinderTask()).start();

Implementing with postDelayed doesn't seem to make a difference, even with a delay of 10s.

Maybe it's my implementation.

I'm instatiating the handler in onCreate()

handler = new Handler();

calling the task in onResume()

if (mQCARView == null) {
    // search the QCAR view
    //viewFinderTimer = new Timer();
    //viewFinderTimer.scheduleAtFixedRate(new QCARViewFinderTask(), 100l, 1000l);
    new Thread(new QCARViewFinderTask()).start();
}

class QCARViewFinderTask implements Runnable {
   @Override
   public void run() {
   //ARActivity.this.runOnUiThread(new Runnable() {
   handler.postDelayed(new Runnable() {

      @Override
      public void run() {
         if (!QCAR.isInitialized())
            return; // wait for QCAR init
         if (mQCARView != null)
            return;// already found, no need to search
         // else search
         View rootView = ARActivity.this.findViewById(android.R.id.content);
         QCARUnityPlayer qcarView = findQCARView(rootView);
         // if QCAR view has been found, add some android view/widget on top
         if (qcarView != null) {
            ...
         }
      }
   }, 10000);
}

The logs indicate a threading issue; basically the app is trying to modify the view hierarchy from the wrong thread;

my guess here is that the use of the TimerTask and Timer is causing the issue; 

I would suggest to try the Handler approach (as I previously suggested), using the postDelayed() method; also, when you use the Handler, make sure to create the Handler in the main UI thread, for instance create it inside the onCreate() or the onResume() methods of the main activity.

Also, if using a Handler which has been created in the main UI thread, you will not need to use the runOnUIThread() method, which is shown in the tutorial.

If approproately implemented, this should resolve the threading issue.

Actually, I spoke too soon.

Even after reducing the number of models to get rid of the out of memory crash, the Eclipse modified app still crashes on the Kindle - so the initial problem I posted about is still there.

I tried your suggestion of using a Handler, but it made no difference.

All the info in my initial post is still relevant, but I never posted the actual error from Logcat.

Here it is, if it helps:

Of course, that was the question I should have asked myself before asking the forum :)

I just installed the Frame Markers sample, and it worked perfectly well.

Playing around with my project a bit more, I removed a frame marker from the scene (there are 3 frame markers and each has 2 or 3 complex animated models that are set to active/inactive through on-screen buttons) and the app ran the way it should. So it looks like it's definitely a memory resource issue.

Thanks for your help anyway!

Do you see such a problem with our samples too ? or just on your custom application ?

Would the device really be running out of memory? It has 1GB of RAM, same as the Nexus 7 and more than the HTC Desire HD (768MB) 

Thanks

Jase

That's a bit weird; the only thing I can think of is a threading issue; 

one thing you could try to use a Handler (use the post() method) instead of the Timer, so to execute the view search with some delay, see :

http://developer.android.com/reference/android/os/Handler.html