Background

This reverts commit f92f668.

solves #2901

This issue is a regression introduced by #2879, which added support for multiple dependencies for app_intents.

The approach was as follows:

1. Parse each dependency module
2. Merge the generated metadata into a single dummy module's metadata using the --static-metadata-file-list option of appintentmetadataprocessor, which is intended to propagate dependency metadata (definition of AppIntents) to dependents
3. Bundle the result of step 2 into the app

However, it turns out that --static-metadata-file-list does not propagate AppShortcutsProvider to dependent modules. In other words, the processor only recognizes providers defined in the last (root) module it processes.

Since the root module in this approach is a dummy module, providers defined in modules passed to app_intents are dropped during step 2.

Approach

Let me revert it now and start over thinking about proper approach.

Now I’m thinking it would be better to keep the single-module restriction for the app_intents argument. Since the processor essentially expects a single root module for defining AppShortcutsProvider, it makes sense for app_intents to specify that root module.

Instead, it would be more appropriate to support recursively parsing the metadata of dependency modules from the module passed to app_intents, which would effectively allow handling multiple modules. I might try to work on it when I have a time

any other idea, suggestion are welcomed

BTW, I'm going to open an another PR for adding test cases regarding AppShortcutsProvider, it helps us avoiding such regression in the future.

I'm sorry for causing this problem and thanks for reviewers, contributors support 🙇