Установи другое приложение камеры. Или там баг в прошивке?

УМВР

Samsung Galaxy S4 mini, непорутаный, SD-карточки нет, фотографирует норм. ЧЯДНТ?

Если говорить по честному, то там есть эмуляция SD карточки. Вы не помните, раньше были андроиды с объемом внутренней памяти исчисляемым сотнями, а порой и десятками мегобайт, и там любой медиа-контент - исключительно на внешней SD карте. С тех пор сохранились эти костыли, что даже на современных смартах с 64гб внутренней флешки, эта flash эмулирует примонтированную SD карту.

У меня некие /dev/video* присутствуют. Но вроде как и в настоящем линуксе таким образом фото снять нельзя.

мне кажется, дохлый номер... в libhybris до сих пор не поддерживается камера, куда уж только с рутом в руках...

SD-карточки нет, соответственно штатными средствами снимать на камеру отказывается.

Что-что? Он же должен снимать и без СДшки.

это не костыль. это механизм кастомного разраничения привелегий.

В настройках камеры, внезапно, есть выбор, куда сохранять: во внутреннюю флешку или на сд

У тебя есть встроенная память (вроде 4 Гб). А у ТС ни встроенной ни SD-карты

у ТС ни встроенной

ТС об этом не говорил.

А у ТС ни встроенной ни SD-карты

Это как? А корень где?

Посмотрите на исходники демона «sdcard», который посредством FUSE и рукодельных извратов эмулирует FAT-подобное поведение поверх ext3, а именно - отсуствие прав доступа на файлах и case-insensetive имена. Если это не костыль, что это?

Попробуй еще раз перечитать то что я написал:
«это механизм кастомного разраничения привелегий»

Это как?

Как было на ведроидах с 1.х и на некоторых 2.х. Пол гига памяти под ось и data, а sdcard монтировался только при подключении настоящей карточки.

Так это же значит, что есть полгига встроенной памяти под rootfs. А сказано было «нет ни встроенной, ни внешней карты».

В старых ведроидах нет костыля, монтирующего /sdcard из этой памяти. А без /sdcard не работает приложение камеры.

ТС я бы посоветовал руками смонтировать sdcard на встроенную память, благо рут есть.

руками смонтировать sdcard на встроенную память, благо рут есть.

вот причитал и вспомнил мучение с xperia zr своей, где ни один foldermount не работает. почему такое может вообще быть никак не могу понять, ведь смонтировать sdcard в любое место можно при наличии рута? а еще проще симлинк сделать. до сих пор не могу понять почему на икспериях это не работает.

Это когда все подряд могут писать на карту, - это называется «разраничение»?

вспомнил мучение с xperia zr своей

Там ведь проблема в том, что пользовательский (/data) раздел небольшой? Я просто как раз присматриваюсь к zr. А почему бы просто не создать на карточке отдельный раздел и монтировать (добавить скриптик в /etc/init.d, кажись такой путь...) его в /data? У меня на lg p500 такое прокатывало на ура.

Как вообще впечатления от него? Какие есть +/-? Все на экран плюются. Так ли он плох?

Там ведь проблема в том, что пользовательский (/data) раздел небольшой?

Не разбирался подробно еще, лень было, но т.е. софтины, которые работают на других аппаратах тут не работают. А из 8Гб пользователю доступно 4 после вайпа на стоке, т.е. тяжелую игрушку, где кэш 8Гб ну никак не поставишь.

Как вообще впечатления от него? Какие есть +/-? Все на экран плюются. Так ли он плох?

Впечатления отличные в принципе. Плюсы:

1. Аккум держит 2-4 дня очень бодро. Хотя я сёрфингом по 5 часов не занимаюсь. У меня 1 час разговоров + 1 час навигации в день.

2. можно помыть с мылом, когда заляпается.

3. довольно шустрый. у меня ничего не лагает на 4.2.2

минусы:

1. надпись сони на пленке. так что когда зацарапается, то после замены надпись сони уйдет. ну или с двумя пленками жить.

2. рут нормально только на 4.2 получается и довольно много гемора его сохранить при переходе на 4.3 и 4.4. я пока на 4.2 сижу и не жужжу ибо лень гемороится, а от 4.3 и 4.4 мне ничего не надо.

3. миньон раш немножко лагает. даже не лагает, а плавности нет. но это единственная игра что лагала. может потому что я не геймер и на телефоне играю только в карты.

4. ну и главный минус это 8Гб основной памяти и невозможность(слишком сложно и с глюками вроде можно. нужно поменять местами КП и вн. память) переноса приложений на карту.

А по экрану меня устраивает всё. Сравнивал с Z1 Compact у друга и не заметил особо большой разницы. Кстати на Z1C у друга за неделю задняя крышка вся в мелких царапках, а у меня с февраля всё нормально.

Правда под мою руку 4.3" в Z1C приятнее, чем 4.5" у ZR. Пример: Задеваю в номеронабирателе звездочку, когда тянусь в правый верхний. Но это у кого какие руки и какое использование(я противник держания смарта 2мя руками).

Спасибо за отзыв.

Сравнивал с Z1 Compact

А на нем он должен быть лучше? Мне казалось что там на всей линейке Z* что-то вроде TN и поэтому народ плюется.

А на нем он должен быть лучше?

На Z1 Compact IPS экран. Инфа 146% :)

Но он дороже на 8тыс. ZR можно РСТ взять за 12тыс. в связном, а z1c не дешевле 19тыс. будет.

А за что такая переплата? Что там кроме экрана лучше?

А за что такая переплата? Что там кроме экрана лучше?

Ну как минимум за снап 800й можно переплатить и за 16Гб вместо 8ми. Ну и за то что это этого года аппарат и обновляться будет еще год как минимум, а zr последнее обновление сейчас 4.4.2 уже получил(максимум 4.4.3 будет).

Ну так есть Cyanogenmod... Интересно, а кто-нибудь ubuntu phone на него вкорячить пытался?

Ну так есть Cyanogenmod

Как по мне так циан это для юношей с горящими глазами, а мне даже софт уже по форумам лень искать и я жмякаю «купить» в гуглоплее не от честности, а от лени.

Для зетки есть прошивка, может и для zr где найдется. Хотя работой назвать сложно, т.к. звонки не работают.

http://4pda.ru/forum/index.php?showtopic=567787

Давай не задалбівай уже. Просто попробуй посмотреть в файл system/core/sdcard/sdcard.c - ты поймешь о чем я. Ну хотя бы прочти коментарий с 66-ой по 89-ую строчку, че уж там код-то.

Как маленькие, ей богу.

Это все появилось только в 4.3. Изначальная, и до сих пор основная функция sdcard - костыль

и снова фейл.
До 4.3(а точнее 4.4) демон сдкард использовался только для эмуляции сторейджа на eMMC, все остальные сторейджы были как есть. И при этом, на самом деле, его можно было не использовать, а иметь на eMMC(или чего круче, на реальной sd-шке) отдельный раздел отформатированный в FAT. Да и вообще, технически небыло никаких препятствий что бы не использовать его вообще. А вообще фьюз клевая тема.

eMMC, все остальные сторейджы были как есть

Вам лишь бы поспорить, не важно о чем? :-) изначально речь только о emmc и была.

иметь на eMMC(или чего круче, на реальной sd-шке) отдельный раздел отформатированный в FAT

Тут как раз две проблемы: 1. Патенты на FAT. 2. Неэффективное использование места. Если в телефоне скажем 64г встроенной памяти, то сколько отдавать на /data, а сколько на /sdcard? А потом юзеру ещё объяснять, почему у него 64г, а места на то, что бы приложение поставить - нет.

ЗЫ я в своё время на sdcard собаку съел, во времена 4.1 это был вообще полный ахтунг, из за которого все дико тормозило, т.к. работал он в один поток в 4.1, и если там шифрование включить, то вообще, тормоза дикие при работе с картой http://habrahabr.ru/post/180985/

Глупости.
Ман фьюз и не говорите глупостей про «в один поток». Вероятно собака у вас біла протухшая, либо то циганщина...
Партиционировние очень косвенно описано в СДД. Но вообще дата єто всегда то что осталось от остальніх разделов... А сдкард так вообще симлинк.

Ман фьюз и не говорите глупостей про «в один поток». Вероятно собака у вас біла протухшая, либо то циганщина...

Самсунговская стоковая прошивка. Сам fuse - конечно умеет много потоков, но сам демон sdcard... А он до 4.2 был одно-поточным. Не верите - смотрите исходники: https://github.com/android/platform_system_core/blob/jb-mr0-release/sdcard/sd... :

void handle_fuse_requests(struct fuse *fuse)
{
    unsigned char req[256 * 1024 + 128];
    int len;
    
    for (;;) {
        len = read(fuse->fd, req, sizeof(req));
        if (len < 0) {
            if (errno == EINTR)
                continue;
            ERROR("handle_fuse_requests: errno=%d\n", errno);
            return;
        }
        handle_fuse_request(fuse, (void*) req, (void*) (req + sizeof(struct fuse_in_header)), len);
    }
}

и конец main:

    fuse_init(&fuse, fd, path);

    umask(0);
    handle_fuse_requests(&fuse);
    
    return 0;
}

-- после того, как я туда забэкпортил sdcard из 4.2, оно у меня летать начало просто (т.е. опять-же на стоке от самсунга). Альтернативными прошивками, как на базе стока, так и CM - на том SGS3 никогда не пользовался, ибо все кривое.

.... а просто симлинком /mnt/sdcard не может быть, без FAT или FUSE, т.к. приложения поломались бы.

И что? Это не отменяет того что решение с фюзом самон простое и очевидное решение. Назвать его «костылем» может только профан, не понимающий сути процессов происходящих в системе. Ну а то что многие(особенно самсунг) экономят на хорошей еММС даже для топовых девайсов уже давно не секрет.

И что? Это не отменяет того что решение с фюзом самон простое и очевидное решение. Назвать его «костылем» может только профан, не понимающий сути процессов происходящих в системе. Ну а то что многие(особенно самсунг) экономят на хорошей еММС даже для топовых девайсов уже давно не секрет.

Знаете, мне тогда, back in time, было пофиг - как оно реализовано. Но когда любое приложение, читающее с внутренней карты, дико тормозило, и порой запускалось по 2-3 минуты, если фоном работал Media Scanner (а в нем тоже был баг, и он постоянно что-то сканировал), — то пофиг, как оно реализовано внутри, это однозначно кривая дико-тормозящая реализация. И дело тут не в медленной eMMC, а в кривой архитектуре sdcard (к FUSE как таковому - у меня нет претензий). И как-то пофиг, что кто-то может это считать «самой простой и очевидной реализацией» — если это неимоверно тормозит - то простота - не главное.

Если вам не понятно, объясню по подробнее, в чем проблема:

sdcard в андроиде, до 4.1 включительно - одно-поточный. Это значит что есть 1 поток, который читает все запросы, обрабатывает (т.е. читает или пишет нужные данные с реальной FS где-то в /data/media), и отдает результат.

Проблем тут сразу несколько: во первых такая реализация - не использует все возможности железа, если чтение затрагивает не только собственно чтение с eMMC, но и какую-то нагрузку на CPU (шифрование раздела в моем случае). Вторая проблема - это то, что все запросы от всех-всех-всем приложений складываются в одну общую FIFO. В «обычных FS» каждый процесс может, посредством системного вызова, обратится к драйверу FS независимо от того, кто к нему обращался из других контекстов, и сколько раз. FIFO реализация плоха тем, что если в очереди окажется много тяжелых запросов от одного приложения (которое может с*ать их в несколько потоков), то другому процессу, даже если понадобится прочитать всего 10 байт с карты, прийдется ждать пока sdcard обработает в 1 поток все запросы, что были получены до этого. А это, на практике, оказалось жуууутко медленно. Я не теоретизирую, я с этими багами сам столкнулся и жутко натерпелся от них.

Много-поточная реализация, что появилась в 4.2 и позже, частично решает эти проблемы, но проблема с FIFO все равно может появится, просто по стечению обстоятельств - не проявляется (обычно в системе не так много параллельных потоков, которые бы одновременно интенсивно что-то бы читали и писали).

Остановись уже, теоретик. У меня 2 года был Motorola Razr, вместе с ним я прошел процесс апгрейда с GingerBread 2.3.4 до JellyBean 4.1.2. В последнее время я использовал самосборный 4.2.2 (АОСП + минимум патчей, плюс доделок по мелочам).
И знаешь что? Ни разу ни одно приложение у меня не запускалось по 2-3 минуты. Тоесть вообще никогда. Как игрушки так и простой софт. Да бывали подтормаживания, с кем не бывает. Но это еденицы секунд, а не десятки-сотни. А уж более засраной прошивки чем у моторолы сложно представить, с их то количеством сервисов и «улучшений»(зондов).

Шах и мат теоретик.

p.s. про FiFo поржал.

Я ещё раз повторяю. Это не теория. Я видел все эти тормоза живьем, и очень от них настрадался. У вас их не было возможно по тому, что не используете шифрование и может у вас было не так много медиафайлов на карте (у меня их были десятки тысяч, благодаря AnkiDroid). Про fifo можете ржать дальше. Если найдёте в sdcard времён 4.1/4.2 асинхронную обработку запросов, я вам 3 бутылки ирландского виски пришлю.

P.S. как я уже писал выше, я в своё время вылечил эти тормоза дикие на 4.1 путём бэкпорта sdcard из 4.2: https://github.com/quarck/csetup/tree/master/sdcard/jni - попутно прикрутил возможность насильно не давать доступ к некоторым каталогам некоторым процессам, т.к. media scanner игнорирует .nomedia файлы.

Да, а что касается вопроса разграничения прав - это все можно было сделать куда проще стандартными средствами Unix/Linux. Главная цель sdcard - это именно эмуляция стораджа похожего на FAT.

Это не проблемы устройства то что ты его юзаешь через Ж. в смысле десятки тысяч медиа файлов это не то, для чего делался смартфон.

Т.е. смартфоном нужно только звонить и смски набирать, а приложений никаких ставить не стоит? Медиа-файлы были в каталоге ресурсов приложения AnkiDroid, куда по хорошему media scanner вообще не должен был заглядывать. Т.е. все мое «использование через Ж» свелось к тому, что поставил приложение, которое скачало тонну ресурсов в каталог, в который никто другой вообще не должен заглядывать.

Вам спорить не надоело? И что там с асинхронной отработкой в sdcard, мне идти за виски в магазин?

Впрочем вы начали переходить на личные оскорбления, не считаю разумным вам больше что то отвечать.

Я не пытаюсь никого оскорблять. Просто у любой технологии и решения есть свои ограничения и целевые сферы применения. И их нужно понимать. Идеальных устройств не существует, да и необходимости в них нет. Вы пытаетесь вот уже который пост мне доказать что эти криворукие американцы даже нормально разрулить вопросы с <перечень косяков> не могут. Я же пытаюсь вам пояснить что у каждой технологии/решения есть свои плюсы, минусы и специализации.
Вы говорите «фьюз однопоточный - какой ужас», а я говорю что он однопоточный только в контексте одного ядерного процесса(он же тред), а так как логика нормального приложения подразумевает не больше нескольких потоков связанных с одним тредом/процессом плюс асинхронность и блаблабла, то в этом и правда ничего страшного нет в большинстве случаев.
Вы говорите «ИО в фифо - айайайай», а я говорю что никаким «фифом» там и не пахнет, в зависимсоти от версии ядра у вас как минимум 3 пранировщика ИО операций в ядре, и каждый из них немного умнее(или много) чем обычный фифо, а ещё кеширование.

Главная проблема с sdcard в том, что он решает искусственно созданную проблему, которой могло бы не быть. Но т.к. приложения уже рассчитывают на fat-подобное поведение, то нужен этот костыль.

А про планировщики ввода-вывода - вы путаете тёплое с мягким, т.к. все эти планировщики работают на уровне блочных устройств, а FUSE не опускается ниже уровня VFS. Я по этому вопросу копал ранее код fuse - там fifo очередь запросов чистой воды.

Посмотрите например на первоисточник:

https://android.googlesource.com/kernel/common/ /android-3.4/fs/fuse/file.c — например часть fuse, отвечающую за непосредственно обработку запросов на чтение конкретных файлов. Например рассмотрим чтение из файла. Тут много точек входа, которые могут быть вызваны, в зависимости от используемого ядром интерфейса:

* fuse_file_aio_read * fuse_direct_read * fuse_readpage * fuse_direct_IO

(в различных *ops структурах упоминаются еще функции do_sync_read, generic_file_splice_read, и еще некоторые - это все стандартные ядреные функции, они в конечном итоге дергают одну из вышеупомянутых).

Теперь что присходит дальше, в каждом конкретном случае:

* fuse_file_aio_read — после пары проверок дергает стандартную функцию ядра generic_file_aio_read, которая будет реализует AIO посредством оставшихся функций.

* fuse_direct_read - передает запрос ниже, в fuse_direct_io (обратите внимание, там 2 разных фунции - с _io и с _IO, первое - внутренняя функция, второе - внешний интерфейс). fuse_direct_io далее создает request под данный запрос (через fuse_get_req, реализованную в https://android.googlesource.com/kernel/common/ /android-3.4/fs/fuse/dev.c), и далее, для случае операции чтения - передает все это дело далее во внутрь fuse_send_read. (стоящий fuse_put_request в конце fuse_direct_io на самом деле занимается только освобождением памяти, и к обработке запросов не имеет отношения). Далее fuse_send_read заполняет все поля запроса и дергает fuse_request_send, который опять-же реализован уже в dev.c, и все что он делает - это кладет запрос в конец очереди запросов (вызовом queue_request), и вызывает функцию request_wait_answer, которая дожидается ответа. На этом сделаем паузу, посмотрим что делают другие функции.

* fuse_direct_read - сразу вызывает fuse_direct_io, а дальше - все аналогично предыдущему случаю.

* fuse_readpage - после нескольких vm-специфичных операций, дергает fuse_send_read, а дальше - опять-же все аналогично первому случаю.

* fuse_direct_IO - передает запрос в fuse_loop_dio, откуда оно идет далее в fuse_direct_read, откуда вызывается fuse_direct_io и дальше - аналогично предыдущему первому случаю.

Т.е. все пути ведут к тому, что создается запрос, и посредством queue_request (из https://android.googlesource.com/kernel/common/ /android-3.4/fs/fuse/dev.c ) кладется в _КОНЕЦ_ очереди. Всегда в конец (что важно для данного рассмотрения).

fuse демон общается с кернельной частью посредством устройства в /dev, ядреная реализация которого собственно расположена в том dev.c. Когда демон читает из устройства, вызывается fuse_dev_do_read, сначала дожидается запросов от ядреной части, посредством request_wait, и далее достает из очереди запрос и отдает в userspace. Тут немного запутанная логика, сначала все запросы перекладываются в конец очереди interrupts, и потом уже оттуда по одному достаются, но суть не меняется - запросы в итоге достаются по одному из НАЧАЛА очереди. Далее - все зависит от того, как userspace часть отработает, и если userspace часть реализована строго последовательно «прочитать, обработать, вернуть», как это сделано в sdcard, выходит обычный FIFO. Как видите, никакой планировщик ввода-вывода не вмешивается в то, в каком порядке fuse обрабатывает запросы.

Как мне кажется, основная проблема это то как сделать доступными для приложений, которые фактически живут в некотором подобии сандбоксов, вот такой вот шареный сторейдж. Да еще и сохранив при этом обратную совместимость. Хотя я склоняюсь к мнению что это «на самом деле» именно для обратной совместимости.

Я подразумевал именно блочное ИО, т.к. от скорости и политики его работы напрямую зависит скорость выполнения запросов через фюз. Я не очень в курсе что там внутрях самого фюза(ну теперь уже в курсе, спасибо), однако моя мысль заключается именно в том, что ключевое условие быстрой работы быстрое(или оптимизированное) ИО именно на блочном устройстве. В одном из проектов (кстати как раз на 4.1) замена eMMC на самый обычный SSD дала просто многоразовый прирост производительности. Именно на этом основывается мой личный опыт достаточности фюзового демона для среднестатистической работы, и недостаточности его в специальных условиях.

Как мне кажется, основная проблема это то как сделать доступными для приложений, которые фактически живут в некотором подобии сандбоксов, вот такой вот шареный сторейдж. Да еще и сохранив при этом обратную совместимость. Хотя я склоняюсь к мнению что это «на самом деле» именно для обратной совместимости.

Ну об том и речь, что это все обусловлено изначальной архитектурой - приложениям был дан общий сторадж, отнимать не хорошо — все сломается. А так, архитектура андроида вполне позволяет вообще обойтись без общего стораджа, если бы об этом заранее позаботится. Для этого нужно для каждого типа данных - иметь свой content provider, как это сейчас делается например для контактов — контент провайдеров контактов может быть тонна (контакты с гугла, контакты со скайпа, контакты с фейсбука), но все это выглядит как один общий список по категориям в звонилке или любой другой программе, работающей с контактами. Тоже самое можно сделать и вообще с любым типом данных, - картинками, музыкой, итп. Тем более что большинству пользователей абсолютно пофиг, где и как внутри хранятся медиа-файлы, главное что их видно в галерее/плеере/итп.

Конечно работа с файлами как-то проще, да и историческое наследие - в первых андроидах была очень маленькая внутренняя флешка, и для любого медиа-контента использовалась внешняя SD. Так что повелось уже так, что есть общий сторадж, куда все могут писать и читать, приходится его эмулировать. (ЗЫ - вообще в плане производительности, можно было-бы вместо модуля sdcard написать патч к ядру, позволяющий по аналогии с «mount -o bind», делать некий «mount -o flatbind», но такой, что в новой точке монтирования игнорировались бы права доступа и регистр имен. Тогда при работе с файлами было-бы в разы меньше оверхеда. Хотя конечно отлаживать такое решение пришлось бы чуть дольше).

Можно предложить и чисто unix-овое решение, которое правда не даст регистро-независимости, но плоские права доступа - обеспечит: сделать /mnt/sdcard - обычной ext3, но написать небольшого демоненка, котрый через inotify слушает уведомления о создании новых файлов и каталогов в /mnt/sdcard, и при создании любых новых файлов - сразу-же делает им chmod 777. Оверхеда от такого демоненка было-бы в разы меньше, чем от sdcard, и отладка его - заняла бы совсем ничего. Но проблема в том, что нужны не только плоские права, но и FAT-совместимая обработка имен, т.к. регистронезависимость. А это уже свидетельствует о том, что sdcard - именно для эмуляции :)

Вот в последнем абзаце ты и изложил одни из основных проблем, которые препятствуют использованию любой продвинутой файловой системы. А ещё опыт медиа сканера явно подсказывает, что «обпровайдерить» совсем весь контент это реально не очень хорошая идея. Во-первых потенциально куча дыр, во-вторых сложность кода возрастает в разы, в третьих все те же проблемы с перфомансом. Упомянутый тобой костыль с 0777+демон это куда «круче» чем фюз, т.к. фюзовый сервис хотя бы дает возможность минимально разграничивать права для групп media_rw, sdcard_r(rw), а так же отфильтровывать «служебные» каталоги.

В сказки про патентный тролинг я тоже не верю, так как всеравно все платят МСу все за тот же фат. В ближайшем релизе увидим, если на ф2фс перейдут то может и не сказки.

Но в одном ты прав на 100%: sdcard - именно для эмуляции.