На андроид-эмуляторе с помощью Device File Explorer студии можно видеть и читать любые файлы из датакаталога запущенного приложения.
Что ж, форкнусь и буду пробовать отсылать пэдээфы на указанный юзером ящик посредством встроенного в андроид гугловского почтового клиента. Правда, есть неудобство: юзер приложения должен иметь аккаунт в Гугле, и файлы будут приходить на указанный юзером ящик от имени юзера, прописанного в его гугловском аккаунте. Но, считаю, это мелочь. Впрочемм... Неизвестно, долго ли Гугл будет позволять бесплатно использовать его клиента.
Вкуриваю доки. Кое-что ниже 11-го уровня ОС ещё разрешено, начиная с 11-го -- трудности невероятные -- полный разгром свободы. Пока не знаю, как выкрутиться. Но уверен -- выход есть. Голова уже потрескивает. Никто не поможет?
Засада, возможно, в том, что в современных андроидах вся флеш-память считается внутренней. Студийные эмуляторы же помимо внутренней памяти имеют как бы реальную внешнюю память, отщипнутую у озу компа; поэтому на студийном эмуляторе у меня всё работает, пдф-файлы пишутся в примонтированную виртуальную эсдишку и успешно передаются по мылу. Неужели из-за этой говны придётся отказываться от одной симки и к 128 гигам добавлять какую-то дешёвенькую эсдишку на гиг эдак 16.
Думал, уже думал. Но ему надо дать разрешение на выемку файла, сгенерированного в датакаталоге. Возможно и даже очень возможно, что получится, если мейлер будет в том же пакете, в котором находится моё приложение и сгенерированный пдф-файл. Т.е. надо писать мейлер самому или спизпозаимствовать готовый код и вставить этот код в моё приложение. Веду поиск.
Ещё вариант -- написать провайдер контента в пакет, в котором находится прокси-мейлер.
По-любому спасибо тебе за поддержку.
Программирование под андроид -- квест и ходьба по минному полю. Доки весьма запутанные.
Прочитал в офдоках одну вещь. Начиная с 10-го уровня ОС Андроид, приложение может беспрепятственно сохранять файлы в директориях для изображений, видео и аудио в соответствующих форматах. Но если формат не соответствует диру, то пшёлнаф. Т.е. pdf не сохранишь, и его надо преобразовывать в изображение. По счастью андроид, начиная с 5-ого уровня, это умеет. Плохой выход, но всё же.
Ура! Повалил проблему. Оказывается, функция Environment.getExternalStorageDirectory() корректно работает только на старых андроидах (9 и ниже) и только с реальной воткнутой эсди-карточкой. В современных андроидах от встроенной памяти система всё же отщипывает кусок и предоставляет его пользователю, как эмулированную внешнюю память. А я ломился в открытые двери и просил научить, как отщипнуть! Гугл уже позаботился.
Доступ к эмулированной внешней памяти осуществляется функцией new File(String.valueOf(main_activity_ctx.getExternalCacheDir())), где main_activity_ctx -- ссылка на контекст приложения. Может, кому пригодится.
Кроме того, надо разрешать доступ к внешней памяти не из манифеста, а и из кода, и в манифесте разрешить монтировку создаваемых диров.
Что поделать -- самоучка я; на курсах, вероятно, этому учат. :)
Петро, какой же я нахрен молодец? МЕСЯЦ разработка топталась на месте. МЕСЯЦ! За такую работу в фирме меня бы точно уволили. Правда, если бы я работал в фирме, то, думаю, у более опытных товарищей быстрее бы нашёл ответ. К чему это я? А к тому, что "Вести" мало читают. Вопреки давнишним высказываниям Питона, ибо посещаемость типа открыл-закрыл - - не показатель.
Впрочем, моральная поддержка "старичков" дорого стОит.
Оказывается, система андроид примерно раз в сутки без ведома пользователя чистит кэш приложения в эмулированной внешней памяти. Кэш находится по адресу: /storage/emulated/0/Android/data/имя_пакета_приложения/cache/
Ошибка ли это системы или нет -- не знаю. Ошибка ли это конкретного девайса (p30 light, 10-ка) - - вряд ли, на эмуляторах разных девайсов то же. Свободной памятив в моём девайсе навалом - - более 100 гиг.
Гугл не помог. :(
Кто-нибудь может что-нибудь подсказать? (Ну, кроме "пиши в другое место".)
О, это я уже давно пробовал. getExternalFilesDir() возвращает путь к каталогу Android/data/data/имя_пакета/, однако работать с этим каталогом система позволяет только моему приложению, т.е. другие приложения (в т.ч. и файловые манагеры) не имеют права туда лезть. Об этом я уже сообщал.
Добавлять же скрытый копипастер в своё приложение, чтобы перекидывать пэдээфы из датакаталога куда-нибудь, не хочется, чтобы не засоряться, да и возиться с отладкой тоже не хочется. Но, возможно, придётся. Now I am исследованинг, отчего может происходить незапланированная очистка кэша. Вот это беспокоит. Неужели ошибка в системе?
Я пользуюсь файловым манагером Amaze, он мне наиболее подходит. Его особенность -- настраиваемая домашняя папка. Вот я настроил её на кэш приложения и в один клик после разных манипуляций с девайсом посматриваю, исчезли или нет мои пэдээфы.
Написал простейший файловый браузер, чтобы отыскивать свои пэдээфы. Это -- не то приложение, которым пэдээфы записываю. Создаю в браузере ссылку двумя способами:
extStore = new File("/storage/emulated/0/Android/data/com.mike.mysecondprj/cache");
extStore = new File(String.valueOf(this.getExternalCacheDir()));
Первый способ находит пэдээфы, второй -- нет. Неудивительно, так как this.getExternalCacheDir() подсталяет имя пакета браузера, а это -- другое имя. :)
Но почему исчезают файлы в кэше -- Бог (Гугл?) знает. Сегодня пока ни один не исчез.
Т.е. на кэш его настроить можно, а на /data (без cache) - нет? Странная логика...
Гхм.... В Android/data/data/имя_пакета/ хранятся жизненно важные для приложения данные -- БД, ини-файлы, временные файлы, повреждение или удаление которых приводят к неработоспособности приложения. Поэтому все файловые манагеры нерутованного андроида показывают, что эта папка пустая. Т.е. настроить-то можно, но ничего не видно. :)
Кешам и темпам ты не хозяин.
Не совсем так. Темпам, конечно, не хозяин, а кэшам -- хозяин, но не я, а приложение. Иначе зачем кэш приложению?
Кажется, просёк фишку. Но ещё не уверен. Файл из кэша приложения можетбыть удалён системой при условии, что он открыт, а открывшее его приложение, например, файловый манагер, закрыт. Возможно, система считает такой открытый файл мусорным. И если открытый файл ничем не используется, то через некоторое время система удаляет его из кэша. Но это пока рабочая гипотеза.
Ну, посмотрел, что там в pdf-отчёте, и забыл закрыть.
Однако я ошибся. Даже если файл не открыт, но приложение не пользовалось этим кэшированным файлом более суток, то система его удаляет. Вывод: файл после сохранения в кэше надо тотчас же где-то сохранять. Вопрос: где? В некоторых моделях андроидов есть директорий PDF. Вероятно, туда. Но в некоторых моделях этого дира нет. В некоторых андроидах есть дир SHAREit.
И есть ли какая-то настройка в андроиде, которая бы предотвращала слежение за кэшами приложений? Или это неотключаемый рудимент, оставшийся со времён, когда памяти было с гулькин нос и чистка кэша была одним из важнейших занятий?
Попробовал копировать pdf-файлы из кэша в директорий /storage/emulated/0/PDF. В эмуляторе всё работает "на ура". В реальном девайсе -- не копирует, хотя все формальные разрешения есть. Похоже, приложение пытается скопировать на реальную эсди-карточку, которой в девайсе нет. Но вот фокус: с помощью манагера Amaze на реальном девайсе могу копировать файлы из кэша в /storage/emulated/0/PDF...
КАК девайс понимает, что /storage/emulated/0/, что это эмулированная эсди, а не реальная физическая?!
Видимо, есть какое-то динамическое разрешение, которое я ещё не вкурил. Буду курить, когда решу навалившуюся проблему: некоторые УСПД дуреют и сдвигают зафиксированные графики нагрузок на полчаса. Т. е. сутки как бы начинаются с последнего получаса прошлых суток. Обратился к изготовителю, он резидент РБ. Оказалось, там об этом знают и знают давно, но не знают причину. Мой заказчик на рогах: может потерять неск. десятков тыс. брб.
Еду на перезапуск, дистанционно исправить не удалось.
Графики в УСПД стали на место, однако отвалился субабонент. Оказалось, при считывании настроек УСПД 1-ая строка 2-го ввода субаюонента продублировалась последней строкой его 1-го ввода. Говнософт - - он и есть говнософт. Не я его писал. Писали недавние студенты, которые, точно с тервером не дружат - - ни контрольных сумм, ни CRC. По специальности я связист, а потом уж говнопрогер, но давно усвоил, что данные при передаче по говноканалам могут исказиться. Поэтому никому и ничему верить нельзя.
Они ставят опрашиваемые девайсы в очередь. Казалось бы, всё норм. Но вот на телефоне висит с десятка полтора девайсов. Софт коннектится с первым, опрашивает и дисконнектится. Потом коннектится со следующим и делает то же. В чём прикол? На опрос - - пару секунд, на коннет-дисконнект - - на порядок больше. Телефонный номер, ессно, тот же. Да только интервал опроса не резиновый. В итоге очередь растёт и в конце-концов возникают потери данных. Но юных дарований это не имеет.
Страницы
И даже терминал не поможет, если у вас нет прав рута или суперъюзера. :)
:(
Нда, никто не помог. Хотя Петро пытался.
На андроид-эмуляторе с помощью Device File Explorer студии можно видеть и читать любые файлы из датакаталога запущенного приложения.
Что ж, форкнусь и буду пробовать отсылать пэдээфы на указанный юзером ящик посредством встроенного в андроид гугловского почтового клиента. Правда, есть неудобство: юзер приложения должен иметь аккаунт в Гугле, и файлы будут приходить на указанный юзером ящик от имени юзера, прописанного в его гугловском аккаунте. Но, считаю, это мелочь. Впрочемм... Неизвестно, долго ли Гугл будет позволять бесплатно использовать его клиента.
Как думаете?
Отставить думать. Потому что гугловский клиент не имеет права брать файлы из датакаталога приложения, а писать свой почтовый клиент не хочется.
Какие извращения! Неужели нет возможности обойти все это?
Вкуриваю доки. Кое-что ниже 11-го уровня ОС ещё разрешено, начиная с 11-го -- трудности невероятные -- полный разгром свободы. Пока не знаю, как выкрутиться. Но уверен -- выход есть. Голова уже потрескивает. Никто не поможет?
Засада, возможно, в том, что в современных андроидах вся флеш-память считается внутренней. Студийные эмуляторы же помимо внутренней памяти имеют как бы реальную внешнюю память, отщипнутую у озу компа; поэтому на студийном эмуляторе у меня всё работает, пдф-файлы пишутся в примонтированную виртуальную эсдишку и успешно передаются по мылу. Неужели из-за этой говны придётся отказываться от одной симки и к 128 гигам добавлять какую-то дешёвенькую эсдишку на гиг эдак 16.
:(
А прокси-мейлера никакого нет? В плане - ты ему шлешь на localhost, а он дальше.
Думал, уже думал. Но ему надо дать разрешение на выемку файла, сгенерированного в датакаталоге. Возможно и даже очень возможно, что получится, если мейлер будет в том же пакете, в котором находится моё приложение и сгенерированный пдф-файл. Т.е. надо писать мейлер самому или
спизпозаимствовать готовый код и вставить этот код в моё приложение. Веду поиск.Ещё вариант -- написать провайдер контента в пакет, в котором находится прокси-мейлер.
По-любому спасибо тебе за поддержку.
Программирование под андроид -- квест и ходьба по минному полю. Доки весьма запутанные.
Прочитал в офдоках одну вещь. Начиная с 10-го уровня ОС Андроид, приложение может беспрепятственно сохранять файлы в директориях для изображений, видео и аудио в соответствующих форматах. Но если формат не соответствует диру, то пшёлнаф. Т.е. pdf не сохранишь, и его надо преобразовывать в изображение. По счастью андроид, начиная с 5-ого уровня, это умеет. Плохой выход, но всё же.
Какой корявый костыль будет!
Ну это на самый-самый крайняк. Покамест вкуриваю Storage Access Framework.
Программировать под андроид существенно сложнее, чем под десктоп -- много зависит от уровней API.
Ура! Повалил проблему. Оказывается, функция Environment.getExternalStorageDirectory() корректно работает только на старых андроидах (9 и ниже) и только с реальной воткнутой эсди-карточкой. В современных андроидах от встроенной памяти система всё же отщипывает кусок и предоставляет его пользователю, как эмулированную внешнюю память. А я ломился в открытые двери и просил научить, как отщипнуть! Гугл уже позаботился.
Доступ к эмулированной внешней памяти осуществляется функцией new File(String.valueOf(main_activity_ctx.getExternalCacheDir())), где main_activity_ctx -- ссылка на контекст приложения. Может, кому пригодится.
Кроме того, надо разрешать доступ к внешней памяти не из манифеста, а и из кода, и в манифесте разрешить монтировку создаваемых диров.
Что поделать -- самоучка я; на курсах, вероятно, этому учат. :)
Спасибо всем, кто откликнулся.
Петро, какой же я нахрен молодец? МЕСЯЦ разработка топталась на месте. МЕСЯЦ! За такую работу в фирме меня бы точно уволили. Правда, если бы я работал в фирме, то, думаю, у более опытных товарищей быстрее бы нашёл ответ. К чему это я? А к тому, что "Вести" мало читают. Вопреки давнишним высказываниям Питона, ибо посещаемость типа открыл-закрыл - - не показатель.
Впрочем, моральная поддержка "старичков" дорого стОит.
"Недолго музыка играла, недолго фраер танцевал".
Оказывается, система андроид примерно раз в сутки без ведома пользователя чистит кэш приложения в эмулированной внешней памяти. Кэш находится по адресу: /storage/emulated/0/Android/data/имя_пакета_приложения/cache/
Ошибка ли это системы или нет -- не знаю. Ошибка ли это конкретного девайса (p30 light, 10-ка) - - вряд ли, на эмуляторах разных девайсов то же. Свободной памятив в моём девайсе навалом - - более 100 гиг.
Гугл не помог. :(
Кто-нибудь может что-нибудь подсказать? (Ну, кроме "пиши в другое место".)
> getExternalCacheDir()
А чем тебя не устраивает getExternalFilesDir?
О, это я уже давно пробовал. getExternalFilesDir() возвращает путь к каталогу Android/data/data/имя_пакета/, однако работать с этим каталогом система позволяет только моему приложению, т.е. другие приложения (в т.ч. и файловые манагеры) не имеют права туда лезть. Об этом я уже сообщал.
Добавлять же скрытый копипастер в своё приложение, чтобы перекидывать пэдээфы из датакаталога куда-нибудь, не хочется, чтобы не засоряться, да и возиться с отладкой тоже не хочется. Но, возможно, придётся. Now I am исследованинг, отчего может происходить незапланированная очистка кэша. Вот это беспокоит. Неужели ошибка в системе?
Я пользуюсь файловым манагером Amaze, он мне наиболее подходит. Его особенность -- настраиваемая домашняя папка. Вот я настроил её на кэш приложения и в один клик после разных манипуляций с девайсом посматриваю, исчезли или нет мои пэдээфы.
Ахаха.
Написал простейший файловый браузер, чтобы отыскивать свои пэдээфы. Это -- не то приложение, которым пэдээфы записываю. Создаю в браузере ссылку двумя способами:
extStore = new File("/storage/emulated/0/Android/data/com.mike.mysecondprj/cache");
extStore = new File(String.valueOf(this.getExternalCacheDir()));
Первый способ находит пэдээфы, второй -- нет. Неудивительно, так как this.getExternalCacheDir() подсталяет имя пакета браузера, а это -- другое имя. :)
Но почему исчезают файлы в кэше -- Бог (Гугл?) знает. Сегодня пока ни один не исчез.
> Его особенность -- настраиваемая домашняя папка. Вот я настроил её на кэш приложения
Т.е. на кэш его настроить можно, а на /data (без cache) - нет? Странная логика...
> Но почему исчезают файлы в кэше
Ну, собственно здесь как раз логики больше. Кешам и темпам ты не хозяин.
Гхм.... В Android/data/data/имя_пакета/ хранятся жизненно важные для приложения данные -- БД, ини-файлы, временные файлы, повреждение или удаление которых приводят к неработоспособности приложения. Поэтому все файловые манагеры нерутованного андроида показывают, что эта папка пустая. Т.е. настроить-то можно, но ничего не видно. :)
Не совсем так. Темпам, конечно, не хозяин, а кэшам -- хозяин, но не я, а приложение. Иначе зачем кэш приложению?
Кажется, просёк фишку. Но ещё не уверен. Файл из кэша приложения можетбыть удалён системой при условии, что он открыт, а открывшее его приложение, например, файловый манагер, закрыт. Возможно, система считает такой открытый файл мусорным. И если открытый файл ничем не используется, то через некоторое время система удаляет его из кэша. Но это пока рабочая гипотеза.
А вы как думаете?
Мы думаем - а зачем он у тебя открыт?
Ну, посмотрел, что там в pdf-отчёте, и забыл закрыть.
Однако я ошибся. Даже если файл не открыт, но приложение не пользовалось этим кэшированным файлом более суток, то система его удаляет. Вывод: файл после сохранения в кэше надо тотчас же где-то сохранять. Вопрос: где? В некоторых моделях андроидов есть директорий PDF. Вероятно, туда. Но в некоторых моделях этого дира нет. В некоторых андроидах есть дир SHAREit.
Что именно создавать самому?
И есть ли какая-то настройка в андроиде, которая бы предотвращала слежение за кэшами приложений? Или это неотключаемый рудимент, оставшийся со времён, когда памяти было с гулькин нос и чистка кэша была одним из важнейших занятий?
Попробовал копировать pdf-файлы из кэша в директорий /storage/emulated/0/PDF. В эмуляторе всё работает "на ура". В реальном девайсе -- не копирует, хотя все формальные разрешения есть. Похоже, приложение пытается скопировать на реальную эсди-карточку, которой в девайсе нет. Но вот фокус: с помощью манагера Amaze на реальном девайсе могу копировать файлы из кэша в /storage/emulated/0/PDF...
КАК девайс понимает, что /storage/emulated/0/, что это эмулированная эсди, а не реальная физическая?!
Видимо, есть какое-то динамическое разрешение, которое я ещё не вкурил. Буду курить, когда решу навалившуюся проблему: некоторые УСПД дуреют и сдвигают зафиксированные графики нагрузок на полчаса. Т. е. сутки как бы начинаются с последнего получаса прошлых суток. Обратился к изготовителю, он резидент РБ. Оказалось, там об этом знают и знают давно, но не знают причину. Мой заказчик на рогах: может потерять неск. десятков тыс. брб.
Еду на перезапуск, дистанционно исправить не удалось.
Такая вот жизнь.
Графики в УСПД стали на место, однако отвалился субабонент. Оказалось, при считывании настроек УСПД 1-ая строка 2-го ввода субаюонента продублировалась последней строкой его 1-го ввода. Говнософт - - он и есть говнософт. Не я его писал. Писали недавние студенты, которые, точно с тервером не дружат - - ни контрольных сумм, ни CRC. По специальности я связист, а потом уж говнопрогер, но давно усвоил, что данные при передаче по говноканалам могут исказиться. Поэтому никому и ничему верить нельзя.
Вот ещё пример, как юные дарования софт пишут.
Они ставят опрашиваемые девайсы в очередь. Казалось бы, всё норм. Но вот на телефоне висит с десятка полтора девайсов. Софт коннектится с первым, опрашивает и дисконнектится. Потом коннектится со следующим и делает то же. В чём прикол? На опрос - - пару секунд, на коннет-дисконнект - - на порядок больше. Телефонный номер, ессно, тот же. Да только интервал опроса не резиновый. В итоге очередь растёт и в конце-концов возникают потери данных. Но юных дарований это не имеет.
Даже не парятся разбивать очереди на подочереди.
Страницы