模拟点击是如何防止作弊的
github.com/Nain57/Smart-AutoClicker
今天淘宝有红包，想找一个模拟点击，结果识别的有效点击次数很少
猜测

检测位置不能一直是同一个坐标（软件开了防作弊会随机坐标）
时间不能太快

模拟点击的按下和抬起的之间的延时分布不符合人工点击的延时分布。

谢谢，理解了。手工点击的时间间隔会更随机，疲劳可能导致时间时间会变大。

很简单，入职阿里的端防团队你就知道了。要是年薪快百万每年产出就这个怕是早就要被开了。

不可能告诉你的，知道也不会告诉你的

web 端有移动轨迹移动端有移动轨迹和按压压力，最后你这个软件如果不需要 shell 权限，那么应该是通过无障碍服务功能实现，这对于目标应用来说是可见的，相当于你明牌了，告诉人家，你用了工具点击的。

这个可能只是一方面，实际上判断的途径会有很多

1 、压力2 、轨迹3 、基于以上 2 点，机器学习判断

弄一个马斯克的 optimus 机器人，把手机给它来点也许能行

我感觉直接拾取人工按一分钟的数据然后回放，怎么样？

＃9 基于我的对抗经验，如果你有足够多的轨迹回放，那么在规模不大的应用场景下，是可行的。如果回放轨迹较少，那么用不了几次，风控也就上来了。

多谢，看来可以花点钱请一百个志愿者来点击半个小时，然后随机组合一下。。。

这个模拟点击的 app 我也在用，它不是自带反侦测随机漂移坐标的功能吗

App 最多能看到有哪些无障碍服务在运行，不能看出某次点击是否来自无障碍吧

＃13 如果你指的是直接检测，给个 true or false 的结果，那么暂时是不太可行的。但是还是有比较方便的方法来测试。假设张三希望在某 app 进行自动登陆，通过无障碍服务实现，找到 ID 为 abc 的 textview 就准备往里填写用户名。而目标应用为了避免这种情况，只需要代码里 new TextView ，并赋 id 为 abc ，并不需要真的 attach 到 View ，调用类似这样的代码textView.sendAccessibilityEvent(AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED);如果最后 textview 里真的有值了，那么就是有无障碍服务操作，因为此时这个组件并不在用户可见的视图，类似的变种，比如视图先放到可视区域以外，size 先做的很小。透明度调低等等，开动小脑袋瓜，还有不少。accessibilityManager.getInstalledAccessibilityServiceList()[*].packageNames 也可以知道哪些无障碍服务正在辅助自己，packageNames 为 null 或者自己的包名，那么都是自己的专辅。同时目前 Android 上无障碍服务的正经应用并不多，建立个白名单并不困难。除了少数几个正经应用，其他我不认识的应用，还在辅助我，风控等级就往上调就行了。

一般会综合多个维度判断的，像上面提到的坐标轨迹，还有像传感器（加速度计），系统环境，后台进程等

我看这个 APP 是基于无障碍服务实现派发点击手势的，其实不通过无障碍接口也能实现同时上面 ＃14 说的 getInstalledAccessibilityServiceList 也检测不出来原理是基于 shizuku 绑定服务调用 UiAutomation 获取屏幕无障碍节点，通过 input tap x y 执行点击

真实点击是多点触碰，模拟点击是单点触碰。

调一下摄像头发现屏幕前没有人(瞎说的

那个上面说阿里的什么防团队年薪百万啥啥的真给我整笑了，能不能让这些年薪百万的天才们把阿里系那个傻叉的要死的验证条功能做好一点啊，说到底不还是有海量的瞎猜和误报。

1. 现在很多这种自动操作 App 为了避免这种情况，都是用的坐标点击，而不是激活某个“钓鱼控件”。2. 正经的无障碍服务很多，如果你关注过盲人的圈子，他们甚至会自己开发各种各样小众的辅助工具，这些都是真实的无障碍需求，如果一刀切（甚至你提到的第一种情况）会让真正需要无障碍的人无法操作。

＃20 用坐标并避免不了，Activity 还是能获取到对应的事件，只是简单的猫鼠游戏，正常用户就不应该按这种欺骗性的按钮。正经的无障碍服务应用还是很容易搜集的，尤其对于大厂，因此白名单足以满足。最后，我承认有很多残障人士，假设他们用了一些不太常见的辅助应用，但是对于风控来说，尤其是涉及到钱的风控，一刀切在许多厂家眼里是合理的选择。