Info.plist de l'application doit contenir une key NSMicrophoneUsageDescription avec une valeur de string expliquant à l'user comment l'application utilise ces données

Obtention d'un rejet de build L' Info.plist l' Info.plist doit contenir une key NSMicrophoneUsageDescription avec une valeur de string expliquant à l'user comment l'application utilise ces données.

L'application n'utilise pas de microphone. Ou alors je pense.

Comment puis-je localiser où mike est utilisé?

UPD23112016: étant donné que la réponse paresseuse est mise à jour, j'ai déposé une nouvelle request de fonctionnalité avec apple pour fermer ce trou de security.

UPD05042017: il est toujours gênant qu'une fois que vous avez proxy access Mike dans un cadre tiers par l'intermédiaire de NSMicrophoneUsageDescription à moitié cuit vous n'avez aucun contrôle sur où et quand il peut être utilisé si l'user accepte d'autoriser l'access Mike. Folks, veuillez faire preuve de diligence raisonnable et rédiger une description précise de NSMicrophoneUsageDescription qui reflète le fait que le micro est utilisé par le code qui est complètement hors de votre contrôle lorsque l'utilisation est obscurcie par un framework binary uniquement. Merci.

Ajoutez NSMicrophoneUsageDescription key NSMicrophoneUsageDescription & en valeur ajoutez la justification expliquant pourquoi votre application utilise Microphone. Ceci est la dernière exigence dans iOS 10.

Pour les fainéants:

si vous souhaitez append rapidement des descriptions d'utilisation pour la plupart des access aux médias (sur les photos de l'appareil, la camera, l'logging video, l'location):

faites un clic droit sur votre file info.plist et -> open as -> Code source

puis collez le suivant entre les valeurs actuelles:

 <key>NSMicrophoneUsageDescription</key> <ssortingng>Need microphone access for uploading videos</ssortingng> <key>NSCameraUsageDescription</key> <ssortingng>Need camera access for uploading Images</ssortingng> <key>NSLocationUsageDescription</key> <ssortingng>Need location access for updating nearby friends</ssortingng> <key>NSLocationWhenInUseUsageDescription</key> <ssortingng>This app will use your location to show you cool stuff near you.</ssortingng> <key>NSPhotoLibraryUsageDescription</key> <ssortingng>NeedLibrary access for uploading Images</ssortingng>

Ces descriptions sont bien sûr à vous. J'ai essayé de les rendre aussi generics que possible.

J'espère que cela fait gagner du time à quelqu'un!

Et le coupable était (batterie): Cadre Instabug. Ils vous disent juste là sur leurs pages de marketware qu'ils permettent aux users de prendre des notes audio pendant la composition de rétroaction. J'ai donc ajouté NSMicrophoneUsageDescription dans le plist de l'application expliquant cela.

Notez qu'il y a beaucoup d'API Apple qu'instabug utilise

Symboles indéfinis pour l'architecture arm64: (j'en ai enlevé quelques-uns qui semblent légitimes selon ce que ce framework prétend faire et laissé ce que je ne vois pas dans le marketware)

"_AVMakeRectWithAspectRatioInsideRect", référencé par: + [IBGIAMImageAttachmentView sizeForContent: forWidth:] dans InstabugHost_lto.o

"_OBJC_CLASS _ $ _ CTTelephonyNetworkInfo", référencé par: objc-class-ref dans InstabugHost_lto.o

"_AVNumberOfChannelsKey", référencé à partir de: – [IBGVoiceNoteManager startRecording] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyHSDPA", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyGPRS", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyWCDMA", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyEdge", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMA1x", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMAEVDORevA", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMAEVDORevB", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyLTE", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_OBJC_CLASS _ $ _ AVURLAsset", référencé par: _OBJC_CLASS _ $ _ IBGAsset dans InstabugHost_lto.o

"_OBJC_METACLASS _ $ _ AVURLAsset", référencé par: _OBJC_METACLASS _ $ _ IBGAsset dans InstabugHost_lto.o

"_CTRadioAccessTechnologyCDMAEVDORev0", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

"_CTRadioAccessTechnologyHSUPA", référencé par: + [IBGInspector getCarrier] dans InstabugHost_lto.o

ld: symbole (s) non trouvé (s) pour l'architecture arm64

Donc, dans ce monde post-Snowden, je me request pourquoi il a besoin d'une corééléphonie, par exemple.

Donc ce que je veux dire, c'est que si vous n'avez pas la source d'un framework tiers, vous devez divulguer à l'user que votre application elle-même n'utilise pas de microphone, ou de camera pour que l'user ait la possibilité de refuser l'access à cet appareil.

Vous ne voulez pas être dans les nouvelles un jour en raison d'une faille de security exploitée via votre application.

Non résolu: La description de l'utilisation du microphone soigneusement conçue ne résout pas complètement le problème de security au cas où votre application utilise un microphone et un framework tiers (pensez-y) en a également besoin.

Voici où la révélation des crédits pourrait être utile pour donner aux users une idée du code de tiers sur lequel vous vous appuyez. Donnez le crédit où il est dû: ^)

Si vous êtes paresseux comme moi et ne lisez jamais le livre blanc de security d'ios, voici un petit https://developer.apple.com/videos/play/wwdc2016/705/

Si vous êtes vraiment paresseux vers 19h00, l'orateur vous dit explicitement que vous ne devriez pas être paresseux à propos de ces descriptions.

Instabug utilise NSMicrophoneUsageDescription pour permettre à vos users d'save une note vocale à propos d'un bug ou d'un feedback.

La raison en est les frameworks manquants dans Linked FrameWorks et Libraries, comme avkit et avfoundation