feat: pluginize native bridge capabilities - #67
Merged
Conversation
- adopt napi-ohos 1.2 and upgraded ohos bindings (arkui 0.2, xcomponent 0.3, ime 0.2, web 0.2, display 0.1, resource-manager 0.3, hilog 0.2) from main - keep the 4 plugin workspace deps of this branch - prek.toml rustfmt hook from main (cargo fmt --check) - demo_native: main's MouseEvent-aware event match - regenerate Cargo.lock
Split both capabilities of #65 into the pluginized bridge model on the pluginized-bridge base: - plugin-url (ohos.url / open-url): external link opening via context.openLink (async/ability), absolute-URL validation on the Rust facade - plugin-files (ohos.files / file-dialog): DocumentViewPicker open/save/folder dialogs (async/ability) File dialog parameters travel as a structured named N-API object (ohos.files.DialogOptions with structured DialogFilter { name, pattern }); no string-encoded filter grammar crosses the bridge - the picker-specific 'name|*.ext' choice strings and ';'-separated patterns are converted only inside the ArkTS plugin. demo & docs: - demo_native: demo_open_url, demo_file_dialog_open, demo_file_dialog_save - demo EntryAbility registers ohos.url and ohos.files - Index.ets: new 'Platform services demo' tab - plugin-development-standard.md + named-napi-contracts skill contract tables
Follow-up work on top of the PR #65 pluginization: - abstract plugin bases (PluginBase / AsyncPluginBase / SyncPluginBase): execution mode fixed by the base, identity declared once on the plugin, optional lifecycle hooks with default no-ops; exported from @ohos-rs/ability - registration: identity no longer repeated — BridgePluginFactory reduced to { modules?, create }, LazyPlugin wraps a per-session instance closure, and the context is lazy-injected via attachContext() after creation (before onInstall); factory/plugin consistency check removed (instance is the single source of truth) - hvigor ArkTS compiler fixes: restore literal annotations (ArkTS rejects as const), drop as unknown / indexed-access types, definite-assignment-safe init chain with failure logging in NativeAbility - demo.raw factory contract + DemoNodePlugin.requires mismatch fixed - demo buttons overflow fixed (Flex wrap + Scroll) - ignore build artifacts (oh_modules, build dirs)
…t onCreate - EagerPlugin: shares one caller-constructed BridgePlugin instance across native modules and Ability sessions, for plugins owning process-wide global state (e.g. ohos.resource); tolerates repeated attachContext - attachBridgeEventSink runs right after module.init in onCreate so ability-only plugins can emit ArkTS -> Rust inbound events on ability-create instead of waiting for ui-context-ready; the render-time attach in DefaultXComponent remains as an idempotent fallback
- new paired plugin: crates/plugin-resource (Rust facade, ResourceBridgePlugin) + plugins/resource (ArkTS wrapper, ResourcePlugin); inbound-only resource-manager-ready event pushes the platform resourceManager object into a native pointer inside the same N-API callback, then all reads go through ohos-resource-manager-binding C API - remove the built-in global resource manager from crates/ability (resource.rs, app.resource_manager(), derive init hook); use ResourceExt / openharmony_ability_plugin_resource::resource_manager() instead - demo: Resource demo page (installed check + raw dir count), EagerPlugin registration in EntryAbility, workspace/demo dependency wiring - docs: plugin-development-standard §3/§8 (inbound event timing, EagerPlugin shared instances), contract-table, crate READMEs
Project overview, build/lint/format commands, architecture map, plugin contract rules and the new-plugin checklist for agents working in this repository.
…bridge The fix targeted crates/ability/src/helper/webview.rs (Rc<ObjectRef> leak) which was deleted by the pluginized-bridge rearchitecture; Rust no longer holds an ObjectRef. Keep the current branch's code and record the reconciliation. Co-Authored-By: Claude <noreply@anthropic.com>
Adds a worker -> main-thread synchronous transport built from the same bridgeInvokeSync function the main-thread path uses, so ArkTS stays agnostic to the caller's thread: - BridgeClient::call_sync_from_worker / BridgeRuntime::call_sync_from_worker for MainThreadSyncBridge plugins; request encoded and response decoded on the ArkTS main thread, results marshalled back over oneshot - main-thread guard rejects calls that would deadlock the N-API main thread - demo: demo_plugin_sync_from_worker spawns a Rust worker that inspects the same demo.main-thread plugin through the new channel - docs: plugin-development-standard §4.1 documents the TSFN sync call path Co-Authored-By: Claude <noreply@anthropic.com>
Restyles the single Index page into grouped capability cards with per-card status lines, a segmented tab bar and busy-state interaction: - DemoCard component renders title/hint/buttons/status; buttons are plain DemoButton data with parent-captured closures (no @BuilderParam, which had a runtime this-binding issue) - four-state status feedback: idle / running (spinner + disabled buttons) / success (green) / error (red) - palette tokens added to color.json; webview and resource results consolidated into single card statuses - includes the worker sync demo button from the TSFN channel feature Co-Authored-By: Claude <noreply@anthropic.com>
Resolve conflicts with main's fix(webview): release controller references safely (#69): - helper/webview.rs: keep the pluginized deletion. The fix (Rc<RefCell<Option<ObjectRef>>> + release_native_ref) addressed the legacy helper where Rust held ArkTS controller references; the pluginized crates/plugin-webview never keeps an ObjectRef, so the fix's goal is achieved by architecture. Its content is identical to the already-merged bd66a48. - demo_native lib.rs: keep the pluginized version; main's hunk uses the removed legacy helper API (Webview/WebViewBuilder/WebProxyBuilder).
Align every plugin package with the @ohos-rs/ability reference layout: - oh-package.json5: add author, keywords and repository fields - oh-package-lock.json5: sync regenerated dependency metadata - CHANGELOG.md for all seven plugins (1.0.0-beta.0) and native_ability (1.0.0-beta.0 entry over the 0.4.0-beta.x history) Co-Authored-By: Claude <noreply@anthropic.com>
- root LICENSE (SPDX "MIT OR Apache-2.0" notice), LICENSE-MIT and LICENSE-APACHE hold the only physical license texts - every package (native_ability, plugins/*) exposes LICENSE, LICENSE-MIT and LICENSE-APACHE as symlinks to the root files, reducing repository file count; package tooling follows symlinks - oh-package.json5 license fields already read "MIT OR Apache-2.0" Co-Authored-By: Claude <noreply@anthropic.com>
Align ArkTS HAR names with the Rust crate naming (openharmony-ability-plugin-*) so each capability is discoverable as a single @ohos-rs/ability-plugin-<name> package: - plugin oh-package.json5 name fields - demo entry dependencies (kept as local file: paths) and imports - documentation references across crates/*/README.md, docs/plugin-development-standard.md and plugin READMEs Co-Authored-By: Claude <noreply@anthropic.com>
- add missing READMEs for plugins/files, plugins/url and the paired crates/plugin-files, crates/plugin-url - every plugin README gains an Install section (ohpm install command) and versioned dependency examples instead of file: protocol paths - drop the outdated local-path note from the permission README Co-Authored-By: Claude <noreply@anthropic.com>
- remove the legacy package/ publish-staging directory (duplicate of native_ability as @ohos-rs/ability) - add ohpm-workspace.yaml declaring native_ability and plugins/* as the source packages for file: dependency resolution - fold publish-readiness updates into native_ability README and lock metadata regenerated by ohpm install Co-Authored-By: Claude <noreply@anthropic.com>
richerfu
added a commit
that referenced
this pull request
Aug 5, 2026
…pr63-pluginized - bridge: adopt main's call_sync_from_worker (worker -> main-thread sync via TSFN) plus tsfn_sync_bridge demo wiring - packages: rename all plugins to @ohos-rs/ability-plugin-* and bump to 1.0.0-beta.0 (author/keywords/repository metadata) matching main's published form; drop the libnative_ability.so dependency from native_ability and plugin lockfiles - keep PR #63 pluginization: clipboard/menu/statusbar/updater/version crates and HARs, evolved webview/window/app-control plugins, demo registrations - delete legacy package/ staging dir (main removed it; workspace excludes it) - docs: fold main's call_sync_from_worker guidance into AGENTS.md and plugin-development-standard.md Co-Authored-By: Claude <noreply@anthropic.com>
ljy9812
pushed a commit
to ljy9812/openharmony-ability
that referenced
this pull request
Aug 20, 2026
…ore + PR harmony-contrib#68 plugins) Phase A0 of bridge migration: merge upstream pluginized bridge architecture into local ohdev branch with conflict resolution. Key changes: - Restored helper module from pre-merge (needed by legacy feature modules) - Preserved deleted files to _legacy/ directories - Merged type.ets: kept old ArkHelper/WebView types + new bridge types - Merged NativeAbility.ets: kept old ProcessInitializer lifecycle (bridge migration in A1+) - Merged DefaultXComponent.ets: upstream new bridge-based architecture - Merged MainPage.ets: kept old MenuBarComponent/WindowManager integration - Fixed xcomponent-sys version mismatch (0.0.2 -> 0.1) - Fixed axis event FFI (private in newer sys crate, re-declared locally) - Removed duplicate MouseEvent variant in input/mod.rs Compilation: 0 errors on both aarch64-unknown-linux-ohos and Windows. Rollback tag: pre-bridge-merge
ljy9812
pushed a commit
to ljy9812/openharmony-ability
that referenced
this pull request
Aug 22, 2026
…on and plugin migrations - pluginize native bridge capabilities (harmony-contrib#67), normalize node surface (harmony-contrib#70), transparent XComponent background (harmony-contrib#73), webview controller release safety (harmony-contrib#69) - plugin module agnostic refactor (harmony-contrib#75), serialize ability plugin lifecycle (harmony-contrib#74) - account/updater bridge migration and clipboard write-html API - dead code cleanup superseded by the bridge plugin architecture - deps upgrade, format + git hook Co-Authored-By: Claude <noreply@anthropic.com>
ljy9812
pushed a commit
to ljy9812/openharmony-ability
that referenced
this pull request
Aug 27, 2026
…on and plugin migrations - pluginize native bridge capabilities (harmony-contrib#67), normalize node surface (harmony-contrib#70), transparent XComponent background (harmony-contrib#73), webview controller release safety (harmony-contrib#69) - plugin module agnostic refactor (harmony-contrib#75), serialize ability plugin lifecycle (harmony-contrib#74) - account/updater bridge migration and clipboard write-html API - dead code cleanup superseded by the bridge plugin architecture - deps upgrade, format + git hook Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
close #65