我们需要一种方法让包开发者声明我们要捆绑的清单；可能在 pubspec.yaml 中的 flutter: 子条目是最好的选择？
这是一种很神奇的方法，但我们也可以有一些已知路径(在 lib/ 中？),如果有 PrivacyInfo.xcprivacy. ,工具会自动将其捆绑在一起。就像 AppFrameworkInfo.plist 如何用作 App.framework 和 Info.plist 一样：
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/app_shared/ios.tmpl/Flutter/AppFrameworkInfo.plist
flutter/packages/flutter_tools/lib/src/build_system/targets/ios.dart
第519行到第522行 in 140edb9
| | flutterProject.ios.appFrameworkInfoPlist |
| | .copySync(environment.outputDir |
| | .childDirectory('App.framework') |
| | .childFile('Info.plist').path); |

cc @dcharkes

要回答的一个问题是，除了Flutter之外，是否还有其他嵌入式开发人员需要包含这样的隐私清单。如果答案是肯定的，那么hook/build.dart应该将其作为元数据输出到NativeCodeAsset。这样，具有构建钩子的包也可以在其他嵌入式开发人员中使用。如果答案是否定的，我们可以构建一个针对Flutter的特定解决方案。
目前，我还没有发现除了Flutter之外的其他Dart嵌入式开发人员最终会在苹果应用商店中发布。你是否知道任何@mit-mit@mariamhas@mraleph?
重复的问题：

• Native assets should be able to specify a privacy manifest #140966

重复问题
这不是一个重复的问题；这个问题是关于有人编写了一个纯Dart包，直接调用所需的原因API进行FFI的情况。
然后 hook/build.dart 应该将其作为元数据输出到 NativeCodeAsset 。
在这个场景中没有 hook/build.dart ,也没有任何本地代码资产。
(调整标题以尝试使区别更清晰。)

啊，有趣！
所以这些将使用 DynamicLibrary.process.lookup 来访问系统 API。我理解得对吗？
我们可以考虑说用户应该使用 @Native ,并在报告 NativeCodeAsset 时附带 LookupInProcess ,从他们的 build.dart 中解决 #140966 的问题。然而，由于原生资产目前处于实验阶段，这对于目前使用 DynamicLibrary.process.lookup 而没有进行实验的用户来说并不能解决问题。

这些将使用 DynamicLibrary.process.lookup 来访问系统 API。我理解得对吗？
是的(可能通过 ffigen 或相关工具)。
我们可以考虑建议用户使用 @Native,并从他们的 build.dart 报告一个 NativeCodeAsset 和 LookupInProcess。
哦，我想 build.dart 实际上不需要构建任何东西，对吧？所以有人可能有一个原生资产包，其中唯一的原生资产就是隐私清单捆绑包，没有原生代码？
尽管对我来说还不清楚如何接线以获得正确的输出。在 #140966 中设想的情况中，我的理解是我们最终会得到一个包含该代码进行的 RRAPI 调用的隐私清单的 TheNativeCodeICompiled.framework,这样就可以了。然而，在本问题的场景中，RRAPI 调用(对于 Flutter 构建)位于 App.framework 中，因此相应的隐私清单必须位于 App.framework 中，以便 App Store 验证器接受它。但似乎 build.dart 没有方法可以实现这一点。
或者你是说我们应该建议没有人通过 FFI 调用，例如 stat,如果他们真的想调用 stat,他们应该写一个简单的 my_stat 并通过原生资产打包，然后调用它？如果是这样的话，强迫人们为他们的包添加一个几乎没有任何原因的原生构建步骤似乎并不可取。

这些将使用 DynamicLibrary.process.lookup 来访问系统 API。我理解得对吗？
是的(可能是通过 ffigen 或相关工具)。
我们可以考虑建议用户使用 @Native ,并从他们的 NativeCodeAsset 报告一个 LookupInProcess ,其中包含 build.dart 中的隐私清单包和没有本地代码？
是的。👍
尽管对我来说还不清楚如何连接以获得正确的输出。在 #140966 中设想的情况中，我的理解是我们最终会得到一个 TheNativeCodeICompiled.framework ,其中包含该代码进行的 RRAPI 调用的隐私清单，这将起作用。然而，在本问题中的场景下，RRAPI 调用(对于 Flutter 构建)位于 App.framework 中，因此相应的隐私清单 必须位于 App.framework 中，以便 App Store 验证器接受它。但似乎 build.dart 没有方法实现这一点。
嗯，flutter_tools 是 build.dart 输出的消费者。build.dart 只输出 .dylib 和元数据。Flutter Tools 可以决定它想做什么。Flutter tools 是负责将动态库转换为框架的那个。
如果 App.framework 是正确的地方，我们应该将所有单独的 NativeCodeAsset 的隐私清单从它们各自的框架中转移到 App.framework 上。
或者你是说我们应该建议没有人通过 FFI(例如 stat )调用，如果他们真的想调用 stat ,他们应该写一个简单的 my_stat 并通过本地资产打包进行打包，然后调用那个吗？如果是这样的话，强迫人们为他们的包添加一个基本不需要的本地构建步骤似乎并不可取。
不。我建议有一个 hook/build.dart :

void main() async {
  await build(config, output) {
    output.addAsset(
      NativeCodeAsset(
        package: 'my_package',
        name: 'stat.dart',
        linkMode: LookupInProcess(), // Will cause `@Native` to be `DynamicLibrary.process.lookup` at runtime.
        os: config.targetOS,
        architecture: config.targetArchitecture,
        // privacyManifest: ...,
      ),
    );
  });
}

然后包中的代码：

// package:my_package/stat.dart

// Generated by FFIgen with `ffi-native:`
@Native<Int Function(Pointer<Char>, Pointer<Stat>)>()
int stat(Pointer<Char> pathname, Pointer<Stat> statbuf);

这不会进行任何本地构建。它基本上只是从 hook/build.dart 返回的一些元数据到 Flutter。
或者你是说我们应该建议没有人通过 FFI(例如 stat )调用吗？
那么我确实建议没有人通过 stat 通过 DynamicLibrary.process.lookup 调用。(两者都是 FFI,我猜你在这里指的是带有 FFI 的 DynamicLibrary API。)
我同意使用 build.dart 与 LookupInProcess() 相比更像是一种仪式感。所以也许这不是正确的方法。另一方面，如果我们将用户转移到 @Native 而不是 DynamicLibrary 上，我们只需要引入一种解决方案而不是两种。

嗯，flutter_tools 是 build.dart 的消费者。build.dart 只输出 .dylib 和元数据。Flutter Tools 可以决定它想做什么。Flutter Tools 是负责将 dylib 转换为框架的那个工具。
啊，好的。我一直以为 build.dart 本质上是一个黑盒子，会输出框架。这样就说得通了。
另一方面，如果我们将用户转移到 @Native 而不是 DynamicLibrary ,我们只需要引入一个解决方案而不是两个。
只要我们不需要实际引入原生编译步骤，我就支持更少的解决方案 :)