Closed sky96111 closed 2 years ago
目前的体验，ShizukuAPI系列的产品碎片化是很严重的，严重影响了使用体验。很遗憾这么一个年轻的项目早早的出现了历史负担，于是有了Shizuku桥的想法
现在高权限应用分出了好几个阵营： 1.仅支持ShizukuAPI的Rikka系：nopopping、AppOps 2.仅支持Shizuku，不支持Sui：年久失修的「冰箱」「安装狮」、认为root用户就该用libsu的「DarkQ」 3.仅支持Sui，不支持Shizuku的（不包括因为shell权限不足而无法实现某些功能故不支持Shizuku的应用）「Material Files」（这里认为文件管理器支持shell权限的Shizuku是有意义的：可以优雅地读写Android/data文件夹） 4.API已经满足支持Sui和Shizuku，但是需要明确拒绝su权限才进入ShizukuAPI权限判断，甚至硬编码了包名判断，只有安装了Shizuku才能调用Sui的「DarkQ」
ShizukuAPI在一些软件中极大地加快了软件速度，但是一些极端的想要尽量让app有就用ShizukuAPI的场景，可能需要同时拥有Shizuku和Sui才能正常工作
于是我想能不能通过一个极小的同名Shizuku的安装包，桥接一些对Shizuku的调用到Sui上，或者Sui的调用到Root Shizuku，帮助一些古老的设计不佳的应用保持兼容，同时也减少用户安装软件数量？
虽然按照标准，这些行为都应该是能被避免的，纵容这些不规范可能会让以后的生态更糟糕，但作为用户…我真的不想装那么多软件实现同一个功能😭
目前的体验，ShizukuAPI系列的产品碎片化是很严重的，严重影响了使用体验。很遗憾这么一个年轻的项目早早的出现了历史负担，于是有了Shizuku桥的想法
现在高权限应用分出了好几个阵营： 1.仅支持ShizukuAPI的Rikka系：nopopping、AppOps 2.仅支持Shizuku，不支持Sui：年久失修的「冰箱」「安装狮」、认为root用户就该用libsu的「DarkQ」 3.仅支持Sui，不支持Shizuku的（不包括因为shell权限不足而无法实现某些功能故不支持Shizuku的应用）「Material Files」（这里认为文件管理器支持shell权限的Shizuku是有意义的：可以优雅地读写Android/data文件夹） 4.API已经满足支持Sui和Shizuku，但是需要明确拒绝su权限才进入ShizukuAPI权限判断，甚至硬编码了包名判断，只有安装了Shizuku才能调用Sui的「DarkQ」
ShizukuAPI在一些软件中极大地加快了软件速度，但是一些极端的想要尽量让app有就用ShizukuAPI的场景，可能需要同时拥有Shizuku和Sui才能正常工作
于是我想能不能通过一个极小的同名Shizuku的安装包，桥接一些对Shizuku的调用到Sui上，或者Sui的调用到Root Shizuku，帮助一些古老的设计不佳的应用保持兼容，同时也减少用户安装软件数量？
虽然按照标准，这些行为都应该是能被避免的，纵容这些不规范可能会让以后的生态更糟糕，但作为用户…我真的不想装那么多软件实现同一个功能😭