Guide summary
Read and fix package reports
A good package report should tell the user what failed, why it matters, what can be repaired safely, and what evidence support needs if the package still fails.
Check resolution, fps, part lines, loop counts, pause values, and unsupported assumptions before changing files.
Confirm part names, image sequence order, dimensions, and missing or corrupt frames.
Explain what CRYA changed and what still needs user review before install or store submission.
Keep the report, device model, app version, and exact export mode together.
| Collect first | Package ZIP, Package Doctor report, screenshot or copied error text, device model, Android/One UI version, and export type. |
|---|---|
| Common failures | Missing desc.txt, wrong folder names, mismatched frame dimensions, unsupported fps, empty part folders, or invalid archive nesting. |
| Safe repair rule | CRYA can suggest structural fixes, but users should keep backups and review the result before root/system-level use. |
| Store review | Creator submissions should include the clean package report and compatibility notes so reviewers do not need to guess. |
| Private data | Do not post account, billing, or private download links in public support threads. |
Workflow
Use this sequence
A practical flow that maps the public docs back to app behavior and support evidence.
Import the ZIP or working folder into Livingstone.
Let Package Doctor inspect structure, media, and timing.
Apply guided repairs or edit files with the report open.
Check the result before clean export or store submission.
Send the report and device context to support if blocked.
Related CRYA docs
Continue with the next useful page
The docs should move users between package work, safety, billing, store review, and support without exposing private admin systems.