鸿蒙6/鸿蒙NEXT WebView套壳APP源码

鸿蒙6/鸿蒙NEXT WebView套壳APP源码

本文使用AI生成!


一、事情的起因(真实踩坑)

我之前一直在做一个网页项目,但因为业务展示的原因,需要打包成 APP 使用。

在鸿蒙 4.2 的时候,这件事其实非常简单:

  • 找一个安卓 WebView 套壳 APP
  • 用 MT 管理器改一下 URL
  • 直接就能用了

整个流程几乎是“无脑操作”,而且这个方案稳定跑了一年多,没有任何问题


二、问题爆发:升级鸿蒙 NEXT 后直接炸了

直到今年(2026),我换了新手机(Mate80ProMax),系统直接升级到了 鸿蒙 6(HarmonyOS NEXT)

问题就来了。

虽然可以通过“卓易通”兼容运行之前的安卓壳子,但是:

文件上传直接废了

具体表现是:

  • <input type="file"> 还能点
  • 但是:
    • ❌ 不能调用相机拍照
    • ✅ 只能从本地相册选图片

原来是可以选择相机或文件上传的:

在这里插入图片描述

新版点击选图,直接跳转文件页面:

在这里插入图片描述

这对我来说是致命问题,因为我的业务是需要现场拍照上传的。


三、为什么会这样?(踩坑分析)

我后面查了一圈 + 问 AI,大概原因是:

👉 鸿蒙 NEXT 出于隐私安全考虑:

  • 不再允许 WebView 直接调用系统相机
  • H5 的文件选择需要宿主应用手动拦截
  • 再由原生代码去:
    • 调起相机 / 相册
    • 拿到结果
    • 回传给网页

简单说就是:

👉 以前安卓是“自动帮你做”,现在鸿蒙是“你自己写一套流程”

四、我尝试过的几个方案(全踩坑)

方案1:找现成鸿蒙 WebView 套壳

结论:

❌ 没找到能用的

要么:

  • 不支持文件上传回调
  • 要么压根不是鸿蒙 NEXT 原生

方案2:反编译原来的安卓壳子改

思路是:

  • 找 WebView 相关代码
  • 修改文件选择逻辑

问题:

❌ 太麻烦,而且不一定能编译成功

方案3:前端绕过(JS 调相机)

比如:

  • 用 H5 API 直接调用摄像头

问题:

❌ 如果壳子没权限,一样没用

五、为什么必须解决?

有朋友可能会说:

那你用旧手机不就行了?

问题是:

  • 我现在要频繁改网页功能
  • 必须实时验证在 APP 里的效果
  • 总不能天天带两台手机开发吧…

👉 这完全不现实


六、最终决定:自己写一个鸿蒙原生壳

被逼无奈,我直接上手:

✅ 用 ArkTS 写了一个 HarmonyOS NEXT 原生 WebView 套壳应用

于是这个项目就诞生了👇


七、这个项目能做什么?

简单说一句话:

👉 改一个 URL,就能把网页打包成鸿蒙 APP

目前已经做了这些功能:

  • ✅ WebView 全屏加载网页
  • ✅ 支持 JS / DOM Storage / 图片访问
  • ✅ 文件上传支持(相机 + 相册)
  • ✅ 返回键拦截(网页返回 + 双击退出)
  • ✅ 启动页(Splash)
  • ✅ 权限自动申请(相机 / 相册)
  • ✅ 沉浸式体验(隐藏导航条)

八、最关键:文件上传问题已解决 ✅

重点来了:

👉 现在可以正常:

  • 📸 直接拍照上传
  • 🖼️ 相册选择上传

也就是把鸿蒙 NEXT 缺失的那一段:

“WebView → 原生 → 相机 → 回传”

👉 全部补齐了


九、项目地址

👉 GitHub:项目地址

https://github.com/ZhaoYuLiOfficial/HarmonyOS6-WebView-Shell 

👉 Gitee:项目地址

https://gitee.com/ZhaoYuLiOfficial/HarmonyOS6-WebView-Shell 

(如果对你有帮助,欢迎点个 Star ⭐)


十、总结

这次踩坑最大的感受就是:

👉 鸿蒙 NEXT 对安全收得很紧,但开发成本确实上来了

以前安卓一句话能搞定的事情:

现在需要自己补一整套逻辑。

不过好处是:

  • 权限更清晰
  • 行为更可控

🤝 交流 & 反馈

如果你也在做类似的项目,或者遇到类似问题:

  • 欢迎留言交流
  • 也可以提 Issue 一起讨论

本文使用AI生成,大神们轻点喷,大学生第一个开源项目呜呜

Read more

区块链|WEB3:时间长河共识算法(Time River Consensus Algorithm)

区块链|WEB3:时间长河共识算法(Time River Consensus Algorithm)

区块链|WEB3:时间长河共识算法(Time River Consensus Algorithm)(原命名为时间证明公式算法(TCC)) 本共识算法以「时间长河」为核心设计理念,通过时间节点服务器按固定最小时间间隔打包区块,构建不可篡改的历史数据链,兼顾区块链的金融属性与信用属性,所有优化机制形成完整闭环,无核心逻辑漏洞,具体总结如下: 一、核心机制(闭环无漏洞) 1. 节点准入与初始化:候选时间节点需先完成全链质押,首个时间节点由所有质押节点投票选举产生,彻底杜绝系统指定带来的初始中心化问题,实现去中心化初始化。 2. 时间节点推导与防作弊:下一任时间节点通过共同随机数算法从上一区块推导(输入参数:上一区块哈希、时间戳、固定数据顺序),推导规则公开可验证;时间节点需对数据顺序签名,任一节点发现作弊(篡改签名、操控随机数等),该节点立即失去时间节点资格并扣除全部质押。质押的核心目的是防止节点为持续获取区块打包奖励作弊,作弊损失远大于收益,确保共同随机数推导百分百不可作弊。 3. 节点容错机制:每个时间节点均配置一组合规质押节点构成的左侧顺邻节点队列(队列长度可随全网节点规

Web 渗透实战:OWASP Top 10 核心漏洞 从原理到完整防御

Web 渗透实战:OWASP Top 10 核心漏洞 从原理到完整防御

很多 Web 安全从业者和新手,对 OWASP Top 10 的认知停留在 “知道漏洞名”,却不懂 “漏洞为什么会出现”“怎么手动复现”“企业该怎么防”—— 比如只会用 Sqlmap 扫 SQL 注入,却看不懂有漏洞的 PHP 代码;知道 XSS 危险,却写不出防御用的编码函数。其实 OWASP Top 10 的核心不是 “记住漏洞列表”,而是 “理解每个漏洞的攻防逻辑”,这是 Web 渗透和安全开发的基础。 本文精选 OWASP Top 10 中 8 个 “高频且影响严重” 的漏洞,每个都配 “真实代码片段 + DVWA/Vulhub 实战步骤

IntelliJ IDEA 打包 Web 项目 WAR 包(含 Tomcat 部署+常见问题解决)

IntelliJ IDEA 打包 Web 项目 WAR 包(含 Tomcat 部署+常见问题解决)

一、引言 对于 IntelliJ IDEA 新手来说,Web 项目 WAR 包打包常因步骤多、配置深而卡壳,且多数教程仅讲“打包”却忽略“部署验证”和“问题排查”。本文将从前置准备→核心配置→打包验证→Tomcat 部署→问题解决,带你完整走通流程,避开 90% 的常见坑。 二、前置准备:确认基础配置(避免起步就错) 在开始打包前,先检查 3 个关键前提,缺失任一环节可能导致后续操作失败: 1. 确认项目类型:打开项目结构(快捷键 Shift+Ctrl+Alt+S),在「Modules」中查看模块类型是否为「Web Application」,若不是,

前端如何应对精确数字运算?用BigNumber.js解决JavaScript原生Number类型在处理大数或高精度计算时的局限性

前端如何应对精确数字运算?用BigNumber.js解决JavaScript原生Number类型在处理大数或高精度计算时的局限性

目录 前端如何应对精确数字运算?用BigNumber.js解决JavaScript原生Number类型在处理大数或高精度计算时的局限性 一、BigNumber.js介绍 1、什么是 BigNumber.js? 2、作用领域 3、核心特性 二、安装配置与基础用法 1、引入 BigNumber.js 2、配置 BigNumber.js 3、常用方法 ①创建 BigNumber 实例 ②基本运算 ③幂运算 ④绝对值 ⑤舍入 ⑥比较 ⑦格式化输出 ⑧链式调用 三、核心特性 1、大数精度丢失问题 2、小数运算精度问题 3、大数乘除法精度问题 四、总结         作者:watermelo37         ZEEKLOG万粉博主、