Android AssetManager Timeout Exception - android

We have recently started experiencing a lot of AssetManager Timeout Exception.
Fatal Exception: java.util.concurrent.TimeoutException: android.content.res.AssetManager$AssetInputStream.finalize() timed out after 10 seconds
at android.content.res.AssetManager$AssetInputStream.close(AssetManager.java:565)
at android.content.res.AssetManager$AssetInputStream.finalize(AssetManager.java:598)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:190)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:173)
at java.lang.Thread.run(Thread.java:818)
We recently updated support lib version to 27.1.1 , playservices to '11.0.4'.
Can't think of any possible reason for the crash appearing recently in large numbers.

Related

DeadSystemException in HMSPackageManager

I faced DeadSystemException in app on Huawei devices when HMSPackageManager tries to get info about services from Android PackageManager.
Stacktrace:
Fatal Exception: java.lang.RuntimeException: android.os.DeadSystemException
at android.app.ApplicationPackageManager.queryIntentServicesAsUser(ApplicationPackageManager.java:1192)
at android.app.ApplicationPackageManager.queryIntentServices(ApplicationPackageManager.java:1198)
at com.huawei.hms.utils.HMSPackageManager.f(HMSPackageManager.java:27)
at com.huawei.hms.utils.HMSPackageManager.i(HMSPackageManager.java:4)
at com.huawei.hms.utils.HMSPackageManager.refresh(HMSPackageManager.java:16)
at com.huawei.hms.utils.HMSPackageManager.getHMSPackageName(HMSPackageManager.java:8)
at com.huawei.hms.utils.HMSPackageManager.getHmsVersionCode(HMSPackageManager.java:1)
at com.huawei.hms.utils.HMSPackageManager.isApkUpdateNecessary(HMSPackageManager.java)
at com.huawei.hms.adapter.AvailableAdapter.isHuaweiMobileServicesAvailable(AvailableAdapter.java:77)
at com.huawei.hms.common.internal.BaseHmsClient.checkAvailabilityAndConnect(BaseHmsClient.java:134)
at com.huawei.hms.common.internal.BaseHmsClient.connect(BaseHmsClient.java:1)
at com.huawei.hms.common.internal.HuaweiApiManager$ConnectionManager.connect(HuaweiApiManager.java:97)
at com.huawei.hms.common.internal.HuaweiApiManager$ConnectionManager.sendRequest(HuaweiApiManager.java:96)
at com.huawei.hms.common.internal.HuaweiApiManager.connectAndSendRequest(HuaweiApiManager.java:37)
at com.huawei.hms.common.internal.HuaweiApiManager.handleMessage(HuaweiApiManager.java:35)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:213)
at android.os.HandlerThread.run(HandlerThread.java:67)
Crash occurs on Android 8/9/10/11, so likely it's not android problem. Crash happens only on Huawei devices. Our app not call HMSPackageManager from any place, so I think it happens in time of HMS Core initialization.
Is anyone has same problem?
Huawei support said that problem in Android OS, but they try to fix error in next HMS SDK update in mid of september.

TimeoutException android.media.SoundPool.finalize()

On Android 9, this crash appears sometimes, I can't understand why:
Fatal Exception: java.util.concurrent.TimeoutException android.media.SoundPool.finalize() timed out after 10 seconds android.media.SoundPool.native_release (SoundPool.java) android.media.SoundPool.release (SoundPool.java:177) java.lang.Thread.run (Thread.java:764)
All works perfectly before, and now on Android 9 (SONY currently), the crash appears.
Have you got some explanations guys?

Every runtime error reported as SIGSEGV error in android studio

I have linked some c++ codes to android studio project and it works with no problem, but every time I encounter with a runtime error in java code, android studio won't tell me the problem precisely and reports only this error in debugger:
Signal = SIGSEGV (signal SIGSEGV: invalid address (fault address: 0xc))
What is the problem?
This primarily occurs due to one of the 2 reasons :
1) Invalid memory reference.
2) Eating up too much memory.
Now, debugging this issue can be a bit intimidating.
So start finding out points where your code may be doing INVALID MEMORY ACCESS causing SIGSEGV error or points where your code is starting too many threads.
And You have to find out if this issue is regularly occuring or 1 in 5(or so) times.
Because I encountered the problem in one project and that occured 1 in 5-6 times.

Where do I get the latest IABHelper library?

I have started getting the following exception on some devices:
java.lang.NullPointerException
at com.mycompany.iab.IabHelper.queryPurchases(Unknown Source)
at com.mycompany.iab.IabHelper.queryInventory(Unknown Source)
at com.mycompany.iab.IabHelper.queryInventory(Unknown Source)
at com.mycompany.iab.IabHelper$2.run(Unknown Source)
at java.lang.Thread.run(Thread.java:856)
And I'm wondering if maybe I using the wrong version of the IABHelper as all the posts I find about that same exception are pretty old.
Thanks.
It looks like you probably are using the latest version. Though check the version number in the SDK manager is version 5, then perform a diff on the util folder you have in your app. I am getting these errors too - I assume that it is user error (not calling the sample APIs correctly in some way or other). I got 2 reports today, and 1 at the end of October (2014) - not many so far...

Android app - native lib not found error report on Google Play?

I got the following crash report on Google Play developer console for my app. It seems to suggest that my native library (libcld.so, which _is_present_ in my APK for both ARM flavors and x86) could not be found, and the user comments "nicht mehr startbar" (German: does not start any more). The stack trace is below. Why should this happen??? A freak accident on one of thousands of devices using the app without such trouble? The only explanation I can think of comes from my Windows software experience: sometimes the anti-virus software has a "false positive" and deletes there my exe or one of the dll's as infected. The AV vendors usually fix "false positives" within 24 hours, although they do damage business.
Does this happen on Android too? Would be the first time for me. What could be another reason of not finding the native libraries included with the app?
Stack trace as reported on Google Play:
java.lang.RuntimeException: An error occured while executing
doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:200) at
java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273)
at java.util.concurrent.FutureTask.setException(FutureTask.java:124)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307)
at java.util.concurrent.FutureTask.run(FutureTask.java:137) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1068)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:561)
at java.lang.Thread.run(Thread.java:1096) Caused by:
java.lang.ExceptionInInitializerError at
com.hyperionics.avar.SpeakService.setOriginalText(SourceFile:143) at
com.hyperionics.avar.ContentsLoader.doInBackground(SourceFile:137) at
com.hyperionics.avar.ContentsLoader.doInBackground(SourceFile:31) at
android.os.AsyncTask$2.call(AsyncTask.java:185) at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305) ...
4 more Caused by: java.lang.UnsatisfiedLinkError: Library cld not
found at java.lang.Runtime.loadLibrary(Runtime.java:461) at java.lang.System.loadLibrary(System.java:557) at
com.hyperionics.avar.CldWrapper.(SourceFile:21) ... 9 more
Greg
I figured out what was the problem, inspired by comments left by Chris above. I noticed then that the reported error was on an old device, which can be upgraded max to Android 2.2, not higher.
In the most current release of my app, I made a small modification in my native library, and used asset_manager in it. I did not realize that the native code was compiled for android-14 platform (as my AndroidManifest.xml declares this as the targetSdkVersion), while my minimum supported platforms is android-8 (Android 2.2, Froyo). Turns out there is no asset_manager under the old platform. After I added to Application.mk the following line:
APP_PLATFORM := android-8
the native build immediately triggered an error and I could fix the issue. Well, the most important lesson from this adventure, which I have to learn and re-learn over and over again: before releasing anything, test on all the platforms you claim to support...
A big Thank you! again to Chris for responding to me and making me look again at the crash report.
Greg

Categories

Resources