Develop Reference

Why android room throwing CursorWindowAllocationException? [duplicate]

This question already has an answer here:
android.database.CursorWindowAllocationException when moving a Cursor
(1 answer)
Closed 9 months ago.
I use the room orm for saving data in my app. My app is running on android 5.1.1 and also I use androidx in the project. But after a while I got the below exception:
Fatal Exception: android.database.CursorWindowAllocationException: Cursor window allocation of 2048 kb failed.
at android.database.CursorWindow.(CursorWindow.java:108)
at android.database.AbstractWindowedCursor.clearOrCreateWindow(AbstractWindowedCursor.java:226)
at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:148)
at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:142)
at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:219)
at android.database.AbstractCursor.moveToNext(AbstractCursor.java:268)
at android.arch.persistence.room.InvalidationTracker$1.checkUpdatedTable(InvalidationTracker.java:358)
at android.arch.persistence.room.InvalidationTracker$1.run(InvalidationTracker.java:329)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
But indeed Room manages Cursor automatically and there isn't any Cursor class in the whole project and furthermore, when this error happens there isn't any database-related transaction.

Finally, I found the answer. Be careful when you use WorkManager. It creates a database and updates work statuses and when this database grows it causes a crash. Here is detailed information.
WorkManager database: A local database that tracks all of the information and statuses of all of your work. This includes things like the current state of the work, the inputs and outputs to and from the work ,and any constraints on the work. This database is what enables WorkManager to guarantee your work will finish — if your user’s device restarts and work gets interrupted, all of the details of the work can be pulled from the database and the work can be restarted when the device boots up again.
Use pruneWork() in WorkManager when necessary

Android Lollipop 5.0.1 SQLiteLog POSIX Error 11 SQLite Error: 3850

I am having an issue while upgrading an app to support Android Lollipop.
The app implements a SyncAdapter that writes on a db through a content provider.
At the same time it can happen that the user is browsing the front-end of the app where loaders read the same data from the database.
Loaders also listen to data changes.
Now, if I run the program on a pre-Lollipop device everything works without any error output.
On Lollipop instead I receive the following logcat message:
11:20:59.344 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850
11:20:59.364 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850
11:20:59.364 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850
11:20:59.364 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850
Now, from SQLite docs:
(3850) SQLITE_IOERR_LOCK
The SQLITE_IOERR_LOCK error code is an extended error code for
SQLITE_IOERR indicating an I/O error in the advisory file locking
logic. Usually an SQLITE_IOERR_LOCK error indicates a problem
obtaining a PENDING lock. However it can also indicate miscellaneous
locking errors on some of the specialized VFSes used on Macs.
Everything seems to work properly on a high level (that is both reads
and writes are performed)
and:
A PENDING lock means that the process holding the lock wants to write
to the database as soon as possible and is just waiting on all current
SHARED locks to clear so that it can get an EXCLUSIVE lock. No new
SHARED locks are permitted against the database if a PENDING lock is
active, though existing SHARED locks are allowed to continue.
I know that the SQLite version has been updated by few major releases in Lollipop, so I am prone to think that the error is due to some new behaviour of SQLite that I cannot isolate.
However, everything seems to work fine from a higher level point of view (App doesn't crash, both reads and writes are performed, framerate doesn't drop - at least to human eyes) but I wouldn't want to ignore the issue to release the app until I am sure it won't cause data corruption or troubles.
Perhaps I am missing on some important changes to lollipop regarding locks and multiprocess database access, but I feel it's an issue that lies on a lower level with respect to the Art/Dalvik domain and so has to be fixed in an NDK context.
Is there a way to fix this possibly without distributing an app specific version of SQLite? Is there any manifest/SQLite option to avoid the error?
Thanks in advance

Writer locks the database for both reading and writing.
That means it has to wait for all readers to finish and release locks in order to obtain lock.
After the writer requested a lock, new reader locks must wait for writer to first obtain lock and then release it.
This could be a solution for you: WAL mode
Activating And Configuring WAL Mode:
An SQLite database connection defaults to journal_mode=DELETE. To convert to WAL mode, use the following pragma:
PRAGMA journal_mode=WAL;
WAL will not block readers while writing, which means also that writer does not need to wait for current read locks to be released.
Minimum SQLite version required for WAL is 3.7.0 (2010-07-21).
Lollipop 5.0 uses SQLite 3.8.4.3 so WAL should be available for you.
But WAL does not exist in Android version less than 3.0 although there are some exceptions from this. Take a look at Version of SQLite used in Android?. If you don't need your app to work below Android 3.0 you can use WAL.

Android Multithreading - WaitForGcToComplete after sending app to background

I'm using Android L for some heavily multi-threaded operations, using multiple ThreadPoolExecutors to run queues of AsyncTasks.
When my app goes to the background, I start seeing numerous logs for...
I/art: WaitForGcToComplete blocked for ##.#####ms for cause XXXXX
...with an occasional...
I/art: No such thread id for suspend: ###.
It seems clear that something is going on that's making GC take longer than expected. The log gets generated by art/runtime/gc/heap.cc deep in the AOSP. The secondary log message indicates it's probably related to my thread pools. What isn't clear is why this is only happening (i.e. getting logged) when the app is sent to the background.
I haven't seen any crashes yet due to this, but I have a lot more testing to go through. Has anyone out there run into issues coinciding with these logs?

How to solve showStatusIcon on inactive InputConnection [duplicate]

This question already has an answer here:
Android input connection error
(1 answer)
Closed 7 years ago.
When I close my app I get this message on LogCat
showStatusIcon on inactive InputConnection
I read somewhere, but I'm not sure, that it means that I didn't release something, something related to the memory usage.
How can I solve this problem?

Such problems occur when the input connection in the previous page(or class) has not been closed. Check whether you've closed the input connection in the previous class (by giving connection.close()).
from
Android input connection error

from the documentation
The InputConnection interface is the communication channel from an InputMethod back to the application that is receiving its input. It is used to perform such things as reading text around the cursor, committing text to the text box, and sending raw key events to the application.
In addition, further reading shows
getExtractedText(): This method may fail either if the input connection has become invalid (such as its process crashing) or the client is taking too long to respond with the text (it is given a couple seconds to return). In either case, a null is returned.
It appears to also monitor changes to such text, and alert changes.
To hunt the issue down you'll have to explore any queries you are making, perhaps around listViews or lists in a layout.
If you don't have any views, for example it's happening randomly in the background, then i would suggest that its not a UI element issue, so ignore textfields and such. It could be a background service that's storing information in a cursor or requesting a cursor.
Also, does the issue arise from your app? or perhaps someone else's that you've installed recently. List the full logCat trace. Someone might recognise the issue.
I would hazard a guess that if you haven't written something specific around this that its someone elses log message, or perhaps that of a library your using?

App dies with "Sending signal." but no exception or other info

I'm working on an app that is recording data via Bluetooth, but it intermittently crashes after hours of collecting data (making it hard to track down the bug).
The logcat output isn't very helpful:
http://i.imgur.com/EalnX.png
There are no exceptions thrown and no clues for what caused the process to be terminated.
How can I figure out what went wrong? Is there an exception being thrown that isn't being shown by logcat? How can I track this bug down?

Signal 9 is SIGKILL, which will terminate a process immediately (no handlers inside the process will run). From the log line, the process is killing itself, so its not an external agent that is issuing the SIGKILL.
My guess (and its really a guess) is that the memory management code running inside your process (as part of the infrastructure, not code that you wrote) is deciding that you've exhausted some resource and the only recourse is to die. I would expect there to be more messages before this point is reached in the log, so it may be worth browsing the log history to see if there are useful warnings from the process before this point.
The line immediately before this is a GC log, which implies that some sort of memory resource is running low. But it looks like the heaps are not full, so failing allocations seems unlikely. You can still get allocation failures if the object being allocated was too large to fit on the heap, or fragmentation prevented it from being allocated. I'd expect to see more relevant log messages in this case, though.
I think capturing more of the log (perhaps filtering it by your app's PID if necessary) will help you make progress.

In my case there was no warnings or any clues in the log.
Eventually I found that my problem was that one of the activities I was going into (lets say Activity X) was registering to a broadcast receiver but never unregistered from it.
Therefor by closing the activity (Activity X) and coming back to it caused registering Again to the same broadcast receiver - which caused the mess!
Simply adding unregisterReceiver(mybroadcast); (in Activity X) solved it.
(I added mine to onDestroy. make sure you unregister in the right location).
And if you are super desperate I recommend seeing this slide share which explains Android crash debugging your errors.

this problem happens when using RXjava and not implement the onError callback method