Проверьте, является ли приложение ad-hoc|dev|app-store build во время выполнения

Я хотел бы проверить это для получения информации о сборке на экране отладки. Есть ли способ проверить это во время выполнения?

Я понимаю, что мог бы установить флаги компилятора для сборок или аналогичных, но если есть существующий метод, который я мог бы использовать, я бы хотел воспользоваться этим.

Источник

3 ответа

Решение

Хотя я бы согласился с Абхи Беккертом, что время выполнения - неподходящее время для этого (используйте директивы препроцессора и настройки сборки!), Я хотел уточнить некоторые детали и предположения в предыдущем ответе / комментариях и пролить свет на то, что вы мог сделать. Потерпи меня, это будет более длинный ответ...

Существует множество фрагментов данных, которые могут быть включены в общий термин "Информация о сборке". Неполный список таких вещей может включать в себя: Конфигурация сборки, Идентификатор подписи кода, Время сборки, Дата сборки, Номер маркетинговой версии, Номер редакции SCM, Имя ветви SCM, Идентификатор команды профиля обеспечения, Истечение срока профиля обеспечения, Номер сборки CI..У этого списка нет конца.

Если предположить, что на данный момент ваш вопрос был сфокусирован на получении информации о типе сертификата iOS и профиля обеспечения, используемого для сборки, то мне придется ответить очень твердым "Нет" в качестве ответа на вопрос: способ проверить [построить информацию с использованием существующего метода API] во время выполнения? Вкратце: эти две точки данных в совокупности называются " Идентификацией подписи кода " в Xcode 4.6.x "Параметры сборки" или "CODE_SIGN_IDENTITY" для энтузиастов настройки сборки из командной строки.

На момент, когда был задан этот вопрос, не существует единственного общедоступного API iOS, к которому можно обратиться, чтобы получить информацию о типе подписи кода для запущенного в данный момент приложения. Вероятные причины этого многочисленны, но вот несколько примеров:

  1. Разработчикам разрешено создавать свои собственные схемы сборки и конфигурации сборки. Это означает, что у нас может быть одна схема и одна конфигурация сборки, или одна схема и десятки конфигураций сборки, или даже тысячи каждой. Естественно, каждой схеме может быть назначена своя конфигурация сборки, и каждой из этих конфигураций может быть назначен отдельный идентификатор подписи кода. Как вы можете догадаться, разработчик или команда разработчиков не требуют особых настроек, чтобы быстро стать хаотичным.
  2. Идентификационные данные подписи кода требуют, чтобы профиль обеспечения с истекшим сроком действия, выданный для текущего идентификатора приложения, содержал копию открытого ключа для сертификата, используемого для подписи двоичного файла. Для тех, кто работает в команде, у вас может быть один профиль обеспечения, содержащий все сертификаты разработчиков в группе, или вы можете создать отдельные профили обеспечения для каждого разработчика в группе, содержащие только их сертификаты. Это еще одна точка различий в том, как разработчики могут выбрать создание своего приложения.
  3. Разработчики могут поделиться одним сертификатом (tsk tsk) или получить свои собственные сертификаты... да, вы уже догадались, еще больше вариантов.

Затем этот гипотетический универсальный API должен иметь доступ ко всем вашим данным конфигурации сборки, сертификатам и профилям обеспечения, чтобы иметь возможность раскручивать "эффективные" параметры, примененные во время компиляции, и сокращать все эти данные до конечная строка... просто для диагностической точки зрения разработчика... не является невозможным подвигом для любого воображения, но такая потенциально вычислительно сложная операция для незначительной выгоды разработчика, безусловно, заняла бы место почти в списке приоритетов любого человека. Это могло бы выкинуть еще дальше вниз по списку приоритетов, учитывая, что другие параметры (например, флаги времени компиляции!) Более надежны, дешевле в настройке и проще в обслуживании в долгосрочной перспективе.

Теперь, что касается полулежащего вопроса "Могу ли я сделать это во время выполнения?" Я бы решительно сказал: "Да, вы можете".

Как вы знаете, сборки устройств - это единственные виды сборок, которые требуют подписи кода. Часть процесса создает файл в главном пакете, называемый "embedded.mobileprovision". Это файл, принадлежащий песочнице вашего приложения, и поэтому вы абсолютно точно можете программно открыть его:

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

Файлы.mobileprovision имеют кодировку PCKS#7 и содержат как двоичные, так и текстовые данные. Информация, которую вы ищете, - это информация о текстовом листе, встроенном в данные PCKS#7. Во-первых, используя OS X, давайте взглянем на эти текстовые данные из одной из ваших сборок устройства:

  1. Щелкните правой кнопкой мыши по вашей сборке для комплекта устройств.app и выберите "Показать содержимое пакета".
  2. Скопируйте внедренный файл.mobileprovision куда-нибудь легко доступный.
  3. Откройте этот файл в предпочитаемом вами текстовом редакторе.

Вы сразу замечаете, что есть много двоичных данных, но вы можете разобрать части текстовых данных. Прокрутив вправо, вы увидите xml в стиле plist, но в этом представлении его не так просто прочитать. Мы можем использовать инструмент командной строки OS X, чтобы посмотреть на эти данные более организованно:

  1. Откройте "Терминал" и "cd" в папку, содержащую вашу копию внедренного.
  2. Выполнить: безопасность 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 есть определенный набор ProvisionedDevices, отсутствующий в сборках App Store:

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

Так что же это означает на практике для вопроса проверки во время выполнения? Да, вы можете сделать это, открыв файл embedded.mobileprovision из основного пакета и проанализировав из него данные, чтобы принять обоснованное решение, но за это вы сами несете полную ответственность за реализацию. Вам нужно будет добавить логику для обработки случаев, когда этот файл отсутствует (например, сборки симулятора) и либо для анализа данных PCKS#7, либо для надежного извлечения содержимого ASCII файла, по которому ваш код может выполнить серию поиска строк, Как очевидно, это потребует нетривиальных усилий для несколько хрупкого решения, которое в противном случае может быть легко приспособлено настройками сборки и макросами препроцессора, как Абхи Беккерт обрисовал в общих чертах в предыдущем ответе.

Как насчет риска отклонения App Store? Это "незаконно" или "подрывно"?

Предполагая, что вы используете все общедоступные API при чтении и разборе содержимого файла embedded.mobileprovision, это вполне допустимо в соответствии с текущими условиями App Store. Все в песочнице вашего приложения является честной игрой, включая embedded.mobileprovision, если оно есть. Я по-прежнему настоятельно рекомендую не идти по этому пути, повторяя комментарии Абхи Беккерта. Это значительное усилие для менее чем 1% случаев использования, и есть гораздо более простые решения! Кроме того, диагностические представления разработчиков не должны присутствовать в сборках релизов App Store, однако решение о включении постороннего кода полностью в ваших руках.

Я надеюсь, что это прояснит любые давние вопросы, но если нет, пожалуйста, оставьте комментарий, и мы увидим, что мы можем сделать.

Источник

Это, вероятно, то, что вы ищете. У Абхи есть хорошее, подробное объяснение, и у этой сути есть настоящий код:

https://github.com/blindsightcorp/BSMobileProvision

Источник

Время выполнения - неподходящее время для этого.

Ваше приложение может быть отклонено из магазина, если вы попытаетесь это сделать. Или это может быть одобрено, и тогда вы делаете срочную версию исправления ошибки, которая может быть отклонена.

Как @rmaddy предложил в комментарии, вы должны сделать это во время компиляции.

Отредактируйте настройки вашего проекта, чтобы определить эту константу: CONFIGURATION_$(CONFIGURATION)затем сделайте это в своем коде:

#if defined (CONFIGURATION_Debug) || defined (CONFIGURATION_Adhoc)
  NSLog( @"Warning message");
#endif

Источник / более подробная информация: http://ios-dev.gravitini.com/2009/02/identifying-current-xcode-configuration.html

Вы можете обернуть вокруг него функцию времени выполнения, если хотите. Может быть:

void debugLog(NSString *str)
{
    #if defined (CONFIGURATION_Debug)
      NSLog(@"%@", str);
    #endif
}
Источник
Другие вопросы по тегам