web-dev-qa-db-ja.com

アーカイブまたはiTunesConnectdSYMファイルにないdSYMを要求しているファブリック

Crashlyticsがインストールされたアプリがあります。そのためのdSYMファイルを取得するには、常にウィンドウ/オーガナイザーに移動し、右クリックしてFinderに表示し、[パッケージの内容を表示]を右クリックして、dSYMディレクトリに移動して取得します。

この例では、Crashlyticsは、数字と文字のランダムな文字列（65cbd90a2b443d36ab7a6a419b797a71）であるdSYMファイルが欠落していると言っています。上記の方法論を使用してそれを探しに行くと、CocoaPodsを介して組み込んだいくつかのフレームワークのMyApp.app.dSYMという名前のファイルとdSYMファイルしか表示されません。そのファイルをドラッグアンドドロップしてみましたが、Fabricはランダムな文字列を要求します。

MyApp.app.dSYMのパッケージの内容を表示しようとしましたが、「Contents」フォルダーと「Resources」フォルダー（DWARFサブディレクトリと拡張子のない「MyApp」というファイル）以外は何も表示されません。 。

この投稿を確認したところ、99％確信しています アーカイブを作成して再送信する 。

概説したように、iTunesConnectから直接dSYMをダウンロードしてみました この投稿で 。

そのdSYMを「そのまま」アップロードして圧縮（dSYM.Zip）しようとしましたが、Fabricは、ローカルアーカイブにもiTunesConnectのdSYMにも存在しないように見えるランダムな文字列を必要としています。

Crashlyticsが求めているdSYMファイルを取得する可能性のある追加の方法に関する提案は大歓迎です。

iosobjective-cswiftcrashlyticstwitter-fabric
16
Adrian

ITunes ConnectからDSYMパッケージをダウンロードすると、もうすぐそこにいます。ダウンロード後、.Zip拡張子を追加し、ダブルクリックして解凍します。

生成されたDSYMのフォルダーには、65cbd90a2b443d36ab7a6a419b797a71というタイトルのフォルダーがあります（Crashlyticsが要求しているフォルダー）。そこにない場合は、CrashlyticsとiTunesConnectで同じビルドを見ていることを再確認してください。

そのファイルだけをCrashlyticsにアップロードします。

問題が解決しました。 ????

12
Jordan Smith

ビットコードに対応していないアプリの場合、Crashlyticsは自動的にdSYMsをアップロードします。アプリでBitcodeを有効にしている場合は、dSYMを手動でアップロードする必要があります。

ビットコード対応のアプリケーションは、クラッシュを象徴するために、XcodeからdSYMをダウンロードし、それをCrashlyticsにアップロードする必要があります。ビットコード対応アプリのDSYMは、Xcodeのオーガナイザーからダウンロードできます。アプリの特定のアーカイブを選択し、[dSYMのダウンロード]ボタンを押すと、ビットコードでコンパイルされたdSYMが元のアーカイブに挿入されます。

enter image description here

DSYMを手動でアップロードする

DSYMが取得されていない場合は、 アプリ設定ページ に移動してアプリを選択し、[不足しているDSYM]タブをクリックしてdSYMをアップロードすることで手動で追加できます。

enter image description here

DSYMの場所を見つけるには、開いているターミナルで次のコマンドを実行します。

mdfind "com_Apple_xcode_dsym_uuids == <UUID>"

すべてのdSYMを見つけるには、

mdfind "com_Apple_xcode_dsym_uuids == *"

また、dSYMをFabricにアップロードする場合は、UUIDが欠落しているものと一致することを確認する必要があります。開いているターミナルでこのコマンドを実行すると、dSYMのUUIDが得られます。

dwarfdump -u <PathToYourAppsDsym>

参照

Crashlytics Advanced Setup

7
Vineet Choudhary

バイナリを作成すると、シンボルはファイル内の特定の場所に配置されます。シンボルがない場合、クラッシュログはバイナリの特定のポイントからのオフセットを示します。 someFramework.someFunction +100

そのため、その特定のバイナリ内のインデックス作成に役立つdSYMファイルが作成されます。変更されたコードベースまたはプロジェクトを再アーカイブすると、新しいバイナリ内で異なるオフセットが発生するため、単純に再アーカイブしてアップロードすることはできません。

これが、gitリポジトリにrelease-v2.1などのタグを付けることが重要である理由です。したがって、必要に応じて、戻って再アーカイブすることができ、オフセットは同じである必要があります。

Fabricが機能する限り、dSYMファイルのzipバージョンが必要です。投稿した番号は、おそらくZipファイルのハッシュです。100％確実ではありません。

システムにFabricアプリがインストールされている場合、デバイスでバージョンを実行すると、dSYMファイルが自動的にアップロードされます（プロジェクトを繰り返しビルドして実行すると、アップロード帯域幅が破壊される可能性があります。プロジェクトごとに各dSYMファイルがアップロードされます。ビルド）。

Gitリポジトリで正確な時点を見つけ、シミュレーターでアプリを再実行するのが最善のオプションです。これにより、dSYMがアップロードされ、うまくいけば古いものとペアリングされますが、機能するかどうかはわかりません。それ以外の場合、正確なdSYMがあると思われる場合は、圧縮してアップロードしてみてください。

それが機能しない場合は、昔ながらの方法で、ターミナルとクラッシュログのオフセットを使用して手動で再シンボリック化する必要があります。少し時間がかかりますが、 atos を使用して実行できます

atos [-o AppName.app/AppName] [-l loadAddress] [-Arch architecture]
2
system