https://bugs.kde.org/show_bug.cgi?id=521883
--- Comment #1 from Tiar <[email protected]> --- Translation from the attached zip: ------------------------------------------------- To the respected Krita Development Team, Dear Developers, I am a Windows and Android user who has started using Krita for pre-production game concept art in recent years. I deeply appreciate and am highly optimistic about Krita’s development. All the bugs and defects I report at present are exclusive to the Android version, and I have a lot of relevant feedback to share. I possess solid foundational knowledge of the Android system. My device specifications: OnePlus Ace Racing Edition, ColorOS 15 based on Android 15, mainland China region user. Krita build version: 5.3.2.1 git (0619060), downloaded from the official website’s stable release channel via standard installation procedure. Attached are log files and annotated screenshots. I will move straight to the core issues below: 1. Krita Built-in File Picker (Relevant screenshot: IMG_20260620_220957.webp within the compressed ZIP package) The root cause of this malfunction is incomplete static permission declarations inside the AndroidManifest.xml file of Krita’s APK installation package. For reference, here is a permission snippet adopted by Termux for full storage access: <!-- Read contents from shared storage --> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <!-- Modify or delete files within shared storage --> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <!-- Full all-files access permission --> <uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" /> Without the complete set of permissions listed above, Krita’s internal file picker cannot enumerate, view, open or edit any media/document files stored in public shared storage on modern high-version Android systems. Users can only browse visible folders and subfolders, while all actual files inside directories are hidden. New Android OS versions enforce strict file interception mechanisms for privacy and security purposes. When apps lack full storage access authorizations (including image, audio, video and universal all-file permissions), the system blocks file enumeration entirely. The critical permission here is definitely MANAGE_EXTERNAL_STORAGE; supporting screenshot reference: Screenshot_2026-06-20-22-25-26-87_fc704e6b13c4fb26bf5e411f75da84f2.webp inside the ZIP archive. Reference Permission Group 2 <!-- Read shared storage content, only apply for SDK versions up to Android 12 (API 32) --> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> <!-- Read image media files from shared storage --> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <!-- Modify or erase shared storage content --> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> Optional supplementary permissions to optimize drawing workflow experience: <!-- Request to be excluded from system battery optimization restrictions --> <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" /> <!-- Keep device awake during drawing sessions --> <uses-permission android:name="android.permission.WAKE_LOCK" /> Reference Permission Group 3 (Comprehensive full-feature permission set) <!-- Global all-files management access --> <uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" /> <!-- Image media read access --> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <!-- Video media read access --> <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" /> <!-- Prevent screen sleep during long painting work --> <uses-permission android:name="android.permission.WAKE_LOCK" /> <!-- Post system notifications for backup/export reminders --> <uses-permission android:name="android.permission.POST_NOTIFICATIONS" /> <!-- USB storage device access support --> <uses-permission android:name="android.permission.USB_PERMISSION" /> <!-- Write and delete shared storage files --> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <!-- Basic shared storage read access --> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <!-- Audio media file read permission --> <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" /> <!-- Full document and file management scope --> <uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" /> <!-- Persist wake lock across screen lock state --> <uses-permission android:name="android.permission.WAKE_LOCK" /> <!-- Auto-restart app after device reboot --> <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> <!-- Camera access for texture reference capture --> <uses-permission android:name="android.permission.CAMERA" /> <!-- Access motion sensor data: accelerometer, gyroscope, device rotation tracking --> <uses-permission android:name="android.permission.ACCESS_MOTION_SENSOR" /> <!-- Device physical orientation sensor read access --> <uses-permission android:name="android.permission.ACCESS_ORIENTATION" /> Currently, Krita’s manifest file only contains a single storage permission declaration as follows: <!-- Modify or delete shared storage content --> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> This insufficient permission declaration inevitably triggers widespread compatibility failures on all modern high-version Android operating systems. I have provided all viable permission reference snippets above, hoping these resources help resolve the compatibility defects caused by incomplete storage permission configuration. Supplementary Explanation for Screenshot Demonstrated Issues 1. Reason I prioritize reporting and advocating for improvements to the built-in file picker, investing spare personal time to submit this detailed report: My device runs unmodified official ColorOS firmware with locked bootloader, no root access available. The only legitimate way to browse, modify and organize Krita’s private application directories entirely relies on Krita’s native internal file picker, running under Krita’s own system user identity u0_a319 (verified in attached screenshots). The restricted private paths include: /data/user/0/org.krita /data/data/org.krita /storage/emulated/0/Android/data/org.krita /data/user_de/0/org.krita These folders store automatic configuration backups and .kra project backup files, which are assigned owner-only read/write system file permissions. Even with advanced file management tools like MT Manager (which can partially access /storage/emulated/0/Android/data/org.krita without root), copying these backup files externally is blocked by system permission denial errors. This built-in file browser is an irreplaceable core feature for end users without root privileges. I sincerely request a toggle option to disable the system default native file picker. By contrast, Android’s system default file selector has two critical drawbacks: - It only grants access to public shared storage partitions and cannot navigate Krita’s private app data directories. - It returns content:// URIs instead of standard absolute file paths, breaking the "save backup alongside original project file" functionality. As a fallback, the system forces all auto-backups to be stored under /storage/emulated/0/Android/data/org.krita/files/Documents/krita-backup/, trapped within inaccessible private storage limits. Most Krita mobile artists lack advanced file management utilities to retrieve these backups. This analysis is my logical deduction, and the attached screenshots fully illustrate this limitation. Additionally, I hope the built-in file picker can be upgraded with standard file operation features: copy, paste, move files and folders. A GUI-based permission modification tool would also be a valuable addition if development resources permit. Countless tablet and Android mobile artists will encounter identical storage access limitations, yet most lack background knowledge of Android system underlying mechanisms and will not submit improvement requests. Upgrading this file browser will deliver immense convenience to the entire mobile Krita user base. Full file management functionality prevents permanent loss of artwork and project backups, a high-stakes concern for all creators. Users may also opt to store confidential private project assets inside Krita’s isolated private directories for enhanced data privacy, similar to a secure digital journal. 2. Use case justification for mobile Krita: portable game concept art creation for independent pre-production development My hardware configuration delivers sufficient performance for professional drawing workflows. This statement contains no commercial promotion or third-party sponsorship. Device hardware specs: OnePlus Ace Racing Edition with a minimum of 16GB memory (12GB physical RAM + 4/8/12GB virtual memory expansion options), 256GB internal storage, optimized native ColorOS Android display rendering pipeline. The screen resolution is 1080×2412, fully functional for design work. Minor UI clipping issues beyond viewport boundaries can be resolved via screen rotation; dragging window title bars enables interaction with off-screen controls. Over 90% of Krita’s feature set operates flawlessly on this hardware, and I have reliable workarounds for all minor screen compatibility quirks. Screen rendering limitations do not hinder core concept design work. Contact Information for follow-up communication For official development team correspondence only: <REDACTED> Note to third-party readers outside the Krita dev team: Please refrain from unsolicited messages, spam calls or SMS. Thank you for your understanding and cooperation. Thank you sincerely for reading this lengthy detailed report written in Chinese. I hold deep respect for all members of the Krita development team. Best regards, A devoted mobile Krita independent game concept artist -- You are receiving this mail because: You are watching all bug changes.
