CRYA Community
A home for creators, testers, and Android modders.
Share work, report issues, help improve packs, follow releases, and join a creator ecosystem built around useful moderation and clear rules.
Community lanes
A useful place for each kind of conversation
CRYA community should help users find the right route quickly while private account, billing, and moderation decisions stay protected.
Present boot animation previews, creator notes, model support, and seasonal collections.
Send useful package and app evidence so support can triage without guessing.
Rules, trust levels, warnings, and review trails protect users and creators.
General troubleshooting belongs in public; account, billing, deletion, and private links move to support.
Announcements, status updates, store highlights, and app changes should be short, dated, and easy to verify.
Repeated questions should become docs, AI knowledge, support templates, or app fixes instead of staying scattered.
Contribution loop
How community work becomes product quality
The community should not just chat; it should help CRYA improve packages, docs, creator rules, and support evidence.
Creators post previews, compatibility notes, source context, and package reports.
Users try packs, record device context, and report visual or export problems clearly.
Support separates app bugs, package errors, device limits, and service issues.
Moderators and admin tools turn useful reports into decisions, docs, or store updates.
Approved improvements become updated packs, better help pages, AI knowledge, or release notes.
| Announcements | Release notes, maintenance windows, store highlights, and verified admin messages. |
|---|---|
| AI Help | General package questions, docs routing, and safe troubleshooting through reviewed knowledge. |
| Support | Evidence collection and triage guidance without sharing private account data publicly. |
| Boot Store | Pack discovery, submission questions, compatibility notes, and creator pack updates. |
| Showcase | Previews, creator drops, seasonal prompts, and community recognition. |
Trust rules
Good communities need visible boundaries
Users should know what can happen publicly, what moves to support, and what stays in Mission Control.
No private account, billing, token, or admin details in public channels.
Root/system advice stays recovery-first and avoids unsupported promises.
Creator credit, ownership notes, and source claims should be reviewable.
Warnings, blocks, grants, payouts, and disputes belong in protected admin workflows.
Community routes
Where people should go next
Public routes should point people to the right product surface instead of burying them in a chat thread.
Profiles, badges, submissions, competitions, showcase paths, and creator quality signals.
OpenBotLivingBootBOTTelegram topic routing, AI help, support evidence, store updates, and status-aware answers.
OpenHelpSupportPrivate support paths for account, billing, deletion, store review, and sensitive reports.
OpenStatusStatusMaintenance windows, heartbeat checks, service health, and public incident guidance.
Open