- Kotlin 98.7%
- Shell 0.6%
- Python 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
skipper
7d9cb58138
The merge made these modules' test source sets compilable, so 20 tests that never ran at fork HEAD now execute. All 20 are pre-existing upstream/fork issues surfaced by the merge, not merge regressions. Test-only changes; no production behaviour is affected. unifiedpush UnifiedPushParserTest (4): RoomId/EventId debug validation is disabled by the `&& false` guard in RoomId.kt / EventId.kt, so parse() of a malformed id no longer throws. Replaced assertThrowsInDebug with lenient non-null assertions on the raw value the parser now returns (marked with a comment explaining the guard). rageshake DefaultBugReporterTest (5): - EXPECTED_NUMBER_OF_PROGRESS_VALUE 18 -> 36: the OkHttp write-listener callback count is request-body-size and environment dependent, and changed after upstream updates. - truncation test: the crash call stack is capped at take(5000) before truncateDescription runs (far below MAX_DESCRIPTION_SIZE), so an over-long description must now come from problemDescription (which is not capped) to trigger the truncation marker. rageshake BugReportPresenterTest (1): "send failure description too short" needs a non-internal build (minBugReportLength = 10) for "bug!" (4 chars) to be genuinely too short; pass aBuildMeta(isDebuggable = false) via a new optional createPresenter param. mediaupload AndroidMediaPreProcessorTest (10): @Ignore with reason - the test assets (image.jpeg/png, animated_gif.gif, image.svg, text.txt, sample3s.mp3) were never committed in any ref. Per decision these are ignored rather than fabricating binary fixtures; report upstream so the fixtures can be added. ktlint cleanup (loose ends from prior merge-fix work): - DefaultMediaSenderTest.kt: moved `// SC` markers off inline positions that trip ktlint (type-argument list, lambda arrows). - BugReportPresenterTest.kt: fixed lexicographic import order. All five touched files are now ktlint-clean. Result: :libraries:pushproviders:unifiedpush:test, :features:rageshake:impl:test and :libraries:mediaupload:impl:test -> BUILD SUCCESSFUL (161 tests, 0 failures; 19 skipped = 9 pre-existing + 10 new @Ignore). |
||
| .fastlane | ||
| .github | ||
| .idea | ||
| .maestro | ||
| annotations | ||
| app | ||
| appconfig | ||
| appicon | ||
| appnav | ||
| changelog.d | ||
| codegen | ||
| docs | ||
| enterprise@6b422f4c8e | ||
| features | ||
| gradle | ||
| graphics | ||
| libraries | ||
| metadata/en-US | ||
| plugins | ||
| sc_tools | ||
| schildi | ||
| screenshots | ||
| services | ||
| tests | ||
| tools | ||
| upstream_infra | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| .lfsconfig | ||
| AGENTS.md | ||
| build.gradle.kts | ||
| CLAUDE.md | ||
| correct_strings.sh | ||
| create_variant_resources.sh | ||
| fastlane | ||
| FEATURES.md | ||
| fix_merge.sh | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| increment_version.sh | ||
| LICENSE | ||
| LICENSE-COMMERCIAL | ||
| merge_helpers.sh | ||
| pre_merge.sh | ||
| readme.md | ||
| settings.gradle.kts | ||
SchildiChat Android Next — Enhanced Edition
This repository hosts an enhanced version of SchildiChat Android Next — a Matrix client based on Element Android X in the tradition of the original SchildiChat for Android which was based on the now deprecated Element Android codebase.
Note that this is not the regular SchildiChat Next: these builds are based on the upstream SchildiNext codebase but ship with extra features on top of it — most recently full support for sticker & emoticon image packs (MSC2545): send stickers from the composer, insert emoticons inline, and use emoticons as reactions — plus a timeline font size setting. An overview over all changes compared to Element X can be found here.
Similarly to Element X, this SchildiChat Android rewrite should still be considered beta, as it lacks some functionality which one might expect from a fully-featured chat app, compared to the old SchildiChat implementation.
Note for F-Droid: You can get faster updates directly from the developer by adding the SpiritCroc F-Droid repository. These builds usually match the releases in the official F-Droid repository thanks to reproducible builds, but get built directly on app update and do not need to go through a possibly lengthy build process on the F-Droid servers.
Beta builds for testing pre-release versions are available from the SpiritCroc testing F-Droid repository under a different package name, and can thus be installed next to the stable release.
Releases: Prebuilt phone APKs (arm64-v8a / armeabi-v7a / universal) are published on the Forgejo release page; this repository's default branch carries the current feature set, including the MSC2545 sticker & emoticon work.
Current state of development
Since Android support has landed in SchildiChat Revenge, Next is no longer my main focus for Android.
This means, for now Next will still receive updates (including upstream merges / Element X updates), but likely will not gain any significant new Schildi-specific features.
Translations
If you want to translate SchildiChat, visit our weblate.
Translations that concern upstream Element code are best contributed directly to Element, who currently manage translations on localazy.
Screenshots
Building
In general, building works the same as for Element X or any common Android project. Just import into Android Studio and make sure you have all the required SDKs ready.
WYSIWYG development
To develop changes in our matrix-rich-text-editor fork:
Build WYSIWYG locally
- Clone the repo
- Bump the version number to some future version that doesn't exist yet
using
./update_version 1.2.3where1.2.3is your chosen version number. By not re-using any existing version number you can make sure you're using your local build if the build of SchildiChat succeeds. - Publish the wysiwyg by running
make androidin its directory. (Make sure you haveJAVA_HOME,ANDROID_NDK_HOMEand all the build dependencies setup)
Include local-built WYSIWYG in SchildiChat
- Modify
settings.gradle.ktsto insertmavenLocal()into thedependencyResolutionManagement {}block. (Cherry-pick) - Change the version number of
wysiwygingradle/libs.versions.tomlto match the one you published locally.
Contributing
Generally, contributions are welcome!
Note that in order to ease upstream merges, we want to leave the smallest footprint possible on Element's sources
when implementing original features or patching Element's behaviour.
In particular (may change a bit while the project is still in alpha):
- Put code into additional files (
chat.schildi.*package names) if reasonable- Prefer
schildi/libmodule if it doesn't depend on element modules (except maybe strings) - Prefer
schildi/componentsmodule if it depend on some of Element's Design/UI components but nothing else - Otherwise, prefer element module where it makes most sense (or create a new module for bigger features, maybe)
- Prefer
- Put Schildi-specific drawables and other xml resources that override upstream resources into the
scbuild flavor- This way, we can use the same name and avoid merge conflicts
- Compare e.g.
libraries/designsystem: we define the flavorscand thus put drawables in thescinstead ofmaindirectory. For new modules that do not feature ascflavor yet, copy over the requiredbuild.gradle.ktscontent from a module that does.
- Put Schildi-specific strings into
schildi/lib- Never touch upstream strings! If we want to change Element's strings, we'll either want a script that patches them,
so we can restore upstream strings before upstream merges and re-do our changes automatically after the merge,
or alternative put it into an
scbuild flavor, if we do not need to touch multiple translations.
- Never touch upstream strings! If we want to change Element's strings, we'll either want a script that patches them,
so we can restore upstream strings before upstream merges and re-do our changes automatically after the merge,
or alternative put it into an
- Don't worry too much about code style if violating it can ease upstream merges
- When putting upstream code into a new block (e.g., putting it in an
if-statement), don't indent the upstream code, but rather add comments like// Wrong indention for merge-ability - startand// Wrong indention for merge-ability - end
- When putting upstream code into a new block (e.g., putting it in an