HarmonyOS 鸿蒙Next中闪控球实现账号密码显示及快捷输入功能替代方案

HarmonyOS 鸿蒙Next中闪控球实现账号密码显示及快捷输入功能替代方案 【问题描述】:想通过全局闪控球实现一个大致功能:用户在应用内保存的密码或文字通过闪控球显示,在切换到其他应用时,可以依照闪控球进行输入,输入完毕后再回到应用关闭显示或直接关闭显示。但是申请ohos.permission.USE_FLOAT_BALL权限没有通过,提示不符合使用场景。想问下闪控球的场景要求这么严格吗?还有没有其他替代方案

【问题现象】:已经做了复制粘贴功能,就是有些密码输入场景可能无法直接粘贴。目前就是有些应用或页面需要输入密码的时候,可能无法直接粘贴,得一个一个字符输入。想问是否还有其他方案能实现类似功能,或者是比如在其他应用中输入图片中的文字,这种情况也没法通过复制粘贴的形式,可以理解为“跨应用信息输入”但是确实使用场景很少见

【版本信息】:开发工具版本:6.1.0、手机系统版本:6.1.0.117、Api语言版本:23

【复现代码】:未涉及

【尝试解决方案】:未涉及


更多关于HarmonyOS 鸿蒙Next中闪控球实现账号密码显示及快捷输入功能替代方案的实战教程也可以访问 https://www.itying.com/category-93-b0.html

9 回复

分析申请失败原因:全局闪控球开发指导约束与限制中已明确说明ohos.permission.USE_FLOAT_BALL权限仅对跨应用的题目搜索、账单记录、商品比价、抢单、翻译场景,以及金融类应用的实时盯盘场景开放此权限。 密码显示不在上面场景中,因此申请失败。

替代方案:

  1. 密码属于敏感信息,优先建议参考密码自动填充服务,让应用接入密码保险箱。这样,用户在应用或浏览器进行注册/登录操作时,可一键完成自动生成强密码、自动保存、自动填充,无需记住或手动输入繁琐的密码,由系统实现统一的安全管理密码能力。

  2. 可使用画中画能力,参考案例,无需申请权限。

  3. 使用剪切板,参考使用剪贴板进行复制粘贴,不过需要申请权限,因此只能复制粘贴文字,密码是不行的。

更多关于HarmonyOS 鸿蒙Next中闪控球实现账号密码显示及快捷输入功能替代方案的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


这种能力需要系统层的权限,还是留给官方去做吧

  1. 全局悬浮窗的解决方案参考下这个:《如何实现全局悬浮窗》。看有没有能解决你问题的。
  2. 关于闪控球要求的权限审核严格,看你对使用场景的描述,你要是描述成复制密码用,那估计不好通过。
  3. 还有一个曲线实现你想要的功能的效果的办法。《画中画》。PiPWindow是系统能力,不需其他权限。PiPConfiguration里有个参数customUIController可以接收自定义节点,就可以把要全局显示的信息放上面。

毕竟涉及到用户的隐私,闪控球作用是主要功能快捷化,而不是这种方式,无法通过闪控球实现账号密码显示以及快捷输入(或许可以通过快捷截屏识别屏幕中的文字内容然后复制)

建议通过密码保险箱来进行账号密码保存和快捷输入

系统设置与开关开启

用户需事先设置锁屏密码,并开启密码保险箱自动保存和填入账号和密码开关。这是密码保存功能的基石,确保了后续操作在安全框架内进行,同时为密码管理提供必要的权限基础。

界面组件属性正确设置

界面中的 TextInput 输入框组件必须将 enableAutoFill 属性设为 true(默认即为 true)。并且,密码保险箱仅在用户名和密码输入框同时存在时生效。用户名输入框应设定 type 属性为 InputType.USER_NAME,密码输入框则根据场景设定为 InputType.PASSWORD(用于登录和修改密码时的旧密码输入)或 InputType.NEW_PASSWORD(用于注册和修改密码时的新密码输入)。

输入内容规范

用户名和密码输入框不能为空且长度需符合限制。用户名长度不得超过 128 字符,密码长度不得超过 256 字符,确保输入数据的有效性和安全性。

页面跳转触发保存

密码保存操作在页面跳转时被触发。例如,用户完成登录或注册后页面跳转,系统会根据此前的输入内容和设置,判断是否提示用户保存账号密码。

这个审核结果基本是正常的。

ohos.permission.USE_FLOAT_BALL 属于比较敏感的系统能力,审核会重点看是不是符合系统级悬浮交互场景(如导航、辅助工具、系统服务)。

你这个场景本质是:

跨应用展示账号密码 / 辅助输入

平台通常会认为:

  • 存在隐私泄露风险
  • 有绕过目标应用输入限制的嫌疑
  • 不属于闪控球核心使用场景

所以比较难过审。

为什么场景要求严格?

因为闪控球能跨应用悬浮显示,本质接近系统级覆盖层。

如果放开,容易被用于:

  • 自动填密
  • 覆盖诱导输入
  • 敏感信息展示

所以审核会卡得很严。


替代方案(更现实)

1、系统剪贴板 + 一键复制(最推荐)

你现在已经做了,这是官方最稳方案。

可以优化成:

  • 分类管理
  • 点击即复制
  • 自动返回目标应用

体验会比悬浮球更容易过审。


2、应用内密码键盘 / 快捷短语

如果场景主要是你自家 App 内输入:

可以做:

  • 常用文本快捷插入
  • 密码模板
  • 自定义短语

3、拉起分享/选词能力

对于“图片里的文字输入”,可以考虑:

  • OCR 识别
  • 一键复制识别结果
  • 用户切回目标 App 粘贴

这个审核风险低。


4、用 LiveView / 卡片(有限替代)

如果只是“临时查看内容”,可以考虑:

HarmonyOS 卡片能力

但它只能展示,不适合做跨应用输入辅助。


做不到的:

想实现这种:

在 A 应用保存密码 → 切到 B 应用 → 悬浮显示字符供逐位输入

如果依赖系统悬浮能力,普通应用基本很难过审。

一句话:

USE_FLOAT_BALL 审核严格是正常的,你这个“跨应用密码辅助输入”很难通过;现实可行的替代就是“剪贴板 + OCR + 快捷复制”,不要继续强依赖闪控球权限。

你描述的使用场景感觉就是一个输入法的复制粘贴功能啊

在HarmonyOS鸿蒙Next中,替代闪控球功能可通过ArkUI的TextInput组件实现:使用type属性在InputType.NormalInputType.Password间切换以显示密码;快捷输入利用系统剪贴板API(pasteboard.createData()pasteboard.getData())配合自定义悬浮按钮完成。

闪控球(FLOAT_BALL)权限仅对系统应用或输入法等明确场景开放,普通三方应用申请几乎不可能通过,提示“不符合使用场景”是正常结果。

替代方案上,HarmonyOS Next 推荐使用自动填充框架(Autofill Service),专门解决密码管理器跨应用填充需求。你只需实现 AutofillService,配合用户授权,即可在登录页面自动弹出已保存的账号密码,绕过粘贴限制,体验与系统密码管理一致。对于无法粘贴的图片文字,可先 OCR 识别再通过 Autofill 或剪贴板输出。若场景极少,剪贴板临时中转仍是最轻量的备选。

回到顶部