Symbolicating iPhone App relatórios de falhas

https://stackoverflow.com/questions/1460892

13-09-2019
|

Pergunta

Eu estou olhando para tentar symbolicate relatórios de falhas do meu iPhone app.

Eu recuperei os relatórios de falhas do iTunes Connect. Eu tenho o binário do aplicativo que eu submetido à App Store e eu tenho o arquivo dSYM que foi gerado como parte da compilação.

Eu tenho todos esses arquivos juntos dentro de um único diretório que é indexado por holofotes.

E agora?

invocando

Eu tentei:

symbolicatecrash crashreport.crash myApp.app.dSYM

e ele só emite o mesmo texto que está no relatório do acidente para começar, não symbolicated.

Estou fazendo algo errado?

Solução

Passos para analisar relatório de travamento da Apple:

Copie o arquivo de liberação .app que foi empurrado para o appstore, o arquivo .dSYM que foi criado no momento da liberação e o relatório de acidente recebe da Apple em um Pasta .

aplicação terminal aberto e vá para a pasta criada acima (usando o comando cd)

Executar atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. A localização de memória deve ser aquele em que o aplicativo caiu conforme o relatório.

Ex: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

Isto mostrar-lhe a linha exata, o nome do método que resultou em acidente.

Ex: [classname functionName:]; -510

Symbolicating IPA

se usarmos IPA para symbolicating - basta mudar o nome do .ipa extensão com .zip, extraí-lo, em seguida, podemos obter uma pasta Payload que contêm aplicativo. Neste caso nós não precisamos de arquivo .dSYM.

Nota

Isso pode funcionar apenas se o binário do aplicativo não tem símbolos despojado. Pela liberação padrão constrói despojado os símbolos. Nós podemos mudar isso em configurações de compilação do projeto "Strip símbolos de depuração Durante Copiar" para NO.

Mais detalhes ver este pós

Outras dicas

Depois de ler todas essas respostas aqui, a fim de symbolicate um registro acidente (e, finalmente, ter sucesso) Eu acho que existem alguns pontos que faltam aqui que são realmente importantes, a fim de determinar por que a invocação de symbolicatecrash não produz uma saída symbolicated.

Existem 3 ativos que têm que se encaixam quando symbolicating um registro acidente:

O arquivo de log acidente em si (ou seja example.crash), seja exportado do organizador do Xcode ou recebidas a partir do iTunes Connect.

O pacote .app (ou seja example.app) que se contém o binário aplicativo pertencente ao log acidente. Se você tem um pacote .ipa (ou seja example.ipa), então você pode extrair o pacote .app por descompactar o pacote .ipa (ou seja unzip example.ipa). Posteriormente reside o pacote .app na pasta Payload/ extraído.

O pacote .dSYM contendo os símbolos de depuração (isto é example.app.dSYM)

Antes de iniciar symbolication você deve verificar se todos os artefatos corresponder, o que significa que o log acidente pertence ao binário que você tem e que os símbolos de depuração são aqueles produzidos durante a construção desse binário.

Cada binário é referido por um UUID que pode ser visto no arquivo de log acidente:

... Binary Images: 0xe1000 - 0x1f0fff +example armv7 <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example 0x2febf000 - 0x2fedffff dyld armv7s <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld ...

Neste extrato do log acidente pertence a uma imagem aplicativo binário chamado example.app/example com UUID aa5e633efda8346cab92b01320043dc3.

Você pode verificar o UUID do pacote binário que você tem com dwarfdump:

dwarfdump --uuid example.app/example UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

Depois disso, você deve verificar se os símbolos de depuração você também tem pertencem a esse binário:

dwarfdump --uuid example.app.dSYM UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

Neste exemplo todos os ativos se encaixam e você deve ser capaz de symbolicate seu stacktrace.

Processo para o script symbolicatecrash:

No Xcode 8.3, você deve ser capaz de chamar o script via

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

Se não estiver lá, você pode executar um find . -name symbolicatecrash em seu diretório Xcode.app para encontrá-lo.

Como você pode ver que não há mais parâmetros dados. Assim, o script tem que encontrar o seu binário do aplicativo e símbolos de depuração, executando uma busca holofotes. Ele procura os símbolos de depuração com um índice específico chamado com_apple_xcode_dsym_uuids. Você pode fazer isso busca-se:

mdfind 'com_apple_xcode_dsym_uuids = *'

resp.

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

A primeira chamada holofotes dá-lhe todos os pacotes dSYM indexados eo segundo dá-lhe os pacotes .dSYM com um UUID específico. Se holofotes não encontrar seu pacote .dSYM então symbolicatecrash será nenhum dos dois. Se você fizer todas essas coisas por exemplo em uma subpasta de sua holofotes ~/Desktop deve ser capaz de encontrar tudo.

Se symbolicatecrash encontra seu pacote .dSYM deve haver uma linha como a seguinte em symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

Para encontrar o seu pacote .app uma busca holofotes como o seguinte é invocado por symbolicatecrash:

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

Se symbolicatecrash encontra seu pacote .app deve haver o seguinte excerto no symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884 Found executable <SOME_PATH>/example.app/example -- MATCH

Se todos esses recursos são encontrados por symbolicatecrash deve imprimir a versão symbolicated do seu log acidente.

Se você não pode passar em seus arquivos dSYM e .app diretamente.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

Nota:. O backtrace symbolicated será a saída para terminal, não symbolicate.log

Com a última versão do Xcode (3.2.2), você pode arrastar e soltar quaisquer relatórios de falhas na seção Logs de dispositivos do Xcode Organizer e eles serão automaticamente por symbolicated para você. Eu acho que isso funciona melhor se você construiu essa versão do App usando Construir & Archive (também parte do Xcode 3.2.2)

Eu fiz isso com sucesso, utilizando os seguintes passos.

Passo 1: Crie uma pasta no ambiente de trabalho, dou nome dele para "CrashReport" e colocar três arquivos ( "MYApp.app", "MyApp.app.dSYM", "MYApp_2013-07 -18.crash ") nele.

Passo 2: Open Finder e vá para Aplicativos, onde você vai encontrar a aplicação Xcode, clique direito sobre esta e clique em "Mostrar conteúdo do pacote", após este seguir este caminho simples. "Contents-> Developer-> Platforms-> iPhoneOS.platform-> Developer-> Library-> PrivateFrameworks -> DTDeviceKit.framework -> Versions-> A-> Recursos"

ou

"Contents-> Developer-> Platforms-> iPhoneOS.platform-> Developer-> Library-> PrivateFrameworks -> DTDeviceKitBase.framework -> Versions-> A-> Recursos"

ou

Para Xcode 6 e acima o caminho é Applications / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Recursos

Onde você encontrar o arquivo "symbolicatecrash", copie este e colá-lo para a pasta "CrashReport".

Passo 3: o lançamento do terminal, executar estes 3 Comando

cd / Users / mac38 / Desktop / CrashReport e pressione o botão Enter

DEVELOPER_DIR exportação = "/ Applications / Xcode.app / Contents / desenvolvedor" e pressione Enter

./ symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM e pressione Enter Agora seu feito .. (NOTA: versões cerca de 6,4 ou mais tarde, não tem a opção -A - apenas deixá-lo out).

Passos para symbolicate um relatório acidente automaticamente usando o Xcode:

ATUALIZADO PARA Xcode 9

Conectar qualquer dispositivo iOS para o Mac (sim uma agressão física, sim, eu sei que isso é estúpido)

Escolha "Dispositivos" no menu "Janela"

Clique no dispositivo nos registros da esquerda e da visualização do dispositivo à direita

Espera. Pode demorar um minuto para aparecer. Talvez fazendo Command-A então Delete vai acelerar o processo.

passo indocumentados Critical: renomear o relatório acidente que você tem de iTunesConnect de extensão .txt a extensão .crash

Arraste o relatório de travamento para essa área à esquerda

E então Xcode vai symbolicate o relatório do acidente e exibir os resultados.

Fonte: https://developer.apple.com/library/ ios / technotes / tn2151 / _index.html

Eu uso Airbrake em meus aplicativos, que faz um bom trabalho de registro de erros remoto.

Aqui está como eu symbolicate deles com a Atos se o backtrace precisa dele:

No Xcode (4.2) ir para o organizador, clique direito sobre o arquivo de qual o arquivo .ipa foi gerado.

No Terminal, cd na xcarchive por exemplo MyCoolApp 10-27-11 1.30 PM.xcarchive

Digite o seguinte atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (Não se esqueça as aspas simples)

Eu não incluir o meu símbolo no essa chamada. O que você recebe é um cursor de bloco em uma linha vazia.

Então eu copiar / colar meu código símbolo naquele cursor bloco e pressione entrar. Você verá algo como:

-[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

Você está de volta para um cursor de bloco e você pode colar em outros símbolos.

Ser capaz de passar por seu backtrace um item sem re-introduzir o primeiro bit é um poupador de tempo bom.

Aproveite!

Eu também colocar dsym, pacote de aplicativos e log acidente juntos no mesmo diretório antes de executar acidente symbolicate

Então eu uso essa função definida na minha .profile para simplificar correndo symbolicatecrash:

function desym { /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more }

Os argumentos acrescentou que não pode ajudá-lo.

Você pode verificar para certificar-se de holofotes "vê" seus arquivos dysm executando o comando:

mdfind 'com_apple_xcode_dsym_uuids = *'

Procure a dsym você tem em seu diretório.

NOTA: Como da última Xcode, não há mais um diretório Developer. Você pode encontrar este utilitário aqui:

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers íons / A / Resources / symbolicatecrash

Apenas um simples e resposta atualizado para o Xcode 6.1.1.

PASSOS

1.Xcode> Janela> Devices.

2.Select um dispositivo a partir de uma lista de dispositivos na secção dispositivos.

3.Select Visualização de Logs de dispositivo.

4.Sob seção All Logs você pode diretamente arrastar soltar o report.crash

5.Xcode automaticamente Symbolicate o relatório acidente para você.

6.You pode encontrar o relatório de travamento Symbolicated, combinando a sua data / hora com a Data / Hora mencionado no seu relatório de acidente.

Mesmo que eu tinha vindo a desenvolver aplicativos para alguns anos agora, esta foi a minha primeira vez a depuração de um binário e eu me senti como um noob completo descobrir onde todos os arquivos foram ou seja, onde é * .app * .dSYM e registros de acidente ? Eu tive que ler várias mensagens, a fim de descobrir isso. Imagem vale mais que mil palavras e espero que este post ajude alguém no futuro.

1- Primeiro, vá para itunesconnect e descarregue seus registros de acidentes. NOTA: É a maioria dos casos, você pode obter algo como "Muito poucos relatórios foram enviados para um relatório a ser mostrado." Basicamente não número suficiente de usuários apresentaram relatórios de log de falhas para a Apple caso em que você não pode fazer muita coisa nesse ponto.

2 Agora, se você não mudou seu código desde que você tinha apresentado o seu binário para a Apple, então, lançar Xcode para esse projeto e fazer do produto -> Arquivo novamente. Caso contrário, basta encontrar o seu mais recente binário enviado e clique direito sobre ela.

No Xcode 4.2.1, aberta Organizador , em seguida, ir para a Biblioteca / Device Logs e arraste o arquivo .crash na lista de registros de acidentes. Será symbolicated para você depois de alguns segundos.

Note que você deve usar a mesma instância do Xcode que a construção original foi arquivado em (ou seja, o arquivo para a sua construção deve existir no Organizador ).

Usando o Xcode 4, a tarefa é ainda mais simples:

open Organizador ,

clique em Biblioteca | Dispositivo Log na coluna da esquerda

clique em " Importar " botão na parte inferior da tela ...

e voilà. O arquivo de log é importado e simbolizava automaticamente para você. Desde que você arquivados a compilação usando Xcode -> produto -.> Arquivo início

O mágico Xcode Organizer não é tão mágico sobre symbolicating meu aplicativo. Eu tenho nenhum símbolo em tudo para os relatórios de falhas que eu voltei da Apple a partir de uma submissão aplicativo falhou.

Eu tentei usar a linha de comando, colocando o relatório acidente na mesma pasta do arquivo .app (que submeti à loja) eo arquivo .dSYM:

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

Isso só fornecidos símbolos para meu aplicativo e não o código de fundação do núcleo, mas foi melhor do que o despejo número que Organizador está me dando e foi o suficiente para me encontrar e corrigir o acidente que meu aplicativo teve. Se alguém sabe como estender isso para obter símbolos Fundação seria apreciado.

No meu caso, eu estava arrastando relatórios de falhas diretamente do Mail para o Organizador. Por alguma razão, que impediu os relatórios de falhas de ficar symbolicated (Eu adoraria saber por que).

A cópia dos relatórios de falhas para o desktop primeiro, e depois arrastá-los de lá para o Organizador tem-los symbolicated corretamente.

caso muito específico, eu sei. Mas pensei que iria partilhar apenas no caso.

Aqui está outro problema que tenho com symbolicatecrash - não vai trabalhar com aplicativos que têm espaços em seu pacote (ou seja, 'Test App.app'). Nota eu não acho que você pode ter espaços em seu nome quando enviar por isso você deve removê-los de qualquer maneira, mas se você já tem acidentes que precisam analisar, symbolicatecrash patch (4.3 GM) como tal:

240c240 < my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\""; --- > my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\""; 251c251 < my $cmd = "find \"$archive_path/Products\" -name $exec_name.app"; --- > my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

Para aqueles que usam Airbrake, não há uma resposta sólida acima, mas isso não iria funcionar para mim, sem ajustes:

funciona para alguns endereços de memória, mas não outros, não sei porquê ...

Criar novo dir no desktop ou onde

Encontre arquivo em questão no Xcode organizador

Toque duas vezes para revelar no Finder

Toque duas vezes para mostrar o conteúdo do pacote

Copiar arquivo .dSYM e arquivo .app no ??novo dir

cd no novo dir

Execute este comando: Atos -arch ARMv7 -o 'Vimeo.app' / 'Vimeo'

Terminal vai entrar um movimento interativo

Colar no endereço de memória e aperte enter, ele será o nome do método de saída e número de linha

Se preferir, digite o comando: Atos -arch ARMv7 -o 'Vimeo.app' / 'Vimeo' Para obter informações para um endereço só

A combinação que funcionou para mim foi:

Copie o arquivo dSYM para o diretório onde o relatório acidente foi

Descompacte o arquivo IPA contendo o aplicativo ( 'MyApp.ipa unzip')

Copie o binário da aplicação da carga explodiu resultando na mesma pasta que o relatório do acidente e arquivo de símbolo (algo como "MyApp.app/MyApp")

Importar ou Re-symbolicate o relatório acidente de dentro organizador
O Xcode

Usando Atos eu não era capaz de resolver as informações símbolo correto com os endereços e os deslocamentos que estavam no relatório de acidente. Quando eu fiz isso, eu vejo algo mais significativo, e parece ser um rastreamento de pilha legítimo.

Eu tive que fazer um monte de hackers do script symbolicatecrash para obtê-lo para executar corretamente.

Tanto quanto eu posso dizer, symbolicatecrash exige agora o .app para estar no mesmo diretório que o .dsym. Ele usará o .dsym para localizar o .app, mas não vai usar o dsym para encontrar os símbolos.

Você deve fazer uma cópia de seu symbolicatecrash antes de tentar essas manchas que irá torná-lo olhar na dsym:

Perto da linha 212 na função getSymbolPathFor_dsymUuid

212 my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

Perto da linha 265 na função matchesUUID

265 return 1;

Esta é simples, depois de pesquisar um monte i encontrados medidas claras para symbolicate arquivo de log acidente todo.

copiar arquivos .app, crash_report e DSYM em uma pasta.

conectar o dispositivo com o Xcode

Em seguida, vá para a janela -> selecione dispositivos -> logs de dispositivos vista
Em seguida, selecione o dispositivo, apagar todos os logs.

arrastar e soltar o seu acidente na seção de log dispositivo. ele vai symbolicate automaticamente o acidente. basta clicar sobre o relatório e exportá-lo.

codificação feliz,
Riyaz

Eu prefiro um roteiro que irá symbolicate todos os meus registros de acidente.

Pré-requisitos

Crie uma pasta e colocar lá 4 coisas:

symbolicatecrash perl roteiro - há muitas respostas para que diz sua localização

O arquivo da compilação que correspondem aos acidentes (de Xcode Organizer. Simples como Show in Finder e cópia) [Eu não tenho certeza este é necessery]

Todos os pacotes xccrashpoint - (. Do Xcode Organizer Show in Finder, você pode copiar todos os pacotes no diretório, ou o único xccrashpoint você gostaria de symbolicate)

Adicionar que pequeno script para o diretório:

#!/bin/sh echo "cleaning old crashes from directory" rm -P *.crash rm -P *.xccrashpoint rm -r allCrashes echo "removed!" echo "" echo "--- START ---" echo "" mkdir allCrashes mkdir symboledCrashes find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \; cd allCrashes for crash in *.crash; do ../symbolicatecrash $crash > ../symboledCrashes/V$crash done cd .. echo "" echo "--- DONE ---" echo ""

The Script

Quando você executar o script, você terá 2 diretórios.

allCrashes -. Todas as falhas de todo o xccrashpoint estará lá

symboledCrashes -. Os mesmos acidentes mas agora com todos os símbolos

Você NÃO precisa limpar o diretório de falhas antigas antes de executar o script. ele irá limpar automaticamente. boa sorte!

Para acidentes symbolicate, Spotlight deve ser capaz de encontrar o arquivo .dSYM que foi gerado ao mesmo tempo o binário que submetidos a Apple foi. Uma vez que contém as informações de símbolos, você vai estar fora de sorte se ele não está disponível.

Eu tenho um mal-humorado pouco sobre o fato de nada aqui parece "apenas trabalho" Então eu fiz alguma investigação e o resultado é:

Configurar: QuincyKit back-end que recebe relatórios. Sem symbolication configurado como eu não poderia mesmo começar a descobrir o que eles estavam sugerindo que eu faço para fazê-lo funcionar.

A correção: download de relatórios de falhas do servidor on-line. Eles são chamados de 'Crash' e pelo movimento padrão para o diretório / pasta ~ / Transferências. Com isso em mente, este script irá "fazer a coisa certa" e os relatórios de falhas vai entrar em Xcode (Organizador, logs de dispositivos) e symbolication será feito.

O script:

#!/bin/bash # Copy crash reports so that they appear in device logs in Organizer in Xcode if [ ! -e ~/Downloads/crash ]; then echo "Download a crash report and save it as $HOME/Downloads/crash before running this script." exit 1 fi cd ~/Library/Logs/CrashReporter/MobileDevice/ mkdir -p actx # add crash report to xcode abbreviated cd actx datestr=`date "+%Y-%m-%d-%H%M%S"` mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

As coisas podem ser automatizados para onde você pode arrastar e soltar no Xcode Organizer fazendo duas coisas se você fizer uso QuincyKit / PLCR.

Em primeiro lugar, você tem que editar o administrador script remoto / actionapi.php ~ linha 202. Não parece para obter o direito timestamp, então o arquivo termina com o nome 'acidente' que Xcode não reconhece ( ele quer acidente algo dot):

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

Em segundo lugar, no lado do iOS em QuincyKit BWCrashReportTextFormatter.m ~ linha 176, alterar @"[TODO]" para @"TODO" para contornar os personagens maus.

A Atos está sendo preterido por isso, se você estiver executando o OSX 10.9 ou mais tarde você pode precisar executar

xcrun atos

Atenção: / usr / bin / Atos está se movendo e será removido de um futuro OS liberação X. Ela agora está disponível nas ferramentas de desenvolvimento Xcode para ser invocada via: xcrun atos

Eu gosto de usar Textwrangler a erros pontuais em uma rejeição originais binário aplicativo upload. (Os dados sobre o acidente será encontrado em sua conta itunesConnect). Usando o método de Sachin acima eu copiar o original.crash para TextWrangler, em seguida, copie o arquivo symbolicatecrash eu criei para outro arquivo TextWrangler. Comparando-se os dois arquivos aponta diferenças. O arquivo symbolicatecrash terá diferenças que apontam o número de problemas de arquivo e linha.

Eu descobri a maioria das alternativas propostas não funcionou no último XCode (testado com Xcode 10). Por exemplo, eu não tive sorte de arrastar-soltar registros .crash no Xcode -> Organizador -> logs de dispositivos -View
.
Eu recomendo usar ferramenta Symbolicator https://github.com/agentsim/Symbolicator

Git clone repositório Symbolicator e compilar e executar com o Xcode

Copiar .crash (arquivo ascii, com rastreamento de pilha em implorando de arquivo) arquivo e .xarchive de deixar de funcionar a libertação para mesma temporarly pasta
Arraste e solte .crash arquivo para ícone Symbolicator no Dique

Em 5-30 segundos symbolicated arquivo de acidente é produzido na mesma pasta que .crash e .xarchive são

Nós usamos Google Crashlytics para supervisionar os registros de acidentes, o sentimento é muito oportuna e conveniente para o uso.

Documento liga: https://docs.fabric.io/apple/crashlytics/ faltando-dsyms.html # faltando-dsyms

Tudo sobre dSYMs Faltando Tecido inclui uma ferramenta para carregar automaticamente dSYM do seu projeto. A ferramenta é executada através do script / run, que é adicionado ao seu Run script de construção Fase durante o processo de integração. Pode haver certas situações no entanto, quando os envios dSYM falhar por causa de configurações únicas de projeto ou se você estiver usando Bitcode em seu aplicativo. Quando um upload falhar, Crashlytics não é capaz de symbolicate e exibir acidentes, e um alerta de “Missing dSYM” aparecerá no seu painel de tecido.

dSYMs em falta podem ser carregados manualmente seguindo as etapas descritas a seguir.

Nota: Como uma alternativa para a ferramenta automatizada de upload dSYM, Fabric oferece uma ferramenta de linha de comando (Enviar símbolos)) que pode ser configurado manualmente para ser executado como parte do processo de construção do seu projeto. Consulte a seção de upload-símbolos abaixo para obter instruções de configuração.

...

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow