Неверный двоичный файл приложения iPhone
https://stackoverflow.com/questions/47941
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я пытаюсь загрузить приложение в iPhone App Store, но получаю следующее сообщение об ошибке от iTunes Connect:
Бинарный код загруженного файла не корректен.Подпись недействительна или не подписана сертификатом отправки Apple.
Примечание:Подробности исходного вопроса были удалены, поскольку эта страница превратилась в хранилище всей информации о возможных причинах этого конкретного сообщения об ошибке.
Общую информацию об отправке приложений iPhone в App Store см. Шаги по загрузке приложения для iPhone в AppStore.
Решение
По моему опыту, Xcode иногда не понимает, какой сертификат подписи использовать.У меня появилась привычка выходить и перезапускать Xcode после любого изменения настроек подписи кода (и выполнять чистую сборку), чтобы обойти эту проблему.
Другие советы
Я просто хотел упомянуть, что у меня тоже была проблема с Zip из командной строки.Проблема заключается в том, как по умолчанию обрабатываются символические ссылки.С использованием:
zip -y -r myapp.zip myapp.app
Решил эту проблему.
У меня была такая же проблема, и я решил ее следующим образом:
Сертификаты собственности были установлены на моей машине разработки, а файл mobileprovision.embedded был включен в архив дистрибутива.Примерно через час поиска в Google и копания я нашел источник ошибки.Внутри Xcode я скопировал конфигурацию выпуска и создал новую конфигурацию распространения, а затем изменил удостоверение подписи на свой сертификат распространения.Однако, несмотря на то, что он был обновлен в графическом интерфейсе, файл проекта не был обновлен правильно.
Если вы столкнулись с той же ошибкой, найдите в каталоге [ProjectName].xcodeproj файл project.pbxproj и откройте его в своем любимом редакторе.Найдите раздел «Распространение».Мой сломанный выглядел так:
C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Developer: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Developer: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};
Во втором разделе вы можете видеть, что подписывающее удостоверение и профиль обеспечения неверны.Отредактируйте его, чтобы он соответствовал первому разделу, перестройте, и все готово.Финальный вариант выглядел так:
C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Distribution: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “F00D3778-32B2-4550-9FCE-1A4090344400″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};
гиды изменились, чтобы защитить невиновных
Та же проблема, другое решение.
В моем случае я сжимал файл, используя zip -r myapp.zip myapp.appОказывается, команда zip испортила пакет.Сжатие его из искателя заставило его работать.
У меня была та же проблема, и после нескольких попыток - я удалил права .plist из прав на подпись кода (просто оставил его пустым), и все было нормально построено и НАКОНЕЦ загружено.
Всем удачи :-D
Еще одна точка данных:какое-то время мое приложение прошло.Теперь я добавил поддержку покупок в приложении, и внезапно возникла проблема «Неверный двоичный файл/неверная подпись».Внимательно просмотрев, я обнаружил, что значение идентификатора приложения в файле plist с правами отключено.
Скорее всего, это было связано с тем, что я заменил профиль обеспечения с подстановочного на профиль, специфичный для приложения (требуется для покупок в приложении).Неправильный идентификатор приложения, соответствующий старому профилю.Он не соответствовал идентификатору приложения в info.plist, но, видимо, iTunes это простил.
Итак, подведем итоги:
info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*
все в порядке, в то время как
info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo
вызывает «Неверный двоичный файл».
У меня была та же проблема: при сборке я заметил, что в сборку не была добавлена подготовка.
Решением для меня было установить сборку на устройство iphone так, как я обычно использую симулятор, но тогда она не будет включать профиль обеспечения...
Возможно, это ошибка нуба.Обычно вы не можете выполнить сборку на устройстве, но когда вы делаете это для распространения, вы можете.
Что ж, повторив эти шаги несколько раз, мне наконец удалось загрузить свое приложение.
Я не знаю точно, что это исправило, но перед успешной попыткой я закрыл Xcode и Firefox и перезапустил их.Думаю, в одном из этих приложений было что-то плохое.
Вот проблема, с которой я столкнулся:Я добавил двоичный файл в Subversion перед загрузкой.Затем при сравнении/архивировании двоичного файла были включены скрытые каталоги .svn, что испортило подпись кода.
Я пробовал разные вещи после прочтения разных постов, включая приведенные выше.Что в конечном итоге сработало для меня, так это то, что я начал все сначала!Я удалил все сертификаты и профили обеспечения, связанные с моим приложением.
Я воссоздал новый сертификат разработки и новый сертификат распространения.Я снова скачал промежуточный сертификат.Затем я воссоздал профиль разработки и профиль распространения.
После установки трех сертификатов (на этот раз я заметил, что в дистрибутиве есть как закрытый, так и открытый ключи) и двух профилей обеспечения (мой профиль дистрибутива не был помечен как не имеющий действующего сертификата!), все заработало.
Как только я принял решение отозвать все и начать заново, создание нового материала и его переустановка заняли всего около 5 минут.
См. эту ссылку для решения:
http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect
Короткий ответ: «В конце концов я дважды проверил свой info.plist и кое-что обнаружил.Я добавил CFBundleIconFiles в соответствии с новыми рекомендациями, но в списке массивов была пустая запись.Я удалил это и отправил повторно, и оно наконец было принято!»
У меня была аналогичная проблема, но в Monotouch.Я обнаружил, что в моем профиле выпуска настроено использование сертификатов разработчика.Это должно выглядеть так:
Кажется, у этой проблемы много причин.Вот мое решение:
Это относится ко всем, кто принадлежит к нескольким командам разработчиков (например,ваши собственные приложения и ваши компании).
Если вы создаете сборку с одним набором учетных данных и повторно подписываете ее с другим (например,для специального распространения/распространения в AppStore), вы должны убедитесь, что сборка изначально была создана и подписана учетными данными, принадлежащими той же команде разработчиков iOS, которой принадлежат учетные данные распространения, с которыми вы повторно подписываете.
Поэтому не выполняйте сборку с учетными данными «Indy Dev Inc», а затем пытайтесь выполнить развертывание с учетными данными «Company Inc».Убедитесь, что вы настроили как разработчика «Company Inc», так и учетные данные распространения, и используете их.
Более подробную информацию об этом я разместил в своем блоге: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/
У меня такая же проблема.Я был готов сдаться в этой проблеме, но понял это, когда пошел проверять свой код с помощью Murky.Я всегда просматриваю различия в файлах, которые были изменены, прежде чем проверить их.Делая это в этот раз, я заметил, что файл project.pbxproj изменился… и в разделе «Распространение» запись «PROVISIONING_PROFILE[sdk=iphoneos*]» была пустой.
Выход и перезапуск Xcode мне не помогли.Вместо этого я вошел в настройки проекта и цели и изменил подпись кода, чтобы напрямую выбирать профиль распространения, а не полагаться на функцию автоматического выбора.Это привело к тому, что файл project.pbxproj был заполнен правильными значениями, хотя функция автоматического выбора предположительно выбрала тот же самый профиль, который я выбрал вручную.
Мне нужно пиво...
Попробовав все остальные исправления, перечисленные здесь, мы зарегистрировали TSI в Apple.Выполнив все шаги, указанные в Техническое примечание TN2250 наша проблема возникла из-за того, что запечатанный ресурс отсутствовал или был недействителен.В нашем случае это было ._.DS_Store.
".. называется файлом Apple Double и является результатом копирования *разархивированной* папки проекта Xcode* в файловую систему и обратно из файловой системы, которая не поддерживает должным образом «вилки ресурсов» HFS+ (используемые для подписей кода).Эти дополнительные»... и приводит к сбою проверки подписи кода.
Чтобы удалить проблемные файлы Apple Double из папки проекта Xcode, запустите команду dot_clean в папке проекта Xcode, выполните чистую сборку, а затем повторно заархивируйте и повторите попытку отправки.
dot_clean /the/path/to/xcode/project
Примечание:Вы можете просто перетащить папку проекта в терминал, чтобы автоматически заполнить путь.
При запуске команды сообщение не появляется, но при следующей сборке проекта может появиться предупреждение о файле.Вы можете игнорировать это, приложение успешно проверит и отправит данные.
Проблема решена путем очистки файла myProject.xcodeproj (щелкните правой кнопкой мыши, откройте пакет), пакет содержал файлы от соразработчика, после их удаления проблема была решена.
Для меня решением было создание сертификата распространения по адресу:Портал обеспечения разработчиков Apple.
Чего бы это ни стоило, я хочу добавить, что именно помогло мне решить эту проблему.У меня был ?(знак вопроса) в названии моего приложения, которое вызвало ошибку.
Я получил недопустимый двоичный файл, если приложение не использует удаленное push-уведомление, но я оставил код для регистрации push-уведомлений и делегатов обратного вызова для регистрации/получения удаленного уведомления без комментариев, даже если код не используется.
Это недавнее событие.Моя последняя подача на прошлой неделе была в порядке.На этой неделе он возвращает неверный двоичный файл.К счастью, есть электронное письмо с объяснением ошибки.
У меня была аналогичная проблема, но я не использую entitlements.plist.Однако после дюжины неудачных загрузок я проверил свой info.plist и кое-что обнаружил.В моем массиве CFBundleIconFiles была пустая запись.Я удалил это и отправил повторно, и оно наконец было принято!
Серьезно, насколько сложно Apple будет выявить подобные ошибки проверки?
Редактировать:Не сразу понятно, где находятся CFBundleIconFiles, потому что они используют другое имя.В представлении информации о проекте нажмите Ctl и выберите «Показать необработанные ключи/значения», после чего вы увидите ссылки на CFBundleWhatever.В случае с этим редактором он пытался использовать несуществующий файл icon=72-@2x.png.
Мои два цента:
Загрузите последнюю версию загрузчика приложений.Я только что обновился и теперь получаю другое сообщение об ошибке.
Я только что столкнулся с этой проблемой (снова), но на этот раз обнаружил, что мой профиль распространения имеет статус «Недействительный».Если вы считаете, что все остальное в порядке, дважды проверьте статус на портале и обновите/перезагрузите все, что не находится в активном состоянии.
Я получил неверный двоичный файл после загрузки приложения, но по электронной почте не было объяснено, почему это не удалось.Я попробовал сделать несколько вещей одновременно, и я не уверен, что из следующего действительно помогло:
- Перезапустил Макбук Про
- Переместил исходный код моего проекта с диска NTFS на диск HFS+ и перекомпилировал.
У меня была проблема с этим и с GM SDK 4.3.Одно из наших приложений не смогло пройти загрузку.Оказалось, что это проблема с профилем обеспечения.Я восстановил профиль магазина приложений, и все заработало нормально.
Мое решение заключалось в создании нового идентификатора приложения.Я не уверен точно, почему это исправило, но я подозреваю, что это могло быть несовпадение идентификаторов пакета — создание нового идентификатора приложения заставило меня убедиться, что мое приложение и iTunes ожидают одного и того же.
Другое решение:
Для меня простая установка сертификатов «Выпуск» в разделе «подпись кода» исправила это.Изначально для них было установлено значение «Не кодировать».
Для меня проблема была решена путем повторного сохранения изображения PNG с параметром без чересстрочной развертки.В предыдущих версиях были разрешены чересстрочные PNG, но знайте, что эти изображения могут привести к недопустимому двоичному файлу.
Мое яблочное сообщение:Поврежденный файл значка. Файл значка iconGQ@2x.png кажется поврежденным.Ваш значок не должен представлять собой чересстрочный файл PNG.
Вы можете увидеть, является ли PNG чересстрочным, используя команду «файл» в терминале:Eva-madrazos-macbook-pro-2: gq 7 Integracion ads eva $ file *.png default.png:Данные изображения PNG, 320 x 480, 8 бит/цвет RGB, без чересстрочной развертки
Удачи, Ева
Я хочу указать на возможность написать Apple по электронной почте и попросить их проверить свои журналы.Я так и сделал, предварительно перепробовав множество вещей.Пришлось им напомнить спустя почти четыре недели, но в конце концов они ответили и указали точное место проблемы.
Проблема в моем случае заключалась в том, что ранее я пробовал другие значки приложений, а ссылка на старое изображение все еще оставалась в «CFBundleIcons».Я использовал функцию перетаскивания, чтобы установить значок, но не заметил, что старое содержимое не было полностью очищено до добавления новой ссылки.
Чтобы увидеть ошибочную ссылку, необходимо было развернуть стрелки, чтобы просмотреть каждый подэлемент в файле plist.Один из советов — щелкнуть файл правой кнопкой мыши и выбрать опцию просмотра необработанного содержимого.Таким образом, вам не нужно будет ничего расширять.
Я попробовал все остальные предложенные решения, но ничего не помогло.
В итоге я создал новый проект Xcode и скопируйте в него весь мой код и ресурсы.Это помогло, и мое приложение было помещено в очередь на проверку.
Я также могу порекомендовать Технические примечания Apple по подписанию кода для отладки/проверки.
uuid не разрешен.Я исправил это, удалив все [[UIDevice currentDevice] uniqueIdentifier];
