getApplicationContext returns null in test case (unless you sleep first)

by AndyM » Thu, 05 Mar 2009 02:20:38 GMT


Sponsored Links
 I have a simple androidTestCase class that has this test:

@MediumTest
public void testFoo() {
          assertNotNull(this.mContext.getApplicationContext());
}

this fails unless I sleep first, then it passes. Whats the deal?


--~--~---------~--~----~------------~-------~--~----~



getApplicationContext returns null in test case (unless you sleep first)

by AndyM » Thu, 05 Mar 2009 23:04:57 GMT


 "There are APIs to allow you to run code on the main thread to access
its objects." I'm a little confused about what APIs you are talking
about and how they would help solve this problem. Could you clarify?

To me it seems that the test runner should not be calling my tests if
the Application is not finished initializing yet.

Andy





--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Other Threads

1. SIP using bluetooth

Hi all,

What SIP softphone can use Bluetooth correctly?
I tried on 2.2.1 / Samsung Galaxy S / samsung Bluetooth HM1000
- CSIPSimple: Bluetooth volume is low
- SIP Droid: Bluetooth is not usable

-- 
RMA.

-- 
.

2. tslib patch causing Android boot to fail

Hello everybody,

we're in the progress of porting Android on a Freescale i.MX28 board.
We've got to the point where we're trying to make the touchscreen work with 
Android, so we've borrowed the patches from 0xdroid for tslib and compiled for 
our board.

Both tslib and the Calibration Test App from the donut branch work fine:
http://gitorious.org/0xdroid/external_tslib
http://gitorious.org/0xdroid/packages_apps_tscalibration

We're now trying to get the integration code in frameworks/base working, but 
it's giving us a big problem.
I've downloaded this patch:
http://gitorious.org/0xdroid/frameworks_base/commit/04c8fcb888528659d58fb6f93b01fa892ee717a4
and applied successfully to our own donut-porting branch.
Some rare times the system goes up and touchscreen somehow (that's another 
story) works:
http://pastebin.com/Ty1cHhgR
Unfortunately most of the times the system isn't able to start SurfaceFlinger 
and gets stuck into an infinite loop repeating something like:
"W/SurfaceComposerClient( 1778): lock_layer timed out (is the CPU pegged?) 
layer=0, lcblk=0x40209020, state=00000043 (was 00000043)"
http://pastebin.com/dBXCXZ4e

The problem resides in the libui.so. I've broken down the patch into pieces and 
identified what causes the problem:
- compiling libui.so by just adding the #include "tslib-private.h" in 
EventHub.h makes Android always regularly startup;
- compiling libui.so by adding both the #include "tslib-private.h" and the 
pointer declaration struct tsdev *mTS; in EventHub.h makes Android fail to 
launch SurfaceFlinger most of the times.

Does anybody know what could be causing the problem? Could we be missing 
something (we've noticed we're missing pmem support)?

Any help would be highly appreciated, thank you.

Regards,
Diego Rondini

-- 

3. Help Android porting to imx28

4. Values in Linux Framebuffer is different when bitmap file reading is forced to RGB 565

5. Video recording using inbuilt stagefright soft codec

6. honeycomb source available?????

7. Sudah Dapat --- WTB: Samsung Galaxy Mini <EOM>