检查app是否在运行时是ad-hoc | dev | app-store构建 [英] Check if app is ad-hoc|dev|app-store build at run time

问题描述

我想在调试屏幕中查看此内容以获取构建信息。有没有办法在运行时检查这个？

I'd like to check this for build information in a debugging screen. Is there a way to check this at runtime?

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

I realize that I could set compiler flags for the builds or similar, but if there is an existing method that I could leverage I'd like to take advantage of that.

推荐答案

虽然我同意Abhi Beckert认为运行时是错误的时间（使用预处理器指令和构建设置！ ），我想澄清之前的答案/评论中的一些细节和推测，并对你可以做的事情有所启发。请耐心等待，这将是一个更长的答案...

While I would agree with Abhi Beckert that runtime is the wrong time to be doing this (use preprocessor directives and build settings!), I wanted to clarify some of the details and speculations in the previous answer/comments and shine some light on things you could do. Bear with me, this is going to be a longer answer...

有许多数据可以归入构建信息的通用范围内。这些事情的非详尽列表包括：构建配置，代码签名身份，构建时间，构建日期，营销版本号，SCM修订号，SCM分支名称，供应配置文件团队标识，供应配置文件过期，CI构建号。这个列表一直在继续。

There are a bunch of pieces of data that could go under the generic umbrella of 'Build Information'. A non-exhaustive list of such things would include: Build Configuration, Code Signing Identity, Build Time, Build Date, Marketing Version Number, SCM Revision Number, SCM Branch Name, Provisioning Profile Team Identity, Provisioning Profile Expiration, CI Build Number...the list goes on and on.

假设目前您的问题主要集中在获取有关用于构建的iOS证书和Provisioning Profile类型的信息，那么我将不得不用一个非常坚定的'否'作为问题的答案：有没有办法在运行时检查[使用现有的API方法构建信息]？暂时不说：这两个数据点统称为代码签名身份 Xcode 4.6.x构建设置或CODE_SIGN_IDENTITY为您的命令行构建设置爱好者。

Assuming for the moment your question was narrowly focused on gaining information as to the type of iOS certificate and Provisioning Profile used for the build, then I will have to go with a very firm 'No' as the answer to the question: Is there a way to check [build information using an existing API method] at runtime? As a brief aside: Collectively these two data points are called the "Code Signing Identity" in Xcode 4.6.x Build Settings or "CODE_SIGN_IDENTITY" for you command-line build setting enthusiasts.

截至此问题时间有人问道，没有单一的公共iOS API，您可以调用它来获取有关当前正在运行的应用程序的代码签名类型的信息。这背后可能的原因很多，但这里有几个例子：

As of the time this question was asked, there is no singular public iOS API that you can call to get information about the code signature type for the currently running app. The likely reasons behind this are numerous, but here are a few examples:

1. 允许开发人员构建自己的构建方案和构建配置。这意味着我们可以拥有一个方案和一个构建配置，或者一个方案和几十个构建配置，甚至每个配置数千个。当然，可以为每个方案分配不同的构建配置，并且可以为每个配置分配不同的代码签名标识。正如您可能猜到的那样，开发人员或团队不需要太多定制就可以快速混乱。


2. 代码签名身份只需要为此发布未过期的Provisioning Profile当前应用程序标识符，包含用于对二进制文件进行签名的证书的公钥副本。对于在团队中工作的人员，您可能只有一个包含团队中开发人员所有证书的Provisioning Profile，或者您可以为团队中每个仅包含其证书的开发人员制作单独的Provisioning Profiles。这是开发人员如何选择构建应用程序的另一个变化点。


3. 开发人员可以共享一个证书（tsk tsk）或颁发自己的证书......是的，你猜测它，甚至更多变化。

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

This hypothetical one-stop API would then need to have access at runtime to all of your build configuration data, certificates, and provisioning profiles to be able to untwist the 'effective' settings applied at compile time and reduce all of that data down to a finite string...simply for a developer diagnostics view...not an impossible feat by any stretch of the imagination, but such a potentially computationally intense operation for negligible developer benefit would definitely rank low on just about anybody's priority list. It would get kicked even further down the priority list given that other options (like compile-time flags!) are more reliable, cheaper to setup, and simpler to maintain in the long run.

现在，至于半潜伏的问题我能在运行时做到吗？我会强调说'是的你可以'。

Now, as to the semi-lurking question of "Could I do it at runtime?" I would emphatically say 'Yes you can.'

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

As you know, device builds are the only kinds of builds that require code signing. Part of the process creates a file in the main bundle called 'embedded.mobileprovision'. This is a file owned by your app's sandbox and thus is something you absolutely have the ability to open programmatically:

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

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

.mobileprovision files are PCKS#7 encoded and contain both binary and text data. The info you seek is that of the text-based plist embedded within the PCKS#7 data. First, using OS X let's take a look at this text data out of one of your device builds:

1. 右键单击你的构建版本的设备.app包并选择显示包内容


2. 将embedded.mobileprovision文件复制到一个易于访问的位置。


3. 使用首选文本编辑器打开该文件。

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

You notice right away that there's a lot of binary data but you can make out parts of the text data. Scrolling to the right, you'll see plist-styled xml, only it isn't so easy to read in this view. We can use an OS X command line tool to look at this data in a more organized manner:

1. 打开终端并'cd'到包含您的embedded.mobileprovision副本的文件夹。


2. 运行：security cms -D -i embedded.mobileprovision

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

This will display the plist xml to the terminal window for your perusal in a nicely tabbed format. If you repeat this process for an Ad-Hoc build, Dev build, and an App Store build you'll start to notice the keys in this text that are indicative of the respective types of builds. For builds signed with an 'iPhone Developer: ...' certificate (or 'Dev' builds as you listed in the original post), look for:

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

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

The 'get-task-allow' key is what is used to instruct iOS if the app will allow a debugger to attach to it. In the case of an 'iPhone Developer' signed binary this makes sense - You would typically need to be able to debug on the device when pushing code from Xcode to your device for testing purposes.

'Ad-Hoc'和'App Store'之间的区别需要一些额外的检查。对于这两种发行版，同样的get-task-allow键将设置为false：

The difference between 'Ad-Hoc' and 'App Store' require some additional checks. This same 'get-task-allow' key will be set to false for both of these kinds of distributions:

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

但是，'Ad-Hoc'构建在'App中有一组'ProvisionedDevices'。商店'版本：

However, 'Ad-Hoc' builds have a defined set of 'ProvisionedDevices'not present in 'App Store' builds:

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

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

So what does this mean in practical terms for the runtime checking question? Yes you can do it, by opening up the embedded.mobileprovision file out of the main bundle, and parsing data out of it to make an informed decision, but that is something you'd be entirely responsible for implementing yourself. You'll need to add logic to handle cases where that file is missing (ex. Simulator builds) and to either parse the PCKS#7 data or reliably extract the ASCII content of the file upon which your code can run a series of string searches. As is likely evident, this will require non-trivial effort for a somewhat brittle solution that can otherwise be easily accommodated by build settings and pre-processor macros at as Abhi Beckert outlined in the previous answer.

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

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

Presuming that you use all public API when reading and parsing the contents of the embedded.mobileprovision file, this is perfectly allowable by the current terms of the App Store. Anything in your app's sandbox is fair game including embedded.mobileprovision if it happens to be present. I still strongly caution against going down this road, echoing Abhi Beckert's comments. It is a considerable amount of effort for less than 1% of use cases and there are far easier solutions out there! Furthermore, developer diagnostic views shouldn't be in App Store release builds, however the decision to include extraneous code is entirely in your hands.

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

I hope this clears up any lingering questions, but if not, please toss in a comment and we can see what we can do.

这篇关于检查app是否在运行时是ad-hoc | dev | app-store构建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！