Comments 16
Вот чем мне все-таки нравится Android: получил системную ошибку, полез в исходники и понял причину.
Интересно чем же обусловлено подобное ограничение в старых версиях Android…
Оперативки небось мало, чтоб распаковать большие файлы. Ну или боятся отказа системы: какое-нибудь приложение загрузит архив весом 10кб и распаковывающийся в 10гб и подвесит.
Мало оперативной памяти + всё распаковывается в неё, а не во временный файл на диске. Ассеты — это своего рода заменитель ресурсов в экзешенике, а не обычный архив файлов, который распаковывается куда-то на диск.
Это скорее фича 2.3, там появилось API для работы с asset'ами из натива
А самому сжать средствами джавы в маленький файл, положить его в assets и при чтении распаковывать самому? Я делаю это так: code.google.com/p/diskusage/source/browse/trunk/src/com/google/android/diskusage/utils/MimeTypes.java
Надо теперь будет проверить не сжимается ли он ещё раз автоматически.
Надо теперь будет проверить не сжимается ли он ещё раз автоматически.
Мы вот так делаем — ассеты порезаны с помощью split и вытаскиваются на SD-карту:
qt.gitorious.org/+grym/qt/grym-android-lighthouse/blobs/android-master/src/plugins/platforms/android/grym/java/src/org/qt/util/AssetUtil.java
qt.gitorious.org/+grym/qt/grym-android-lighthouse/blobs/android-master/src/plugins/platforms/android/grym/java/src/org/qt/util/AssetUtil.java
Если данные файла используются только на чтение, то ничего мешает реализовать собственную «прослойку» через которую будут выполняться все запросы на чтение. А прослойка внутри себя будет следить за «позицией в файле» и по мере необходимости использовать file1.dat, file2.dat… fileN.dat.
Таким образом не надо будет ничего «склеивать при первом запуске»
Таким образом не надо будет ничего «склеивать при первом запуске»
Сталкивался с этой проблемой когда надо было развернуть на устройстве базу данных из бекап файла.
В итоге я просто обозвал файл «base.mp3» и при копировании на устроство переименовывал в нужный вид. Чуть позже я еще и архивировал ZIP-ом нужный файл, обзывал mp3, а на выходе распаковывал в нужную папку.
В итоге я просто обозвал файл «base.mp3» и при копировании на устроство переименовывал в нужный вид. Чуть позже я еще и архивировал ZIP-ом нужный файл, обзывал mp3, а на выходе распаковывал в нужную папку.
А зачем использовать AssetManager.ACCESS_BUFFER, может AssetManager.ACCESS_STREAM подойдет? Вот буквально на днях тестировал 3.5 Мб на Android 2.2. Прекрасно распаковывается на SD карточку.
Спасибо за подсказку. Сам сразу не догадался, проверю работу, как будет время. Способ с AssetManager.ACCESS_STREAM должен будет уменьшить количество действий и кода для второго способа из статьи.
Не пользуйтесь моей подсказкой :) Ведет себя очень неадекватно, на HTC работает 2.1, 2.2, на Samsung — нет.
stackoverflow.com/questions/1273300/ioexception-while-reading-from-inputstream
Читайте вот это. Я добавил .jpg и вроде работает, но если не подходит, то придется разбивать, тем более минус из-за .jpg выросло на 700 кб (без компрессии файл идет).
stackoverflow.com/questions/1273300/ioexception-while-reading-from-inputstream
Читайте вот это. Я добавил .jpg и вроде работает, но если не подходит, то придется разбивать, тем более минус из-за .jpg выросло на 700 кб (без компрессии файл идет).
Интересно, а обязательно хранить такой размерчик в ассетсах, есть особенные требования? Не легче ли при первом запуске скачать из инета все что нужно в виде архива и сохранить на сд карте?
Sign up to leave a comment.
Проблема с чтением файлов более 1Мб в Android