嘿，这个问题我之前做跨模块开发的时候也碰到过！Android 8.0开始对隐式广播的限制确实把跨模块通信的老路子给堵了，不过没关系，针对你这种下载模块和应用模块分离、没法直接引用接收器类的情况，我整理了几个靠谱的解决方案：

1. 通过ComponentName构建显式Intent #

虽然下载模块不能直接依赖应用模块的MyBroadcastReceiver类，但我们可以通过包名+接收器全类名来构建ComponentName，从而实现显式广播的发送，不用直接引用目标类。

示例代码：

// 下载模块中发送广播的逻辑
String appModulePackage = "com.your.app.main"; // 替换成应用模块的实际包名
String receiverFullClassName = "com.your.app.main.MyBroadcastReceiver"; // 接收器的完整类路径

ComponentName receiverComponent = new ComponentName(appModulePackage, receiverFullClassName);
Intent downloadCompleteIntent = new Intent("your.original.download.action"); // 可以保留原来的Action
downloadCompleteIntent.setComponent(receiverComponent);

// 发送广播
context.sendBroadcast(downloadCompleteIntent);

注意：需要提前和应用模块约定好包名和接收器的全类名，确保不会因为类路径变更导致失效。

2. 使用LocalBroadcastManager（进程内通信场景） #

如果你的下载模块和应用模块运行在同一个进程里，那LocalBroadcastManager是最优解——它不受Android 8+的隐式广播限制，而且只在进程内传递，安全性和效率都更高。

示例代码：

// 下载模块发送广播
Intent intent = new Intent("com.your.action.DOWNLOAD_COMPLETE");
LocalBroadcastManager.getInstance(context).sendBroadcast(intent);

// 应用模块注册接收器
MyBroadcastReceiver myReceiver = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter("com.your.action.DOWNLOAD_COMPLETE");
LocalBroadcastManager.getInstance(context).registerReceiver(myReceiver, filter);

// 记得在合适的时机注销接收器，比如Activity的onDestroy
@Override
protected void onDestroy() {
    super.onDestroy();
    LocalBroadcastManager.getInstance(this).unregisterReceiver(myReceiver);
}

局限性：仅适用于同进程的模块通信，如果是跨进程就没法用了。

3. 改用事件总线框架（比如EventBus） #

直接抛弃广播机制，用EventBus这类事件总线来做跨模块通信，解耦性更强，也不用处理广播的各种系统限制。

示例代码：

// 1. 定义事件类（可以放在公共模块，让两个模块都能引用）
public class DownloadCompleteEvent {
    // 可以携带下载相关的数据，比如文件路径、大小等
    private String filePath;

    public DownloadCompleteEvent(String filePath) {
        this.filePath = filePath;
    }

    public String getFilePath() {
        return filePath;
    }
}

// 2. 下载模块发送事件
EventBus.getDefault().post(new DownloadCompleteEvent("/sdcard/downloads/test.apk"));

// 3. 应用模块订阅事件
public class SettingsActivity extends AppCompatActivity {
    @Override
    protected void onStart() {
        super.onStart();
        EventBus.getDefault().register(this);
    }

    @Override
    protected void onStop() {
        super.onStop();
        EventBus.getDefault().unregister(this);
    }

    // 订阅下载完成事件，指定在主线程执行（因为要修改UI/设置）
    @Subscribe(threadMode = ThreadMode.MAIN)
    public void handleDownloadComplete(DownloadCompleteEvent event) {
        // 这里执行修改设置的逻辑
        updateSettings(event.getFilePath());
    }
}

优势：完全摆脱广播的限制，模块间不用依赖Intent Action或ComponentName，代码更简洁，还能直接传递复杂数据。

4. 用PendingIntent实现跨模块触发 #

如果下载任务可能在后台完成，需要保证应用模块的逻辑一定能被执行，可以让应用模块提前创建PendingIntent并传递给下载模块，下载完成后调用PendingIntent.send()来触发操作。

示例代码：

// 应用模块创建PendingIntent并传递给下载模块
Intent receiverIntent = new Intent(context, MyBroadcastReceiver.class);
PendingIntent pendingIntent = PendingIntent.getBroadcast(
        context,
        0,
        receiverIntent,
        PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE
);

// 把pendingIntent传给下载模块，比如通过下载任务的参数、接口回调等
DownloadManager.startDownload(url, pendingIntent);

// 下载模块完成后触发
try {
    pendingIntent.send();
} catch (PendingIntent.CanceledException e) {
    e.printStackTrace();
    // 处理PendingIntent失效的情况
}

优势：可以保证操作的可靠性，尤其是在后台场景下，即使应用被挂起也能触发（如果PendingIntent有效）。

你可以根据自己的实际场景选择最合适的方案：同进程选LocalBroadcastManager，跨进程且有明确约定选ComponentName，追求解耦和灵活性选EventBus，需要后台可靠性选PendingIntent。

内容的提问来源于stack exchange，提问作者Chol