Как победить Андроид
Продолжение и окончание...
В прошлой серии: у нас не работали сокетовые fd, когда мы их возвращали в качестве источников для прочтений html-файлов. Работали только fd от обычных файлов.
В чем была причина: неправильная реализация android.os.MemoryFile.native_get_size, которая делала нестандартный ioctl для данного дескриптора и ожидала -ENOTTY для любых дескрипторов, которые не являются андроид-специфичными ashmem-дескрипторами. Однако -ENOTTY ядро возвращает только для обычных файлов (fs/ioctl.c в ядре). Для дескрипторов других типов обычно возращается естественно ожидаемое -EINVAL. Почему в fs/ioctl.c возвращается -ENOTTY по дефолту - вообще тема для отдельных исторических изысканий. Тем не менее, эта самая функция native_get_size ожидала -ENOTTY, а если нет, швыряла IOException, и на этом всё кончалось.
Как проблема была решена: эта самая злополучная функция native_get_size является native-функцией и реализована через jni. Так что через jni же мы просто перерегистрируем эту функцию на свою собственную, корректную реализацию. Всё начинает работать.
Будет ли это работать на Андроидах всех версий: очень хотелось бы в это верить :) Но все другие варианты - сводятся к созданию временных файлов. При том, что, судя по опытам, какой-либо смонтированный для публики tmpfs в Андроиде доступен далеко не всегда. Кто хочет истирать себе флешку мусором?
p.s. Да, как мы видим, Андроид - офигенно низкоуровневая система, где dalvik - это просто запускалка нативного кода. А дальше у нас ядро, системные вызовы и всё-всё-всё - притом непосредственно доступное любой программе.
В прошлой серии: у нас не работали сокетовые fd, когда мы их возвращали в качестве источников для прочтений html-файлов. Работали только fd от обычных файлов.
В чем была причина: неправильная реализация android.os.MemoryFile.native_get_size, которая делала нестандартный ioctl для данного дескриптора и ожидала -ENOTTY для любых дескрипторов, которые не являются андроид-специфичными ashmem-дескрипторами. Однако -ENOTTY ядро возвращает только для обычных файлов (fs/ioctl.c в ядре). Для дескрипторов других типов обычно возращается естественно ожидаемое -EINVAL. Почему в fs/ioctl.c возвращается -ENOTTY по дефолту - вообще тема для отдельных исторических изысканий. Тем не менее, эта самая функция native_get_size ожидала -ENOTTY, а если нет, швыряла IOException, и на этом всё кончалось.
Как проблема была решена: эта самая злополучная функция native_get_size является native-функцией и реализована через jni. Так что через jni же мы просто перерегистрируем эту функцию на свою собственную, корректную реализацию. Всё начинает работать.
Будет ли это работать на Андроидах всех версий: очень хотелось бы в это верить :) Но все другие варианты - сводятся к созданию временных файлов. При том, что, судя по опытам, какой-либо смонтированный для публики tmpfs в Андроиде доступен далеко не всегда. Кто хочет истирать себе флешку мусором?
p.s. Да, как мы видим, Андроид - офигенно низкоуровневая система, где dalvik - это просто запускалка нативного кода. А дальше у нас ядро, системные вызовы и всё-всё-всё - притом непосредственно доступное любой программе.