natkr/flickboard
7
63
Fork
You've already forked flickboard
16

flickboard crashes and cannot be reopened again when background image is too large #365

Closed
opened 2025年07月18日 18:08:49 +02:00 by blackstar · 11 comments

Context

nowadays phones' cameras take pictures with large resolutions and when such a picture is loaded as a background into flickboard the keyboard will slow down (when i tried with 4080x3060) or crash when the image is too large (tried with 8160x6120). when flickboard crashes due to a large image being set to the background it cannot be opened anymore as anytime i open it it crashes again - the only way to recover seems to be to delete all program data for flickboard, which loses all keyboard settings.

Steps to reproduce

  1. open flickboard
  2. go to "aesthetics"
  3. set "background image" to a very large image file

Expected behavior

image should be potentially resized to the screen width to avoid issues or a warning could be issued to prevent the user from setting an image that will crash flickboard as a background.

Actual behavior

flickboard crashes and cannot be opened anymore.

Android version

Android 14

Device

Samsung Galaxy A15

Other details

i can provide an example image that i've experienced a crash with if needed but i think any image large enough should suffice.

Acknowledgements

  • I have written a short but informative title.
  • I have searched the existing issues and this is a new one, NOT a duplicate or related to another open issue.
  • I have filled out all of the requested information in this form.
### Context nowadays phones' cameras take pictures with large resolutions and when such a picture is loaded as a background into flickboard the keyboard will slow down (when i tried with 4080x3060) or crash when the image is too large (tried with 8160x6120). when flickboard crashes due to a large image being set to the background it cannot be opened anymore as anytime i open it it crashes again - the only way to recover seems to be to delete all program data for flickboard, which loses all keyboard settings. ### Steps to reproduce 1. open flickboard 2. go to "aesthetics" 3. set "background image" to a very large image file ### Expected behavior image should be potentially resized to the screen width to avoid issues or a warning could be issued to prevent the user from setting an image that will crash flickboard as a background. ### Actual behavior flickboard crashes and cannot be opened anymore. ### Android version Android 14 ### Device Samsung Galaxy A15 ### Other details i can provide an example image that i've experienced a crash with if needed but i think any image large enough should suffice. ### Acknowledgements - [x] I have written a short but informative title. - [x] I have searched the existing issues and this is a new one, **NOT** a duplicate or related to another open issue. - [x] I have filled out all of the requested information in this form.
Owner
Copy link

Oof, that's definitely not good!

Oof, that's definitely not good!
Owner
Copy link

And yes, it'd be good to have an example image, though which images do and don't trigger it are ultimately going to depend on the specific device (how much memory it has, how its Android variant is tuned, etc etc etc).

And yes, it'd be good to have an example image, though which images do and don't trigger it are ultimately going to depend on the specific device (how much memory it has, how its Android variant is tuned, etc etc etc).

sure, i am attaching two images, the large one (img_crash.jpg at 8160x6120) crashes flickboard completely and the smaller one (img_slowdown.jpg at 4080x3060) causes flickboard to lag for around a second before it opens (both the program itself and the software keyboard when trying to use it in a launcher)

sure, i am attaching two images, the large one (img_crash.jpg at 8160x6120) crashes flickboard completely and the smaller one (img_slowdown.jpg at 4080x3060) causes flickboard to lag for around a second before it opens (both the program itself and the software keyboard when trying to use it in a launcher)

if it's also useful, my device has 4 gigabytes of ram and 4 more gigabytes are usable as swap.

if it's also useful, my device has 4 gigabytes of ram and 4 more gigabytes are usable as swap.
Owner
Copy link

FWIW, I have managed to repro the slowdown in the emulator using 16000x.jpg, but 4080x3060.jpg doesn't seem to do much.

FWIW, I have managed to repro the slowdown in the emulator using 16000x.jpg, but 4080x3060.jpg doesn't seem to do much.

filesize maybe matters too, your 4080x3060 slows down my flickboard noticeably less that my 4080x3060, but the 16000x causes the crash.

filesize maybe matters too, your 4080x3060 slows down my flickboard noticeably less that my 4080x3060, but the 16000x causes the crash.
Owner
Copy link

Hm, in the emulator your img_slowdown causes a minor slowdown and img_crash a medium slowdown (it's bad, but still less than 16000x.jpg).

Hm, in the emulator your img_slowdown causes a minor slowdown and img_crash a medium slowdown (it's bad, but still less than 16000x.jpg).
Owner
Copy link

Okay, progress! It seems to depend on the Android version. I see the same crash from 16000x in the Android 14 emulator (I was using 16 before).

Okay, progress! It seems to depend on the Android version. I see the same crash from 16000x in the Android 14 emulator (I was using 16 before).
Owner
Copy link

Some good news at least... according to the logs, it's not actually a memory problem per se, but "just" the system refusing to render images that it considers too large. That makes it way more realistic to add a bettter failsafe.

Stack trace 
FATAL EXCEPTION: main
Process: se.nullable.flickboard.unsigned, PID: 3344
java.lang.RuntimeException: Canvas: trying to draw too large(1024000000bytes) bitmap.
	at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:266)
	at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:94)
	at l0.b.f(Unknown Source:87)
	at n0.b.K(Unknown Source:24)
	at D0.L.K(Unknown Source:13)
	at n0.d.j0(Unknown Source:36)
	at q0.a.e(Unknown Source:55)
	at q0.d.c(Unknown Source:111)
	at i0.g.x(Unknown Source:220)
	at D0.L.d(Unknown Source:51)
	at D0.i0.I0(Unknown Source:49)
	at D0.i0.H0(Unknown Source:27)
	at D0.B.e1(Unknown Source:5)
	at D0.i0.I0(Unknown Source:7)
	at D0.h0.c(Unknown Source:26)
	at c0.r.e(Unknown Source:108)
	at c0.s.a(Unknown Source:55)
	at c0.u.d(Unknown Source:127)
	at D0.s0.a(Unknown Source:2)
	at B.f.j(Unknown Source:988)
	at A.t.k(Unknown Source:685)
	at o0.b.c(Unknown Source:46)
	at V2.g.k(Unknown Source:1448)
	at o0.g.n(Unknown Source:34)
	at o0.b.e(Unknown Source:54)
	at E0.P0.i(Unknown Source:98)
	at E0.A.dispatchDraw(Unknown Source:68)
	at android.view.View.draw(View.java:23892)
	at android.view.View.updateDisplayListIfDirty(View.java:22756)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513)
	at android.view.View.updateDisplayListIfDirty(View.java:22712)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513)
	at android.view.View.updateDisplayListIfDirty(View.java:22712)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513)
	at android.view.View.updateDisplayListIfDirty(View.java:22712)
	at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540)
	at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513)
	at android.view.View.updateDisplayListIfDirty(View.java:22712)
	at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:694)
	at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:700)
	at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:798)
	at android.view.ViewRootImpl.draw(ViewRootImpl.java:4939)
	at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:4643)
	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3822)
	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2465)
	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9305)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1339)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1348)
	at android.view.Choreographer.doCallbacks(Choreographer.java:952)
	at android.view.Choreographer.doFrame(Choreographer.java:882)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1322)
	at android.os.Handler.handleCallback(Handler.java:958)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:205)
	at android.os.Looper.loop(Looper.java:294)
	at android.app.ActivityThread.main(ActivityThread.java:8177)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)
Some good news at least... according to the logs, it's not actually a memory problem per se, but "just" the system refusing to render images that it considers too large. That makes it way more realistic to add a bettter failsafe. <details> <summary>Stack trace</summary> ``` FATAL EXCEPTION: main Process: se.nullable.flickboard.unsigned, PID: 3344 java.lang.RuntimeException: Canvas: trying to draw too large(1024000000bytes) bitmap. at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:266) at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:94) at l0.b.f(Unknown Source:87) at n0.b.K(Unknown Source:24) at D0.L.K(Unknown Source:13) at n0.d.j0(Unknown Source:36) at q0.a.e(Unknown Source:55) at q0.d.c(Unknown Source:111) at i0.g.x(Unknown Source:220) at D0.L.d(Unknown Source:51) at D0.i0.I0(Unknown Source:49) at D0.i0.H0(Unknown Source:27) at D0.B.e1(Unknown Source:5) at D0.i0.I0(Unknown Source:7) at D0.h0.c(Unknown Source:26) at c0.r.e(Unknown Source:108) at c0.s.a(Unknown Source:55) at c0.u.d(Unknown Source:127) at D0.s0.a(Unknown Source:2) at B.f.j(Unknown Source:988) at A.t.k(Unknown Source:685) at o0.b.c(Unknown Source:46) at V2.g.k(Unknown Source:1448) at o0.g.n(Unknown Source:34) at o0.b.e(Unknown Source:54) at E0.P0.i(Unknown Source:98) at E0.A.dispatchDraw(Unknown Source:68) at android.view.View.draw(View.java:23892) at android.view.View.updateDisplayListIfDirty(View.java:22756) at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540) at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513) at android.view.View.updateDisplayListIfDirty(View.java:22712) at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540) at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513) at android.view.View.updateDisplayListIfDirty(View.java:22712) at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540) at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513) at android.view.View.updateDisplayListIfDirty(View.java:22712) at android.view.ViewGroup.recreateChildDisplayList(ViewGroup.java:4540) at android.view.ViewGroup.dispatchGetDisplayList(ViewGroup.java:4513) at android.view.View.updateDisplayListIfDirty(View.java:22712) at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:694) at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:700) at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:798) at android.view.ViewRootImpl.draw(ViewRootImpl.java:4939) at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:4643) at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3822) at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2465) at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9305) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1339) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1348) at android.view.Choreographer.doCallbacks(Choreographer.java:952) at android.view.Choreographer.doFrame(Choreographer.java:882) at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1322) at android.os.Handler.handleCallback(Handler.java:958) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loopOnce(Looper.java:205) at android.os.Looper.loop(Looper.java:294) at android.app.ActivityThread.main(ActivityThread.java:8177) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971) ``` </details>
natkr added this to the v0.3.0 milestone 2025年07月19日 00:20:20 +02:00
Owner
Copy link

Should be fixed in https://codeberg.org/natkr/flickboard/releases/tag/v0.2.7-beta3, sorry about that!

Should be fixed in https://codeberg.org/natkr/flickboard/releases/tag/v0.2.7-beta3, sorry about that!

no worries, thank you for the fix!

no worries, thank you for the fix!
Sign in to join this conversation.
No Branch/Tag specified
main
spike/old/layout-editor-v1
spike/hct-colour-sliders
features/binary-landscape-keyboard-alignment
v0.3.4.1
v0.3.4
v0.3.4-beta1
v0.3.3
v0.3.3-beta1
v0.3.2
v0.3.2-beta2
v0.3.2-beta1
v0.3.1
v0.3.1-beta2
v0.3.1-beta1
v0.3.0.1
v0.3.0
v0.2.7
v0.2.7-beta7
v0.2.7-beta6
v0.2.7-beta5
v0.2.7-beta4
v0.2.7-beta3
v0.2.7-beta2
v0.2.7-beta1
v0.2.6.1
v0.2.6
v0.2.6-beta1
v0.2.5
v0.2.5-beta5
v0.2.5-beta4
v0.2.5-beta3
v0.2.5-beta2
v0.2.5-beta1
v0.2.4
v0.2.4-beta2
v0.2.4-beta1
v0.2.3
v0.2.2
v0.2.2-beta11
v0.2.2-beta10
v0.2.2-beta9
v0.2.2-beta8
v0.2.2-beta7
v0.2.2-beta6
v0.2.2-beta5
v0.2.2-beta4
v0.2.2-beta3
v0.2.2-beta1
v0.2.1
v0.2.1-beta9
v0.2.1-beta8
v0.2.1-beta7
v0.2.1-beta6
v0.2.1-beta5
v0.2.1-beta4
v0.2.1-beta3
v0.2.1-beta2
v0.2.1-beta1
v0.2.0.1
v0.2.0
v0.2.0-beta5
v0.2.0-beta4
v0.2.0-beta3
v0.2.0-beta2
v0.2.0-beta1
v0.1.11
v0.1.11-beta2
v0.1.11-beta1
v0.1.10
v0.1.10-beta1
v0.1.9
v0.1.8
v0.1.8-beta11
v0.1.8-beta10
v0.1.8-beta9
v0.1.8-beta8
v0.1.8-beta7
v0.1.8-beta6
v0.1.8-beta5
v0.1.8-beta4
v0.1.8-beta3
v0.1.8-beta2
v0.1.8-beta1
v0.1.7
v0.1.7-beta2
v0.1.7-beta1
v0.1.6
v0.1.6-beta7
v0.1.6-beta6
v0.1.6-beta5
v0.1.6-beta4
v0.1.6-beta3
v0.1.6-beta2
v0.1.6-beta1
v0.1.5
v0.1.4
v0.1.3
v0.1.2
v0.1.1
v0.1.0
v0.0.13
v0.0.12
v0.0.11
v0.0.10
v0.0.9
v0.0.8
v0.0.7
v0.0.6
v0.0.5
v0.0.4
v0.0.3
v0.0.2
v0.0.1
Labels
Clear labels
bug
Something isn't working
bug/gesture
A gesture recognition problem
bug/motorola
Bugs that have only been confirmed on Motorola devices
bug/samsung
Bugs that have only been confirmed on Samsung devices
bug/unreproducible
A bug that I can't seem to reproduce, more information is required
cleanup
Maintenance tasks
community
Community/discussion infrastructure
design
Involves design question(s)
documentation
Improvements or additions to documentation
duplicate
This issue or pull request already exists
emoji
Emoji-related features
feature
New feature or request
good first issue
Good for newcomers
help wanted
Extra attention is needed
invalid
This doesn't seem right
layout
Add or change a keyboard layout
meta
Questions about the process itself
question
Further information is requested
wontfix
This will not be worked on
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
natkr/flickboard#365
Reference in a new issue
natkr/flickboard
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?