Android-приложение - обновленная версия, пытающаяся получить доступ к старым ресурсам

Question

мы используем OneSignal для отправки push-уведомлений на устройства с помощью нашего приложения.Я нахожусь в процессе преобразования его в FCM, который в основном был безболезненным, за исключением одной проблемы.С моим новым apk (v2.8), если я установлю его на устройство с текущей версией (v2.7) нашего приложения, то звуки уведомлений не будут работать.Он вибрирует, но нет звука (мы используем 2 пользовательских звука).Если я затем очищаю данные, то есть через настройки / приложения ../ Хранение / Очистка данных, тогда звуки начинают работать, как и ожидалось.Если я установлю на устройство, на котором приложение еще не установлено, оно будет работать правильно.Это только кажется проблемой на устройствах с Oreo и Pie.У меня есть Samsung S4 Mini, который не имеет проблемы.

В дополнение к этой проблеме, когда я вхожу в logcat после отправки тестового push-уведомления, я вижу следующую ошибку:
2019-03-27 11: 02: 40.978 5019-21507 /?E / FileSource: не удалось открыть файл 'android.resource: //staffsync.reliever/2131492871'.(Нет такого файла или каталога)

С помощью APK Analyzer я обнаружил, что идентификатор ресурса 2131492871 действительно принадлежит к необработанному звуковому файлу, который тестовое уведомление пытается воспроизвести , но из предыдущей версииапк, то есть тот, который эта установка обновила - v2.7.

Почему он пытается получить доступ к старому ресурсу?
TIA для любых идей.

Answer 1

Я не уверен, должен ли это быть ответ или добавление к вопросу.Я получил некоторые подсказки от Secolink Eu и Стив Стрэйтс .

Покопавшись в APK Analyzer в Android Studio, в частности в папке resources.arsc, я обнаружил, что ресурсам назначаются идентификаторы довольно систематично - каждый ресурс данного типа будет в серии с одинаковым первым4 числа, например 0f0d, а последние 4 присваиваются в алфавитном порядке имен ресурсов / имен файлов в типе, поэтому, если бы у меня в папке res / raw были a.mp3, b.mp3 и c.mp3, они были бы назначены0f0d001, 0f0d002 и 0f0d003 соответственно.В этом примере, если предыдущий тип res был menu, то он будет иметь идентификаторы ресурсов серии 0f0c, а исходящий тип - string - будет иметь значение 0f0e.

Если ваша базовая структура папок / файлов не меняется от сборки к сборкетогда есть вероятность, что вы получите одинаковые идентификаторы от одной сборки к другой ... easy
Но в моем случае в моей последней сборке все мои ресурсы raw / res начинались с 0f0c, в предыдущей сборке ониНачиная с 0f0d, я удалил папку res / menu, в которой ничего не было в новой сборке, в старой сборке этой папке были назначены идентификаторы 0f0c.
Так что, похоже, новая сборка не будет воспроизводить звуки, потому чтоустройство обращается к ресурсу совершенно другого типа с идентификатором 0f0dxxxx.Я полагаю, что это сохраняется даже после обновления из-за изменений безопасности Oreo / Pie.Если я верну удаленную папку res / menu и восстановлю папку res / raw, как было (я удалил некоторые звуки, которые мы не использовали), то моя новая сборка будет работать как положено.Мы можем заставить пользователей вручную очистить свои данные после установки нового приложения, которое решает проблему, но у нас есть несколько тысяч пользователей, многие из которых не знают, как это сделать, поэтому они звонят в службу поддержки, и те, кто победилЯ не могу вспомнить их данные для входа в систему ... поэтому они звонят в службу поддержки.
Это кажется довольно большим ограничением для Oreo и Pie, я понимаю, что они защищают предпочтения пользователя, но, возможно, процесс установки должен предложить опциюразрешить изменение ресурса уведомлений, или я что-то не так делаю, стоит ли размещать звуковые файлы в другом месте?