android.bat -> NullPointerException for making AVD file !

by Matt AndroidFun » Thu, 30 Apr 2009 02:52:17 GMT


Sponsored Links
 hello Peter,


thank you very much! It solved my problem too.

Regards

2009/4/29 peter.kullm...@googlemail.com <peter.kullm...@googlemail.com>


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



android.bat -> NullPointerException for making AVD file !

by Raphael » Sun, 03 May 2009 06:23:17 GMT


 Thanks, this is fixed and will be in the next version (and no, I do
not know when that is.)
R/




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


Sponsored Links


Other Threads

1. pricing model on a service based android application/game?

I do understand that a self sufficient or standalone android
application
can be bought/sold for one time price.

But what are various ways a user can be charged if an android
application
was a service based application, meaning every time user playing a new
game
would fetch some data from a service.
It seems to me that the pricing model should be on usage bases,
be it periodically (monthly/yearly) or be it per use.

As an hypothetical example, if using gmail on a g1 has a price tag,
what options would
the google team may have, in terms of making users pay?

Can someone please throw some light on the subject?

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

2. Gallery pain

Hello everyone!

I have recently been working with the Gallery (SDK1.0_r2) and have
found the following 3 issues, the first 2 of which have caused me a
fair amount of pain:

1. not having a callback on the 'last item selected' in the gallery
during a fling and/or scroll,
2. Gallery layout change when setSelected(position) is called results
in layout changes for other views of the activity displayed,
3. a 'nothing-selected-state' after a fling with no item selected (in
the middle).

Issue #1 is a feature request.

Let me elaborate; possibly I am missing something and someone more
knowledgeable may shed some light for me on these things. I would be
very thankful for that.

My main layout consists of a simple Gallery 'bar' on top (with a few
TextViews in its adapter), and a SurfaceView below the Gallery,
filling the rest of the screen.

(1.) In my application, when an item is selected in the Gallery, the
Surface below it must be updated. This update does not take too long
to complete, but it takes long enough to make the 'fling' of the
Gallery not perfectly smooth. I am already setting
setCallbackDuringFling(false), but this only hides selection events of
items in between the second and last items selected. I figure this is
because at the beginning of a fling android does not yet know if it is
going to be a fling or just a simple scroll to the side. However, i
really hated those small hickups in the otherwise nice&smooth fling
animation, so I have implemented a crazy scheme, tracking scrollstates
and touch events with delayed message-sending/handling to achieve what
I needed: a single event being fired when the final selection on the
Gallery is made during either scroll or fling motion.
I'd like to suggest adding API support necessary to handle this kind
of event, as I believe others might use it too. (NOTE: try switching
the background on your phone: the wallpaper gallery suffers from the
same kind of hickup I am describing - doesn't it annoy anyone but
me?! ;)

(2.) In another scenario my application needs to select an item of the
gallery, while doing some CPU intensive tasks updating the Surface
below it. On the Surface I am making use of SurfaceHolder.lockCanvas
(DirtyRect) @ 30FPS and again, everything is fine and smooth, until
the selection in the gallery messes up my Surface buffer. It appears
that the Gallery.setSelection(pos) call fires off a requestLayout()
event (inherited from AbsSpinner). For reasons unknown to me, this
later results in some kind of layout invalidation of my SurfaceView as
well. The surfaceChanged() callback of the SurfaceHolder is called and
I seem to loose valid pixel regions of one of the two buffers of the
Surface as a result. The next frame thus displays with some black
pixels, where the previously locked dirtyRect region is replaced with
a full surface lock(); my SurfaceView area blinks. Just a single
fr...@30fps, but still: ugly.
After a considerable amount of time I realized that a
Gallery.setSelection(pos, false) call does NOT result in this layout
madness. I dont care for animation, so this workaround is acceptable
for now. I just dont understand, why a regular setSelection on a
Gallery should invalidate the layout of other views. I think it should
not.

(3.) At least two times during testing I have managed to stop the
gallery fling in a state where NO item was selected. In this state
there was also no item centered, meaning two of my items in the
gallery where equally close to the 'center' of the gallery bar.

Anyone else experiencing these issues? Are there any known/better
solutions to them? Any comment will be greatly appreciated.

-Szabolcs

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

3. Touch screen slowdown

4. Problem loading KML in DDMS view of Eclipse

5. OnGestureListener vs ContextMenu, do they play together?

6. Clear All Notifications called implicitly?

7. Move Apps to /system/app