问题描述
我在应用清单中设置了<intent-filter>，因此当用户导航到https://foo.bar/baz时，它们会自动发送到我应用中的相应活动。对于在“常规” Chrome浏览器中单击的链接，这100％的时间有效。
不过，我注意到的是，在相同设备上的那些相同链接，只要在其中一个链接上正常浏览，就可以
在这种情况下启用这些基于URI的意图过滤器是否存在已知问题，或者在清单中启用该方案需要进行哪些特殊操作？我已经四处搜寻，空了出来，所以希望有人在这里能帮到我。
解决方法
我的应用程序清单中有setup，因此当用户导航到https://foo.bar/baz时，它们会自动发送到我的应用程序中的相应活动。
我假设您的<system.webServer>
<defaultDocument>
<files>
<clear />
<add value="HomePage.aspx" />
</files>
</defaultDocument>
</system.webServer>
适用于<intent-filter>，可能同时适用于ACTION_VIEW和BROWSEABLE类别。
对于在“常规” Chrome浏览器中单击的链接，这100％的时间有效。
大概是Chrome浏览器正在查询LAUNCHER，发现该URL和PackageManager有注册的活动，然后开始该活动。
或者，一个应用可能只是为您的URL调用ACTION_VIEW startActivity()的{{1}}。那和ACTION_VIEW路由，几乎是您基于URL开始活动的唯一方式。
这两个都是选择加入的。无需碰巧在您的URL中运行的任何应用程序即可执行上述任一操作。
用户位于Chrome的“隐身”标签中
鉴于您的Intent在普通的Chrome浏览器中可以正常运行，我猜测隐身模式不会出于隐私原因使用它。隐身模式背后的意义是限制对浏览的了解，因此拒绝启动应用程序是其中的合理部分。
浏览器可能还有其他限制。例如，有一段时间，对于在地址栏中手动输入的URL，Chrome不会导航到外部应用。我已经多年没有尝试过了，所以我不知道这个限制是否仍然有效。
在Twitter的应用内浏览器中，用户正在跟踪链接（可能还有其他应用程序，尽管我尚未对其进行测试）。
许多使用PackageManager的应用程序具有将链接保持在该<intent-filter>内的逻辑，因此，当用户单击时，它不会启动Web浏览器。除非开发人员特别注意处理这种情况（类似于Chrome所做的事情），否则该逻辑还将阻止像您一样启动应用程序。
在这些情况下启用这些基于URI的意图过滤器是否存在已知问题
是的，只要开发人员有意或无意禁用了这种方式启动第三方应用程序。如果您要问的话，这不是您的错误。
还是清单中需要做的特殊操作才能启用这些方案？
您不能仅因为您的URL出现在他们的应用中就强迫开发人员启动您的应用。毕竟，开发人员无需仅因为您的URL出现在他们的应用中就启动Web浏览器。