检查app是否在运行时是ad-hoc | dev | app-store构建

Question

我想在调试屏幕中检查这个构建信息.有没有办法在运行时检查这个？

我意识到我可以为构建或类似设置编译器标志,但如果有一个我可以利用的现有方法,我想利用它.

Answer 1

虽然我同意Abhi Beckert认为运行时是错误的时间(使用预处理程序指令和构建设置!),我想澄清之前的答案/评论中的一些细节和推测,并对你的事情有所启发可以.忍受我,这将是一个更长的答案......

有许多数据可以归入"构建信息"的通用保护伞下.这些事情的非详尽列表包括:构建配置,代码签名标识,构建时间,构建日期,营销版本号,SCM修订号,SCM分支名称,供应配置文件团队标识,供应配置文件过期,CI构建号.这个清单一直在继续.

假设目前你的问题主要集中在获取有关用于构建的iOS证书和Provisioning Profile类型的信息,那么我将不得不采用非常坚定的"否"作为问题的答案:是否存在在运行时检查[使用现有API方法构建信息]的方法？ 简而言之:对于命令行构建设置爱好者,这两个数据点在Xcode 4.6.x构建设置或"CODE_SIGN_IDENTITY" 中称为" 代码签名标识 ".

截至提出此问题时,您可以调用任何单一的公共iOS API来获取有关当前正在运行的应用程序的代码签名类型的信息.这背后可能的原因很多,但这里有一些例子:

1. 允许开发人员构建自己的构建方案和构建配置.这意味着我们可以拥有一个方案和一个构建配置,或一个方案和几十个构建配置,甚至每个配置数千个.当然,可以为每个方案分配不同的构建配置,并且可以为每个配置分配不同的代码签名标识.正如您可能猜到的那样,开发人员或团队不需要太多定制就可以快速混乱.
2. 代码签名标识仅要求为当前应用程序标识符颁发的未过期的Provisioning Profile包含用于对二进制文件进行签名的证书的公钥副本.对于在团队中工作的人员,您可能拥有一个包含团队中开发人员所有证书的Provisioning Profile,或者您可以为团队中每个仅包含其证书的开发人员制作单独的Provisioning Profiles.这是开发人员如何选择构建应用程序的另一个变化点.
3. 开发人员可以共享一个证书(tsk tsk)或颁发自己的证书......是的,你猜对了,甚至更多的变化.

这个假设的一站式API需要在运行时访问所有构建配置数据,证书和配置文件,以便能够解除在编译时应用的"有效"设置,并将所有数据减少到有限的字符串......仅仅是为了开发人员的诊断视图......在任何想象中都不是一个不可能完成的壮举,但对于可忽略不计的开发人员利益而言,这种潜在的计算密集型操作肯定会在任何人的优先级列表中排名很低.鉴于其他选项(如编译时标志!)更可靠,设置更便宜,并且从长远来看更容易维护,它会在优先级列表中被踢得更远.

现在,至于半潜伏的问题"我可以在运行时做到吗？" 我会强调说"你可以."

如您所知,设备构建是唯一需要代码签名的构建类型.部分过程在主捆绑中创建一个名为"embedded.mobileprovision"的文件.这是您的应用程序的沙箱所拥有的文件,因此您绝对有能力以编程方式打开:

[[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]

.mobileprovision文件是PCKS#7编码的,包含二进制和文本数据.您寻求的信息是嵌入在PCKS#7数据中的基于文本的plist的信息.首先,使用OS X让我们看看你的一个设备版本中的这个文本数据:

1. 右键单击构建设备.app包并选择"显示包内容"
2. 将embedded.mobileprovision文件复制到易于访问的位置.
3. 使用首选文本编辑器打开该文件.

您立即注意到有很多二进制数据,但您可以找出部分文本数据.滚动到右侧,你会看到plist风格的xml,只是在这个视图中读起来不那么容易.我们可以使用OS X命令行工具以更有条理的方式查看此数据:

1. 打开终端并"cd"到包含您的embedded.mobileprovision副本的文件夹.
2. 运行:security cms -D -i embedded.mobileprovision

这将在终端窗口中显示plist xml,以便以精美的标签格式进行阅读.如果您为Ad-Hoc构建,Dev构建和App Store构建重复此过程,您将开始注意到此文本中的键表示相应类型的构建.对于使用'iPhone Developer:...'证书(或原始帖子中列出的'Dev'构建)签名的版本,请查找:

<key>get-task-allow</key>
<true/>

如果应用程序允许调试器附加到它,则"get-task-allow"键用于指示iOS.对于"iPhone Developer"签名二进制文件,这是有道理的 - 当将代码从Xcode推送到您的设备进行测试时,您通常需要能够在设备上进行调试.

"Ad-Hoc"和"App Store"之间的区别需要一些额外的检查.对于这两种分发,同样的'get-task-allow'键将设置为false:

<key>get-task-allow</key>
<false/>

但是,'Ad-Hoc'版本在'App Store'版本中有一组定义的'ProvisionedDevices':

<key>ProvisionedDevices</key>
<array>
    <string>abcdef01234567890abcdef01234567890abacde</string>
    <string>1abcdef01234567890abcdef01234567890abacd</string>
    <string>2abcdef01234567890abcdef01234567890abacd</string>
</array>

那么这对运行时检查问题的实际意义是什么呢？是的,你可以通过从主捆绑中打开embedded.mobileprovision文件,并从中解析数据来做出明智的决定,但这是你自己完全负责的事情.您需要添加逻辑来处理丢失该文件的情况(例如模拟器构建)并解析PCKS#7数据或者可靠地提取文件的ASCII内容,您的代码可以在其上运行一系列字符串搜索.很明显,这将需要通过一些脆弱的解决方案进行非常轻松的努力,否则可以通过构建设置和预处理器宏轻松适应,如前一个答案中所述的Abhi Beckert所述.

App Store拒绝的风险如何？这是"非法的"还是"颠覆性的"？

假设您在阅读和解析embedded.mobileprovision文件的内容时使用了所有公共API,这是App Store的当前条款完全允许的.应用程序沙箱中的任何内容都是公平的游戏,包括embedded.mobileprovision,如果碰巧存在的话.我仍然强烈警告不要走这条路,这与Abhi Beckert的评论相呼应.对于不到1%的用例而言,这是一项相当大的努力,并且有更容易的解决方案!此外,开发人员诊断视图不应该在App Store发布版本中,但是包含无关代码的决定完全在您手中.

我希望这能解决任何挥之不去的问题,但如果没有,请发表评论,我们可以看到我们能做些什么.

Answer 2

这可能就是你要找的东西.Abhi有一个很好的,彻底的解释,这个要点有实际的代码:

https://github.com/blindsightcorp/BSMobileProvision