SDK-1.5 Emulator does not find skin

by Wilfried Kopp » Thu, 30 Apr 2009 02:05:56 GMT


Sponsored Links
 Hello,

Screens beeing always too small :) I am trying to use a skin without any
keyboard.
I got it here :
 http://sacoskun.blogspot.com/2008/09/android-emulator-skin-without-keyboard.html 

I am copying the BILGICIFTLIGI-LAYOUT-P folder inside
D:\android\tools\lib\images\skins (please note my system is on D:\...)

When running the emulator, I get such message :
[2009-04-29 13:30:30 - Emulator] emulator: ERROR: could not find directory
for skin 'BILGICIFTLIGI-LAYOUT-P', please use a different name

I tried using the -skindir option and provided the full path :
-skindir "d:\Android\Tools\lib\images\skins" -skin "BILGICIFTLIGI-LAYOUT-P"
...with no success.

If I use -skin HVGA, then it works....

I have tried on 2 different machines and I get the same result.
I also tried renaming BILGICIFTLIGI-LAYOUT-P into NOKBD (short name) with no
more success.
I have btw first tried -skin BILGICIFTLIGI-LAYOUT-P (no ") with no success.

Anyone would have a hint ?

Regards,
Will

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



SDK-1.5 Emulator does not find skin

by swarup » Thu, 30 Apr 2009 15:04:50 GMT


 > I am copying the BILGICIFTLIGI-LAYOUT-P folder inside

this is not going to work for SDK 1.5
try copying your skin folder to SDK_HOME\platforms\android-1.5\skins,
SDK_HOME\platforms\android-1.1\skins, depending upon your AVD target.




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


Sponsored Links


Other Threads

1. Odd size Dell Aero screen: 360x640 px

Dell's first US released smart phone was released today. It has this
odd sized screen of 360x640px. I really wonder what that's going to
look like with the average app?

On the plus side, it's light and inexpensive ($300 without contract).

On the negative side it's on AT&T, has a miniscule battery (1000 mAh),
slow processor (624 MHz) and runs Cupcake (1.5) of all things.

Maybe Dell can do better next time.

-John Coryat

-- 

2. Native crash (SIGSEGV) in open gl texture load

Hi all,

I have posted previously on a related topic, but thought a new post
with clearer descriptions may trigger someone out there with some
knowledge.

I am getting regular crashes in native (android) code when I am
loading textures in opengl.  Trace is:

Build fingerprint: 'generic/sdk/generic/:1.6/Donut/20842:eng/test-
keys'
pid: 196, tid: 331  >>> com.cc.ra <<<
signal 11 (SIGSEGV), fault addr 00000104
 r0 00000104  r1 000003d8  r2 00000104  r3 ac126bb8
 r4 00211f20  r5 00000100  r6 ac128344  r7 4251fe84
 r8 45d69da0  r9 4251fe7c  10 4251fe6c  fp 00000001
 ip ac1285f4  sp 45d69d48  lr ac03ce10  pc afb04408  cpsr 20000010
         #00  pc 00004408  /system/lib/libcutils.so
         #01  lr ac03ce10  /system/lib/libsgl.so
stack:
    45d69d08  0015fab8  [heap]
    45d69d0c  00000001
    45d69d10  00000007
    45d69d14  ad047361  /system/lib/libdvm.so
    45d69d18  00000000
    45d69d1c  0015fab8  [heap]
    45d69d20  0033e650  [heap]
    45d69d24  ad03dafb  /system/lib/libdvm.so
    45d69d28  ad083e1c  /system/lib/libdvm.so
    45d69d2c  ad082c50  /system/lib/libdvm.so
    45d69d30  ad03dadd  /system/lib/libdvm.so
    45d69d34  ad02e45b  /system/lib/libdvm.so
    45d69d38  0033e650  [heap]
    45d69d3c  00211f20  [heap]
    45d69d40  df002777
    45d69d44  e3a070ad
#00 45d69d48  00211f20  [heap]
    45d69d4c  ac03ce10  /system/lib/libsgl.so
    45d69d50  ad336551  /system/lib/libandroid_runtime.so
    45d69d54  0033e650  [heap]
    45d69d58  00211f20  [heap]
    45d69d5c  ad349333  /system/lib/libandroid_runtime.so
    45d69d60  00004000
    45d69d64  00000000
    45d69d68  00211f20  [heap]
    45d69d6c  001e9ec8  [heap]
    45d69d70  00000000
    45d69d74  ac03cb30  /system/lib/libsgl.so
    45d69d78  00000000
    45d69d7c  001e9ec8  [heap]
    45d69d80  00000000
    45d69d84  ac03cb60  /system/lib/libsgl.so
    45d69d88  45d69dc0
    45d69d8c  00000000

The failure always looks the same, but doesn't always happen at the
same time.

I am loading a GLSurfaceView in a fairly standard activity, however
after several attempts I am now at the stage where in order to have an
interim loading screen rendered over the top of the GLSurfaceView (for
which I am using a ViewFlipper to flip to a standard Canvas-based
view) I am needing to completely dissolve the GLSurfaceView every time
a new "level" in the app (game) is loaded.  (This is because I am not
confident that simply flipping out the old view is causing the GL
Context to be destroyed on all devices)

When I try to create a new GLSurfaceView instance in the same
activity, then load the textures, I get the above failure.  As I said
however, it doesn't always occur in the same place.  That is,
occasionally I will be able to play through several levels (GL setup &
tear down events) without a problem, then at some point the failure
will occur.  It consistently fails, just not always immediately.

When I tear down the GLSurfaceView (via a call to removeView on the
ViewFlipper) I have verified that the surface is destroyed (hence
previously loaded textures should be removed from vram) but no matter
what sort of re-arranging of code I have tried I can't seem to avoid
this failure.

Happens on both the emulator, and device.

No JNI warnings, and no GL failures reported when
DEBUG_CHECK_GL_ERROR is enabled on the gl view.

I really need some guidance on this.  Does anyone have any clue as to
how I can resolve, or even diagnose this?

Thanks.

-- 

3. Using HttpClient

4. avira premium security 2010

5. Maybe you can use this

6. get files under certain directory

7. when to use runonuithread()? why we need to use it?