Thanks for posting your findings and glad you found your bug. Less
happy for myself as this clearly indicates a bug in my code, too. Oh
well...
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
Thank for the update. I am just very glad to know that it isn't a nasty
platform bug. :)
On Mon, Aug 30, 2010 at 3:49 PM, TreKing treking...@gmail.com wrote:
PROBLEM SOLVED!
Conclusion: I'm an idiot (shocked!?)
So, for those of you that care, here was the problem. I followed Zsolt's
On Mon, Aug 30, 2010 at 7:03 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
I am glad you solved it. How do you have your warning levels set? I have
mine set to the highest possible on everything and a removed line might have
been caught via unused/unitiliazed varaibles.
Me too! Probably the
Me too! Probably the defaults, but I have no warnings (except the required
minSDK warning) and it wouldn't have been caught anyway. The line that got
removed was a simple static helper function that used the current context to
delete all files in the cache directory. Removing it had no effect
On Tue, Aug 31, 2010 at 4:30 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
Yes, but if you declared the helper function private, you may have gotten
an unused warning. If it was in a different class, of course, that's no
help as the compiler doesn't check for unused package private functions,
I don't know. Every email I've gotten and all comments in the crash reports
indicate it's a consistent crash occurring 100% of the time (and in the
exact same location based on the ever-growing report count for the same
stack trace).
Clearing the data (or uninstalling / re-installing which
On Sun, Aug 29, 2010 at 8:24 PM, William Ferguson william.ferguson.au@
gmail.com wrote:
What's the taskAffinity?
Whatever the default is - I've never touched this.
I suspect that clearing the data is changing the behaviour because this
speed up / slows down one of the threads, thereby
I downloaded the app, but I couldn't get it to crash, sorry. But I
did a clean install.
What a did notice, though, was how it only loaded the bus routes (from
the web?) the first time around. Even after I killed the app and
relaunched it, the bus route list was populated without loading. So
On Mon, Aug 30, 2010 at 4:35 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
I downloaded the app, but I couldn't get it to crash, sorry. But I did a
clean install.
Thanks for trying! I can't believe I'm disappointed it didn't crash =P
What a did notice, though, was how it only loaded the bus
Since clearing application data in Android's application management screen
resolves the issue (as far as I understand from a previous message), perhaps
it would be worthwhile to try and understand what this data is, exactly, and
then follow the yellow brick road (so to speak) back to the code that
PROBLEM SOLVED!
Conclusion: I'm an idiot (shocked!?)
So, for those of you that care, here was the problem. I followed Zsolt's
suggestion to go back to the previous version and then updated the app and
sure enough it crashed.
Quick background: The app gets data from the inter webs and then
I am glad you solved it. How do you have your warning levels set? I
have mine set to the highest possible on everything and a removed line
might have been caught via unused/unitiliazed varaibles.
On Aug 30, 6:49 pm, TreKing treking...@gmail.com wrote:
PROBLEM SOLVED!
Conclusion: I'm an idiot
He he, glad you got some closure.
On Aug 31, 8:49 am, TreKing treking...@gmail.com wrote:
PROBLEM SOLVED!
Conclusion: I'm an idiot (shocked!?)
So, for those of you that care, here was the problem. I followed Zsolt's
suggestion to go back to the previous version and then updated the app and
On Sat, Aug 28, 2010 at 3:22 AM, William Ferguson william.ferguson.au@
gmail.com wrote:
From the symptoms, the code you posted and the assumption that this section
of code is multi-threaded, it looks like a race condition.
That's for the suggestion, but where the static instance is used is
Not real sure about this, just putting it out there ..
But is is possible that Activity2 is started in a separate Task to
Activity1?
I can find any doco confirming or denying, but perhaps separate Tasks
run in separate JVMs, hence the potential for non-initialization.
What's the taskAffinity?
I
Actually I should have asked whether Activity2 is being created in a
different Process as that will definitely be in a separate JVM.
On Aug 30, 11:24 am, William Ferguson william.ferguson...@gmail.com
wrote:
Not real sure about this, just putting it out there ..
But is is possible that
On Sun, Aug 29, 2010 at 6:24 PM, William Ferguson william.ferguson.au@
gmail.com wrote:
Not real sure about this, just putting it out there ..
But is is possible that Activity2 is started in a separate Task to
Activity1?
I can find any doco confirming or denying, but perhaps separate Tasks
Thanks for posting the psuedo code.
From the symptoms, the code you posted and the assumption that this
section of code is multi-threaded, it looks like a race condition.
public StaticClass {
private static Manager manager = new Manager();
public static Manager getManager() { return manager; }
I would bet any money that this is very clearly going to be a race
condition somewhere. Your code using a static Map and the user
symptoms are a dead giveaway.
I think the install/reinstall and clearing the user data are red
herrings. The app might work again for the user if they just ran it
On Thu, Aug 26, 2010 at 1:18 PM, TreKing treking...@gmail.com wrote:
On Thu, Aug 26, 2010 at 12:42 PM, Dianne Hackborn hack...@android.comwrote:
- See if having them clear data first before trying to uninstall solves
the problem.
I'll have someone try this next time I get an email and
Might be throwing in a food-for-thought curveball here but I wonder if
there's a difference between updating an app that's running and one
which isn't?
On Aug 26, 8:23 pm, TreKing treking...@gmail.com wrote:
On Thu, Aug 26, 2010 at 1:56 PM, Doug beafd...@gmail.com wrote:
I don't have anything
On Fri, Aug 27, 2010 at 10:01 AM, Carl Whalley
carl.whal...@googlemail.comwrote:
Might be throwing in a food-for-thought curveball here but I wonder
if there's a difference between updating an app that's running and one which
isn't?
Might be. It's only a handful of people (well, more than a
Yes what happens during an update is the app is first force stopped (all
processes killed, alarms unregistered, etc), then then the new version is
installed.
It seems promising that clear data would fix the problem; this is most
likely then an issue you can deal with in your app rather than
Thanks for the continued help.
On Fri, Aug 27, 2010 at 2:22 PM, Dianne Hackborn hack...@android.comwrote:
The first thing I would look for is any code writing data that could cause
problems if it was killed in the middle of executing.
That makes sense, but that's also why I'm confused. The
I wasn't able to fully follow your description, but this bit caught me eye:
Userselection is the value chosen by the user from a list pre-populated by
the Keys in the Manager class to begin with. So if the user was able to make
the selection, the key was there at the start of the Activity, and
On Fri, Aug 27, 2010 at 3:53 PM, Tom Gibara tomgib...@gmail.com wrote:
Have the keys changed between releases of the application? Is the selected
key persisted in any way?
Nope, they're hard-coded and were introduced in the last update.
So where I have Key is a string literal I use to ID the
Wonder what I can do to make it up ...
Tell them there's cake.
I have had the same problem with every update myself. In average I get
one or two horrible ratings and about 10 emails with problems which
are always solved by reinstalling. I do not use copyprotection.
The problem with null
On Thu, Aug 26, 2010 at 3:31 AM, mot12 martin.hu...@gmail.com wrote:
The problem with null pointers I can also see with my users.
I now have 19 more reports of the same problem in the Dev Console for the
free version and 16 for the paid version. Same stack trace, same
NullPointerException.
If you think this is due to some specific code changes you just made,
you could of course have messed up. But I am sure you checked that.
I wonder what uninstalling does that a simple update doesn't
accomplish. Of course, there's the removal of the database,
preferences, and all that, but that
On Thu, Aug 26, 2010 at 8:17 AM, mot12 martin.hu...@gmail.com wrote:
If you think this is due to some specific code changes you just made, you
could of course have messed up. But I am sure you checked that.
Oh no, I don't think it's my code that's wrong, otherwise EVERYONE would be
Some things to try:
- See if having them clear data first before trying to uninstall solves the
problem.
- For users with apps on SD card support, they could try moving to the SD
card and back.
- Look in the logcat output to see if there are any suspicious messages from
installing (logcat output
On Thu, Aug 26, 2010 at 12:42 PM, Dianne Hackborn hack...@android.comwrote:
- See if having them clear data first before trying to uninstall solves the
problem.
I'll have someone try this next time I get an email and report back.
- For users with apps on SD card support, they could try
I don't have anything helpful to add, TreKing, but I did want you to
know that a small minority of my users see random breakage on update
and a reinstall fixes them right up.
Needless to say, this is unnecessarily frustrating and time-consuming.
Perhaps unrelated, I've also seen quite a few
On Thu, Aug 26, 2010 at 1:56 PM, Doug beafd...@gmail.com wrote:
I don't have anything helpful to add, TreKing, but I did want you to know
that a small minority of my users see random breakage on update and a
reinstall fixes them right up.
Just knowing others are having the same issue is
On Thu, Aug 26, 2010 at 11:18 AM, TreKing treking...@gmail.com wrote:
- Look in the logcat output to see if there are any suspicious messages
from installing (logcat output should be included in bug reports in the dev
console).
I've never gotten logcat output in the dev console. I don't
Since it continues to occur after reboot it means there is a problem
with the the way the class files have been unpacked to disk.
When an apk is installed and that app already exists, a temp folder
for the new instal is created, z and presumably the old instal is
removed later.
It sounds like in
Hm the class files aren't really unpacked on disk. They exist as a single
.dex file in the .apk. During install, a .odex file is created on disk --
this is the .dex file linked to the current platform code. When the VM
loads your .apk, if the signature on the .dex inside doesn't match the .odex
Update clears your statics, so you might expect extra bugs to come
up around that time I guess e.g. if they're not reinitialized
properly.
The classdefnotfound one is obviously not from statics however. I've
had
that one as well, for one of my internal classes, but I can't pin it
to
and update
On Wed, Aug 25, 2010 at 1:48 AM, Pent tas...@dinglisch.net wrote:
Update clears your statics, so you might expect extra bugs to come up
around that time I guess e.g. if they're not reinitialized properly.
Could you elaborate on this? I do use statics for storing user data and
looking at some
java.lang.NoClassDefFoundError: com.google.android.maps.GeoPoint
That's right - my app, which requires the Google Maps addon and should not
be allowed to install on devices without it, apparently crashed for someone
because it could not find a maps library class. What the .. ?
I'm not sure
I've seen random events like this too. The fix is always the same as
well, uninstall and reinstall. I suspect what's happening is the
download is getting corrupted in some fashion. It would be logical to
assume there is some sort of checking going on to make sure the app
was downloaded correctly
On Wed, Aug 25, 2010 at 8:55 AM, Yahel kaye...@gmail.com wrote:
I'm not sure but if you have really few of these, they might just come from
illegal/torrent-style installs ? Someone tried to install the app on there
non-gps device or something ?
I thought so, but isn't the installation of an
I've experienced users having crashing problem after an update. I'm not
sure if yours is device specific, but I would say almost 99% of the crash
reports after updating are from Motorola Droid users (via email and console
error reporting). This could mean that a large majority of my user base is
On Wed, Aug 25, 2010 at 9:42 AM, Justin Giles jtgi...@gmail.com wrote:
I'm not sure if yours is device specific, but I would say almost 99% of the
crash reports after updating are from Motorola Droid users (via email and
console error reporting).
Most of the console reports are indeed
I thought so, but isn't the installation of an apps supposed to fail if the
required library is not present?
Maybe not if it is not install through the market but directly
launched using a file manager after the where-ever-it-came-from
download.
Yahel
--
You received this message because you
I've just noticed after reading your post : Go check out the app
called guitar solo.
The developper clearly would have put his warning in bold/red/blinking
if he it was doable :)
Try to ask him what is experience is.
Good luck.
Yahel
--
You received this message because you are subscribed to
On Wed, Aug 25, 2010 at 10:06 AM, Yahel kaye...@gmail.com wrote:
Maybe not if it is not install through the market but directly launched
using a file manager after the where-ever-it-came-from download.
Could be wrong, but don't think the installer matters. For example, if you
make an AVD with
If you're updating, I'd expect the current version of the app to be closed /
shut down and your static data to be wiped, for sure, and re-initialized on
re-opening.
Yes, e.g. if function (a) relies on statics (s), so you only
initialize (s) if (a)
is being used (set by prefs). Later you add
On Wed, Aug 25, 2010 at 1:37 PM, Pent tas...@dinglisch.net wrote:
Yes, e.g. if function (a) relies on statics (s), so you only
initialize (s) if (a)
is being used (set by prefs). Later you add function (b) which also
uses (s).
When the pref controlling (a) is disabled, everything works fine
As far as I know, this is related to copy protection and a bug in
devices running Android 1.5.
If you published your app with copy protection enabled, and
subsequently disable it in some future update, you will likely
experience this problem. Users who have Android 1.5 devices and had
your app
On Wed, Aug 25, 2010 at 3:56 PM, Nyll codingcave...@gmail.com wrote:
As far as I know, this is related to copy protection and a bug in devices
running Android 1.5.
Hey, thanks for the info. Unfortunately, I don't think it's my problem.
I've never used copy protection and have gotten reports
51 matches
Mail list logo
