Pocket Legends Broken - Logcat/potential fix inside
here ya go devs - this is the problem with the update... nothing to deal with tablets not being "cell phones" as someone had suggested - a simple problem with permissions...Code:I/ActivityManager( 967): Starting activity: Intent { act=android.intent.action. MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=sts.pl/.PocketLeg ends bnds=[582,45][668,118] } I/ActivityManager( 967): Start proc sts.pl for activity sts.pl/.PocketLegends: pid=2910 uid=10038 gids={3003, 1015} W/ApplicationContext( 2910): Attempt to read preferences file /data/data/sts.pl/ shared_prefs/PocketLegends.xml without permission E/ApplicationContext( 2910): Couldn't rename file /data/data/sts.pl/shared_prefs /PocketLegends.xml to backup file /data/data/sts.pl/shared_prefs/PocketLegends.x ml.bak D/AndroidRuntime( 2910): Shutting down VM W/dalvikvm( 2910): threadid=1: thread exiting with uncaught exception (group=0x4 001d848) E/AndroidRuntime( 2910): FATAL EXCEPTION: main E/AndroidRuntime( 2910): java.lang.RuntimeException: Unable to start activity Co mponentInfo{sts.pl/sts.pl.PocketLegends}: java.lang.NullPointerException E/AndroidRuntime( 2910): at android.app.ActivityThread.performLaunchActiv ity(ActivityThread.java:2663) E/AndroidRuntime( 2910): at android.app.ActivityThread.handleLaunchActivi ty(ActivityThread.java:2679) E/AndroidRuntime( 2910): at android.app.ActivityThread.access$2300(Activi tyThread.java:125) E/AndroidRuntime( 2910): at android.app.ActivityThread$H.handleMessage(Ac tivityThread.java:2033) E/AndroidRuntime( 2910): at android.os.Handler.dispatchMessage(Handler.ja va:99) E/AndroidRuntime( 2910): at android.os.Looper.loop(Looper.java:123) E/AndroidRuntime( 2910): at android.app.ActivityThread.main(ActivityThrea d.java:4627) E/AndroidRuntime( 2910): at java.lang.reflect.Method.invokeNative(Native Method) E/AndroidRuntime( 2910): at java.lang.reflect.Method.invoke(Method.java:5 21) E/AndroidRuntime( 2910): at com.android.internal.os.ZygoteInit$MethodAndA rgsCaller.run(ZygoteInit.java:868) E/AndroidRuntime( 2910): at com.android.internal.os.ZygoteInit.main(Zygot eInit.java:626) E/AndroidRuntime( 2910): at dalvik.system.NativeStart.main(Native Method) E/AndroidRuntime( 2910): Caused by: java.lang.NullPointerException E/AndroidRuntime( 2910): at com.tapjoy.TapjoyConnect.initMetaData(TapjoyC onnect.java:248) E/AndroidRuntime( 2910): at com.tapjoy.TapjoyConnect.<init>(TapjoyConnect .java:152) E/AndroidRuntime( 2910): at com.tapjoy.TapjoyConnect.getTapjoyConnectInst ance(TapjoyConnect.java:137) E/AndroidRuntime( 2910): at sts.pl.PocketLegends.onCreate(PocketLegends.j ava:137) E/AndroidRuntime( 2910): at android.app.Instrumentation.callActivityOnCre ate(Instrumentation.java:1047) E/AndroidRuntime( 2910): at android.app.ActivityThread.performLaunchActiv ity(ActivityThread.java:2627) E/AndroidRuntime( 2910): ... 11 more W/ActivityManager( 967): Force finishing activity sts.pl/.PocketLegends W/ActivityManager( 967): Activity pause timeout for HistoryRecord{4aa840f0 sts. pl/.PocketLegends} W/ActivityManager( 967): Activity destroy timeout for HistoryRecord{4aa840f0 st s.pl/.PocketLegends}
i am setting proper permissions as we speak to see if that fixes things... but really, let's get a solution ASAP to those of us who pay for this little time-killing app Pocket Legends.
after some quick research it seems that this was a problem caused by the devs (obv) and not our specific devices:
http://groups.google.com/group/andro...ferences&pli=1
http://code.google.com/p/android/issues/detail?id=2047
it seems as if the app was originally published with copy protection on and then switched to off (or the opposite) and this is now causing the problems we have:
so this is a KNOWN issue with absolutely no real "fix" from google as it was supposed to be baked into froyo - obviously the devs complaining on google in september means it wasnt really fixed. so it seems spacetimestudios has been caught up in a problem with google's flaws, and not their own. i think the fix for this is to switch back the copy protected status of the app - whether that was on or off - this is also assuming i am right in why sts.pl is failing for us.I noticed the same thing and did some research. It appears that what happens is
during the upgrade process for a non copy protected app to a protected app (or vice
versa), the program responsible for the upgrade does preserve the data directories
for the previous app, however it generates a new user/group id for the newer version.
Because the data directories are associated not with the user/group id of the new
version, they are inaccessible
but since there is absolutely no word from the devs on what the status of this problem is, someone has to get the ball rolling in a direction towards a solution!
Originally Posted by sniffs
Bookmarks