Android потерял доступ к выбранному файлу после перезапуска

Если Android после перезапуска потерял доступ к выбранному файлу, проверьте не только сохранённый URI, но и разрешение его использовать. В подходящем сценарии Storage Access Framework приложение сохраняет предоставленный persistable grant через takePersistableUriPermission(). Одна строка URI не выдаёт права, а сохранённое разрешение не гарантирует доступ к удалённому документу.

Ссылка на документ и право чтения — разные вещи

Приложение может успешно запомнить выбранный документ и после запуска показать его имя в списке недавних. Это ещё не подтверждает, что поставщик документа разрешает открыть содержимое сейчас. Поэтому ошибка чтения не обязательно связана с потерей записи в настройках.

Сначала выясните, каким действием пользователь выбрал документ и какие разрешения вернулись. Нельзя автоматически считать ACTION_OPEN_DOCUMENT, выбор фотографии и получение произвольного содержимого одним контрактом. Для диагностики нужен именно фактический путь выбора в приложении.

Когда применяется takePersistableUriPermission

В руководстве Android по документам общего хранилища описано сохранение предлагаемого системой URI-разрешения для доступа через перезапуск устройства. Приложение должно получить подходящий grant и сохранить предоставленные права. Вызов метода не создаёт отсутствующее разрешение на любой известный URI.

Официальный пример ActionOpenDocument показывает получение документа и сохранение права чтения. Пример полезен как подтверждение принципа, но способ получения результата выбора сверяйте с используемой архитектурой и текущим контрактом вашего приложения.

Если выдано чтение, не добавляйте запись просто для запаса. Сохраняйте только права, которые действительно предоставлены и нужны для функции. Возможности поставщика документа, разрешение на URI и собственная функция приложения — разные ограничения, каждое нужно проверить отдельно.

Учебная карточка документа после запуска приложения

Представим редактор заметок, который хранит ссылку на выбранный документ и собственный незавершённый комментарий к нему. Сценарии ниже вымышлены и нужны для приёмки. Они не утверждают, что любой конкретный поставщик файлов ведёт себя одинаково.

Почему сохранённое право не обещает вечный доступ

Документация Android отдельно предупреждает о перемещении или удалении документа: даже после сохранения URI-разрешения может понадобиться получить доступ заново. Поэтому список недавних должен уметь показывать недоступный объект, а не считать каждую сохранённую запись гарантированно открываемой.

У сетевого поставщика также нужно различать право и возможность получить содержимое в данный момент. Сохранение grant не является скачиванием файла и не обещает работу без сети. Если продукту нужен автономный режим, это отдельная функция со своими правилами хранения и обновления копии.

Не подменяйте каждый отказ чтения автоматическим удалением ссылки. Пользователь может восстановить доступность или выбрать документ заново. Сохраните понятный статус и разрешённый следующий шаг, а свои локальные заметки держите отдельно от результата открытия внешнего содержимого.

Почему content URI нельзя чинить выдуманным путём

URI поставщика — не обещание обычного файла по абсолютному пути, которым можно распоряжаться вне выданного контракта. Не стройте общий обход доступа через замену частей строки. Для своего сценария используйте предусмотренную работу с документом и обработку результата.

Название документа тоже не является достаточным идентификатором: разные объекты могут называться одинаково. При повторном выборе явно решите, заменяет ли он старую привязку или добавляет новую. Иначе исправление доступа может незаметно присоединить черновик не к тому документу.

Как восстановить работу без потери данных пользователя

Сообщение об ошибке должно объяснять, что приложение не смогло открыть связанный документ, и предлагать конкретное действие. Не утверждайте удаление, если установлен только отказ открытия. Для запроса разрешения и для временной сетевой проблемы могут требоваться разные следующие шаги.

Если нужен повторный выбор, сохраните собственный черновик до его выполнения. После получения нового URI проверьте возможность чтения и только затем меняйте подтверждённую привязку. Отмена выбора пользователем должна оставлять прежнюю заметку, а не уничтожать её вместе с неудачной попыткой.

При обработке ошибки сохраняйте технически полезный контекст без содержимого документа и лишних персональных сведений. Для разбора обычно важны путь выбора, предоставленные права, поставщик и фактический результат открытия. Полная копия частного файла в журнале не нужна.

Сценарии приёмки сохранённого доступа

1. Зафиксируйте используемое действие выбора и возвращённые права в тестовом сценарии.
2. Выберите учебный документ и проверьте первое открытие через предусмотренный интерфейс.
3. Подтвердите сохранение допустимого persistable grant и отдельно сохранение ссылки.
4. Проверьте повторный запуск приложения и перезапуск устройства по согласованному сценарию.
5. Отдельно проверьте перемещённый или удалённый документ и временно недоступное содержимое.
6. Проверьте повторный выбор, его отмену и сохранность собственного черновика.

Для каждого результата запишите, что установлено фактически: ссылка есть, право подтверждено, открытие удалось или завершилось ошибкой. Не сворачивайте все эти признаки в одну отметку «файл сохранён». План выше не означает, что здесь выполнялись установка приложения или испытания на устройстве.

Что нужно описать в требованиях к мобильному приложению

В разработке мобильного приложения согласуйте, должен ли документ оставаться внешним или продукт хранит свою копию. Это меняет поведение при изменении оригинала, работе без сети и удалении данных. Одного требования «запомнить выбранный файл» для такого решения недостаточно.

Если документ передаётся во внешнюю систему через API, уточните, передаётся ли содержимое или только связь с ним. Для доработки полезнее воспроизводимый жизненный цикл доступа, чем просьба запросить все возможные разрешения.

Исправление принимается по возможности продолжить разрешённую работу после нужного перехода, а при утрате доступа — восстановить её без потери своего ввода. Наличие URI в базе и успешный вызов одного метода являются частями этой проверки, а не её окончательным результатом.