Właśnie to przeszedłem. Miałem dźwięk, który był niesamowicie rzadki (1-4 razy dziennie), nie był to standardowy dźwięk i na pozór losowy.
Doprowadzało mnie to do szału. Oto mój proces:
Pobierz iPhone Configuration Utility (u dołu) . To pozwoli ci spojrzeć na ostatnie wpisy dziennika z dziennika konsoli telefonu --- analogicznie do Console.app.
Po podłączeniu telefonu na lewym pasku bocznym pojawi się sekcja „Urządzenia”. Wybierz telefon, a następnie w zakładkach u góry po prawej stronie zobaczysz „konsolę” ( zrzut ekranu tutaj ).
Następnym razem, gdy pojawi się dźwięk, zanotuj czas, a następnie podłącz go i zapisz dziennik konsoli w pliku tekstowym.
Otwórz zapisany plik dziennika w wybranym edytorze. Będziesz chciał skupić się na czasie, w którym dźwięk się pojawił - dla mnie znałem tylko czas do minuty, ale to wystarczyło. Myślę, że moją pracę ułatwił fakt, że mój telefon był wtedy bezczynny.
Oto, co zobaczyłem w moim dzienniku:
Sep 25 15:24:28 CommCenter[68] <Notice>: Release assertion for reason: operation queue is empty
Sep 25 15:24:28 backboardd[28] <Notice>: MultitouchHID: device bootloaded
Sep 25 15:24:28 backboardd[28] <Notice>: MultitouchHID: detection mode: 6->6
Sep 25 15:24:28 configd[55] <Notice>: network changed: v4(en0:142.244.166.94, pdp_ip0) DNS Proxy
Sep 25 15:24:28 wirelessproxd[66] <Warning>: CoreBluetooth[WARNING] <CBCentralManager: 0x17e88250> is disabling duplicate filtering, but is using the default queue (main thread)
Sep 25 15:24:28 kernel[0] <Debug>: launchd[4555] Container: /private/var/mobile/Applications/DF67F833-5955-4E49-8101-87B804F5C04C (sandbox)
Sep 25 15:24:30 locationd[52] <Notice>: need a scan, count, 0, 0, lwatchdog, 0.0, interval, 60.0, needWatchdog, 1
Sep 25 15:24:30 locationd[52] <Notice>: scan result, count, wait, 1, retry, 0, error
Sep 25 15:24:30 locationd[52] <Notice>: scan result, count, wait, 1, retry, 1, error
Sep 25 15:24:30 locationd[52] <Notice>: scan result, count, wait, 1, retry, 2, error
Sep 25 15:24:31 mediaserverd[45] <Warning>: 15:24:31.746 [0x379e000] Sub_AudioSessionSetActiveWithFlags: WARNING translating CMSession error: -16980
Sep 25 15:24:34 locationd[52] <Notice>: loc watchdog expired, count, 1, 3
Sep 25 15:24:34 locationd[52] <Notice>: scan result, count, wait, 2, retry, 0, error
Sep 25 15:24:34 locationd[52] <Notice>: scan result, count, wait, 2, retry, 1, error
Sep 25 15:24:34 locationd[52] <Notice>: scan result, count, wait, 2, retry, 2, error
Sep 25 15:24:37 backboardd[28] <Notice>: ALS: SetDisplayFactor: factor=0.0000
Sep 25 15:24:37 kernel[0] <Debug>: AppleMultitouchN1SPI: updating power statistics
Sep 25 15:24:37 backboardd[28] <Notice>: MultitouchHID: detection mode: 6->255
Sep 25 15:24:37 kernel[0] <Debug>: ALS: AppleARMBacklight::setBacklightEnableGated 0 (set level to 0x1d7)
Kluczem tutaj jest ten wiersz: Sep 25 15:24:31 mediaserverd[45] <Warning>: 15:24:31.746 [0x379e000] Sub_AudioSessionSetActiveWithFlags: WARNING translating CMSession error: -16980
. To system audio zaczyna odtwarzać dźwięk.
Patrząc nieco dalej wstecz, to linia pokazuje ostatniego uruchomienia aplikacji: kernel[0] <Debug>: launchd[4555] Container: /private/var/mobile/Applications/DF67F833-5955-4E49-8101-87B804F5C04C (sandbox)
.
Rozsądnym założeniem jest to, że jest to winowajcą. Chciałbym usłyszeć, czy ktoś zapewnia łatwiejszy sposób odwzorowania identyfikatora UID aplikacji DF67F833-5955-4E49-8101-87B804F5C04C
na rzeczywistą nazwę. Dla mnie zacząłem otwierać aplikacje losowo, szukając hash winowajcy. Około 10 aplikacji później znalazłem: Downcast.app. Szybko zagłębiając się w ustawienia, znalazłem winowajcę: dźwięk powiadomienia o aktualizacji kanału został włączony.
Brzydkie, ale mi się udało. Powodzenia dla tych, którzy odrywają włosy, próbując znaleźć coś podobnego.