Repository navigation
feat(ohos): add the HarmonyOS host project - #271
TiaraBasori wants to merge 3 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Automated PR reviewHead: Review unavailable: Free OpenRouter review unavailable (HTTP 429); no paid fallback and no merge. Remaining gates
No PR code runs with the model key or write token. Free-only routing; provider/rate-limit failures never authorize a merge. Existing review findings must be resolved, not hidden by a new recommendation. |
iebb
left a comment
iebb
left a comment
There was a problem hiding this comment.
Reviewed current head 36595e8. The host scaffold is useful, but the submitted stack is not yet a validated runnable target.
The documented first build step requires tdjson-ohos-arm64.zip through the real installer, while the pinned manifest has no such entry. The proposed producer publishes no consumable tdjson-manifest.json, and the paired release PR explicitly continues without libtdjson.so. Please complete the pinned artifact/manifest dependency first and show the resulting HAP actually contains the verified library and can load the required TDLib entry points; template/ArkTS compilation alone does not establish this.
The environment contract also needs to agree across the stack: ohos/README.md requires SDK API 26+, whereas #273 uses an API 22 image and rewrites the engine embedding. Pin one supported engine/SDK combination and provide a successful credential-free build tied to the exact assembled source. The current stock-Flutter Quality job does not compile this host. Validate capability/permission declarations against the native plugins that are actually supported, including graceful handling of unavailable plugins.
Please complete the repository PR template, including the Terms classification and applicable build/runtime evidence. This remains open for the complete integration; it is not being rejected as unrelated.
de4bc7a to
4d48152
Compare
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
TiaraBasori
left a comment
TiaraBasori
left a comment
There was a problem hiding this comment.
在 4d481524 最新 rebase 上的增量（本 PR 新 head 8908bd52）：scripts/install-tdjson-artifact.py 将 tdjson-ohos-arm64.zip 升为 REQUIRED 并支持 per-asset release_tag，scripts/tdjson-manifest.json 新增该条目指向 tdjson#4 次级固定标签 tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2（archive 02b825c75…/15479 + member e8996f…/5242880），ohos/README.md 与 release CI 的 SDK/引擎门控统一（API 26 原生或 CI 的 API 22+受控 HAR 补丁）。
Producer/consumer manifest 闭环：tdjson#4（228e9d3b）已发布不可变 release + pinned schema-v2 manifest（archive/member 摘要 + source/patch/build/package provenance）且永不删除既有 release/tag；消费端按 manifest["assets"]["tdjson-ohos-arm64.zip"]["release_tag"] 下载校验。HAP 内 libs/arm64-v8a/libtdjson.so 的已安装↔已打包字节一致性（含 loader/exports 边界）证据由并行 #273 的 Verify and rename the hap 以只读 assembled source 校验并在 release 管线中作为发布门控。
8908bd5 to
d22b3e8
Compare
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
d22b3e8 to
4f8ddad
Compare
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
4f8ddad to
2261ec0
Compare
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
2261ec0 to
8e0eaa3
Compare
iebb
left a comment
iebb
left a comment
There was a problem hiding this comment.
Reviewed exact head 8e0eaa356c4313b9a47dd0c0b4a0ea7e4fb9893d. Changes requested before publication.
[P2] Register and validate external deep-link entry points. ohos/entry/src/main/module.json5:24–33 registers only the home entity/action. Adding the companion app_links plugin cannot make tg/app links launch this ability without appropriate URI/view-data registration. Add the supported registrations and cover cold-launch plus warm-ability delivery through the actual account-routing path.
I withdraw the old missing-manifest/installer-contract claim: the current manifest requires the OHOS asset with digest, size and per-asset release tag, the helper uses the installer, and SDK documentation is updated. The documented placeholder-ZIP check is not proof of an authentic assembled app, native loader or startup; equally, it is not evidence that an unseen published binary is fake. Provide actual pinned artifact/provenance, assembled credential-free build, required TDLib loader/export and startup evidence. The three changed PNG icons were not inspected in this source review.
Complete the full mandatory .github/pull_request_template.md: prose classification and a partial custom checklist are not the six required basic author checks with concrete evidence. Reviewer-only boxes are not author requirements. User-requested manual handling remains applicable; this PR itself did not touch a controller-protected source path, so that is not the reason for manual handling.
These are source/validation gaps, not a newly reproduced native crash or a blanket rejection of the host scaffold.
No approval is granted. Current-base merged-result Quality is not yet fresh in the reviewed evidence; before publication require fresh ordinary PR Quality on this exact head merged with live master, applicable platform checks, resolved findings and genuine exact-head owner approval. No incoming PR code was executed for this review.
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
8e0eaa3 to
7df493e
Compare
|
Addressed the [P2] deep-link registration at new head The entry module now declares the external link entry points. Stated plainly, as with the earlier heads: this box has no OHOS SDK, so the module change is source-reviewed, not compiled here — the assembled HAP carrying these skills and a cold-launch/warm-delivery smoke on a device or hosted OHOS runner remains the platform evidence, exactly the assembled-target validation you have been asking for across this stack; the skill syntax follows the documented On the template: the body now carries the full mandatory structure — Terms classification (compliant/unchanged; platform hosting only), all six author basic checks with the concrete commands that could be run here and the explicit inapplicability reasons for the ones that need an OHOS toolchain, and |
iebb
left a comment
iebb
left a comment
There was a problem hiding this comment.
Re-reviewed 7df493e1b31fa5b139cabfdfc4abf34517b5fca3. The tg/t.me external-link skills are now declared, and the six basic author checks are present. I withdraw those previous source/template omissions. The code review does not establish cold-launch or warm-ability delivery on OHOS: this still needs an authentic pinned TDLib artifact, a credential-free assembled HAP, and startup/deep-link evidence from the real host/loader. The documented placeholder archive verifies installer mechanics only. Keep the evidence claims at that boundary and complete the template's explicit Terms-classification selection. The host improvement remains open pending those platform gates; no incoming code ran locally.
Make the HarmonyOS host a verifiable runnable target: the manifest now carries tdjson-ohos-arm64.zip with archive+member SHA-256/size and a per-asset release_tag pointing at the immutable tdjson#4 secondary release tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 so scripts/build-hap.sh can install arm64-v8a/libtdjson.so into ohos/entry/libs/arm64-v8a/ via the same pinned schema-v2 manifest contract the release CI uses. The installer validates sha256/size, checks that the zipped member matches the pinned digest, and downloads from the per-asset release when the manifest carries one; HAP verification can then byte-compare libs/arm64-v8a/libtdjson.so against the same pinned entry. Align ohos/README.md with the release job's validated SDK combination (API 26 raw SDK or pinned API 22+patched embedding HAR) and document the controlled embedding patch boundary. Addresses PR iebb#271 review findings: pinned OHOS entry, consumer/producer manifest contract, environment-contract coherence, and build-hap verifiability.
The entry module only declared the home entity/action, so no link could ever target the ability and app_links had nothing to deliver. The entry ability now also declares browsable entity + viewData action with the tg scheme and the https t.me host — the same pair the Android manifest declares — for both cold launch and warm-delivery routing through the account-aware link path.
7df493e to
738fbae
Compare
|
Rebased onto current master |
背景
适配纯血鸿蒙（HarmonyOS NEXT）。本 PR 提交
flutter create --platforms ohos（鸿蒙 fork 3.44.9+ohos-0.0.1-canary1 生成）的宿主工程ohos/，并汉化定制。Change
ohos/完整宿主工程：AppScope/、entry/、hvigor 配置、resources。bundleNamead.neko.mithka（与 android applicationId 一致），versionCode 295 / versionName 1.8.0。module.json5：deviceTypes [phone, tablet]；权限仅ohos.permission.INTERNET。scripts/build-hap.sh：把 pinned 的tdjson-ohos-arm64.zip（成员 arm64-v8a/libtdjson.so）装进ohos/entry/libs/arm64-v8a/libtdjson.so；不负责签名。ohos/README.md：环境要求与构建命令，明确受支持的两种组合——API 26 原生 SDK 或 CI 已验证的 API 22+ pinned embedding HAR 兼容补丁。scripts/install-tdjson-artifact.py：新增tdjson-ohos-arm64.zip为 REQUIRED 并支持按资产的release_tag覆盖，消费端与 tdjson#4 发布的次级固定标签（tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2）对齐，下载来源由manifest["assets"]["tdjson-ohos-arm64.zip"]["release_tag"]指定。scripts/tdjson-manifest.json：新增该条目（archive/member SHA-256/size + 所属 release_tag），其余资产校验与 provenance 保持不变。module.json5（增量）：entry ability 增加 browsable entity + viewData action 与tgscheme、https://t.mehost 的 deep-link 注册——之前只有 home skill，链接永远无法拉起 ability。Telegram API Terms classification
Compliant / unchanged — 本 PR 仅新增平台宿主与原生库安装路径，不涉及 Telegram API 的使用、消息转发、权限或 ToS 相关行为，无合规风险。
Basic checks (every PR)
dart format不适用；shell/Python 走bash -n与安装路径校验。flutter analyze不适用。python3 -c "import yaml, json; yaml.safe_load(open(f))"对受影响的 workflow 与scripts/tdjson-manifest.json校验通过；scripts/install-tdjson-artifact.py tdjson-ohos-arm64.zip ohos/entry/libs/arm64-v8a/libtdjson.so --member arm64-v8a/libtdjson.so --archive <pinned-zip>安装后字节与 pinned member SHA/size 完全匹配，复跑命中 cache；Quality CI 在每个 head 运行。ohos/README.md与feat/ohos-release-ci的 SDK/引擎门控统一（API 26 原生或 CI 的 API 22+受控 HAR 补丁）；assembled source 的 HAP 字节校验见feat/ohos-release-ci的Verify and rename the hap（已安装↔已打包字节对比、ELF/exports 边界）。Commands, results, platform/build/UI evidence, and reasons for inapplicable checks: 本机无 OHOS SDK——
module.json5的 deep-link skills 增量为源级评审，assembled HAP 的冷启动/warm 交付冒烟仍需 OHOS runner（已在 review 回复中如实说明）。Section 1.4 exception checks
不适用：本 PR 未改变与 Telegram 服务器的收发、存储或展示逻辑，未触及 1.4 例外判定。
验证（本次增量在 4d48152 最新 rebase 上的修订）
scripts/install-tdjson-artifact.py升级为 required-ohos + per-assetrelease_tag覆盖，保持与 tdjson#4 次级 release 的 manifest 闭环；本地用 placeholdertdjson-ohos-arm64.zip（15479bytes，02b825c75…）离线校验：--archive安装成功且二次运行命中Verified pinned tdjson。关联
feat/ohos-platform / feat/ohos-pubspec / feat/ohos-release-ci / mithka-tdjson feat/ohos-tdjson（228e9d3b 已落实不可变 release + pinned schema-v2 manifest，见该 PR 描述与 build-ohos.yml）。