嘿，我最近在API 101开发时也踩过这个坑——getModuleContext()确实已经从XposedModule基类中被移除（或标记为废弃）了。如果要访问模块自身的资源（比如strings.xml里的本地化字符串），我们需要换用getModuleApplicationInfo()来手动初始化资源，下面是完整的可行方案和原因说明：

替代实现方案 #

这是在API 101中加载模块资源的标准写法，你可以直接在onPackageReady方法中实现：

@Override
public void onPackageReady(@NonNull PackageReadyParam param) {
    // 仅针对目标应用执行（这里以SystemUI为例，可根据需求修改）
    if (!param.getPackageName().equals("com.android.systemui")) return;

    try {
        // 1. 获取当前模块的ApplicationInfo对象
        ApplicationInfo moduleInfo = getModuleApplicationInfo();
        
        // 2. 初始化AssetManager并添加模块APK的路径
        AssetManager assets = AssetManager.class.newInstance();
        Method addAssetPath = AssetManager.class.getMethod("addAssetPath", String.class);
        addAssetPath.invoke(assets, moduleInfo.sourceDir);
        
        // 3. 基于系统配置创建模块专属的Resources对象
        Resources systemRes = Resources.getSystem();
        mRes = new Resources(assets, systemRes.getDisplayMetrics(), systemRes.getConfiguration());
        
        // 现在就能用mRes.getString()或mRes.getIdentifier()
        // 访问模块里的本地化资源了
    } catch (Throwable t) {
        Log.e("Back2Kill", "加载模块资源失败: " + t.getMessage());
    }
}

为什么API会有这个变化？ #

新的API 101采用了更“轻量化”的设计思路，核心是为了提升在不同Android版本和Xposed加载器（比如LSPosed）之间的兼容性。通过手动加载AssetManager，我们的模块可以彻底独立于目标应用的上下文，避免了不同环境下上下文冲突的问题，让模块在各种场景下的稳定性都能得到保障。