Хорошо, по-вашему логично, что у меня есть в проекте arm-v7 библиотека, а Android пытается найти ее х64 версию.
Что бывает очевиднее. И да, это поведение там конкретно не описано.
When installing an application, the package manager service scans the APK, and looks for any shared libraries of the form:
lib/<primary-abi>/lib.so
If none is found, and you have defined a secondary ABI, the service scans for shared libraries of the form:
lib/<secondary-abi>/lib.so
Вот у меня есть secondary ABI, но Android искал только primary.
Тише, тише.
Как я уже сказал, в проекте напрямую не было видно, что используются какие-то другие нативные библиотеки.
О том, что какая-то из подключаемых в Gradle библиотек имеет внутри скомпиленную под arm64 .so'шку, можно было только догадываться.
К тому же, нет возможности указать какую либу использовать, arm64 или arm-v7. По-моему в ситуации, когда есть 5 либ под v7 и одна под x64 (которая в том числе есть и под v7), было бы логичнее сделать fallback на v7, а не пытаться все 5 найти под v7 и не давать возможности изменить это поведение.
Так что давайте не будем тут про понимание устройства ОС.
Самый глубокий кювет для меня был при работе с arm64 девайсом и нативными либами.
Несмотря на то, что все arm64 девайсы могут без проблем юзать arm-v7 либы, приложение крашилось, т.к. по какой-то причине искало именно x64 версию одной библиотеки.
После 3 дней курения проблемы, оказалось, что если у вас в проекте есть хоть одна нативная либа собранная для х64, то все остальные нативные библиотеки андроид тоже начинает искать в папке для х64, и победить это нельзя вообще никак, только если заменить все на х64, либо все на arm-v7.
Прийти к решению было очень непросто, так как напрямую мы подключали только одну нативную библиотеку, о остальные просто втихую использовались какими-то другими зависимостями.
Так и не нашел где такое поведение задокументировано...
Есть ли какая-то причина почему вы используете Otto Bus, вместо шины на Rx?
а "mMvp..." это шикарно :)
Почему все решили, что надо везде фигачить эти префиксы m? Это паттерн для разработки Android SDK. И антипаттерн для всего остального. Даже Гугл об этом говорит.
Какой ужас.
1) Сделайте, пожалуйста, форматирование кода — Ctrl + ALT + L.
2) Книгу лучше найти посвежее
3) Стиль изложения как для людей, которые не то что Андроид, а даже Джаву в глаза не видели. ИМХО, так себе идея начинать изучение сразу с OpenGL. Да и статья такая на Хабре в 2016 году вряд ли приживется, их есть миллион.
Вы не внимательно читали статью. Он виден любому приложению с разрешением android.permission.READ_EXTERNAL_STORAGE об этом я и пытюсь Вам сказать.
Я внимательно читал, просто пытаюсь сделать акцент на том, что таки да, эти данные открыты.
Вы не можете выложить в интернет архив с каталогом /mnt/sdcard(/storage/sdcard) со своего android устройства — посмотрите уже сами на Ваши файлы в директории на Вашем мобильном устройстве, которое Вы используете каждый день.
Да я в курсе, у самого есть файловый менеджер, сам туда частенько заглядываю и сознательно сбрасываю файлы, да и вообще являюсь Android девом и знаю как там все устроено. Просто меня это не сильно волнует, как и в моей настольной системе, например. Не качайте подозрительный софт, да и все…
WhatsApp обещал где-то секюрность этих фото или видео?
Их видно в галерее, файловых менеджерах, плеерах и тд. Если человека это беспокоит, он их удалит, я думаю.
То же самое касается и соц. сетей.
Большинству людей удобен именно такой подход, иначе эти данные скрывали бы.
Если без вашего ведома в открытую хранятся другие данные (переписка, логины, пароли, заметки), то это повод написать разработчику, а не только на хабр. Но я такого не встречал среди своих приложений.
А сам факт, что External SD, который виден по USB подключению, является открытым, по-моему довольно очевиден для хабраюзера, да и для большинства обычных.
С чего вы вообще решили, что getExternalStorageDirectory — место для каких-то временных, да еще и приватных файлов? Это рут директория вашего External Storage, в которой могут читать и писать все, у кого есть права в манифесте.
То, что какие-то ваши мессенджеры туда фигачат свои файлы (пусть даже временные), не говорит вообще ни о чем. Это проблемы (или фичи) их реализации.
Ну код автора заточен под возвращение результата в любом случае. понятно, что если на одни и те же данные могут влиять разные компоненты, то нужно какое-то общее хранилище или возвращение результата из другого компонента. Просто ему это не нужно было, видимо.
В целом, подход интересный, можно подтюнить под свои нужды
Снова введение в RxJava? Какой смысл одно и то же писать? Таких статей уже десятки, с описанием одних и тех же преимуществ и недостатков :)
Лучше сразу писать о более продвинутом использовании Rx, имхо.
Ну, или во всяком случае о чем-то, о чем не пишут на каждом заборе все блоггеры.
Именно так. В Android, например, все битмапы внутри содержат одномерный массив пикселей.
Вы будете удивлены, на сколько быстрее обрабатывается одномерное представление.
Вообще, метод Виолы-Джонса рассчитан на использование в реал тайме, так что вы должны понимать, что ваша реализация уж очень сильно проседает по производительности.
Мне кажется, что это все равно очень плохой результат и стоит смотреть в первую очередь реализацию алгоритма, без привязки к языку.
Что сразу бросилось в глаза — использование двумерного массива для работы с изображением. Это сильный удар по производительности и я считаю, что в таких алгоритмах следует использовать одномерную структуру.
Хоть это и не совсем относится к статье.
Что бывает очевиднее. И да, это поведение там конкретно не описано.
When installing an application, the package manager service scans the APK, and looks for any shared libraries of the form:
lib/<primary-abi>/lib.so
If none is found, and you have defined a secondary ABI, the service scans for shared libraries of the form:
lib/<secondary-abi>/lib.so
Вот у меня есть secondary ABI, но Android искал только primary.
а не пытаться все 5 найти под x64*
Как я уже сказал, в проекте напрямую не было видно, что используются какие-то другие нативные библиотеки.
О том, что какая-то из подключаемых в Gradle библиотек имеет внутри скомпиленную под arm64 .so'шку, можно было только догадываться.
К тому же, нет возможности указать какую либу использовать, arm64 или arm-v7. По-моему в ситуации, когда есть 5 либ под v7 и одна под x64 (которая в том числе есть и под v7), было бы логичнее сделать fallback на v7, а не пытаться все 5 найти под v7 и не давать возможности изменить это поведение.
Так что давайте не будем тут про понимание устройства ОС.
Несмотря на то, что все arm64 девайсы могут без проблем юзать arm-v7 либы, приложение крашилось, т.к. по какой-то причине искало именно x64 версию одной библиотеки.
После 3 дней курения проблемы, оказалось, что если у вас в проекте есть хоть одна нативная либа собранная для х64, то все остальные нативные библиотеки андроид тоже начинает искать в папке для х64, и победить это нельзя вообще никак, только если заменить все на х64, либо все на arm-v7.
Прийти к решению было очень непросто, так как напрямую мы подключали только одну нативную библиотеку, о остальные просто втихую использовались какими-то другими зависимостями.
Так и не нашел где такое поведение задокументировано...
а "mMvp..." это шикарно :)
Почему все решили, что надо везде фигачить эти префиксы m? Это паттерн для разработки Android SDK. И антипаттерн для всего остального. Даже Гугл об этом говорит.
1) Сделайте, пожалуйста, форматирование кода — Ctrl + ALT + L.
2) Книгу лучше найти посвежее
3) Стиль изложения как для людей, которые не то что Андроид, а даже Джаву в глаза не видели. ИМХО, так себе идея начинать изучение сразу с OpenGL. Да и статья такая на Хабре в 2016 году вряд ли приживется, их есть миллион.
Может вообще Android подобное шлет? или Windows, Linux? Или iOS? Ну вы поняли.
Так то можно вообще любого софта бояться…
Я внимательно читал, просто пытаюсь сделать акцент на том, что таки да, эти данные открыты.
Да я в курсе, у самого есть файловый менеджер, сам туда частенько заглядываю и сознательно сбрасываю файлы, да и вообще являюсь Android девом и знаю как там все устроено. Просто меня это не сильно волнует, как и в моей настольной системе, например. Не качайте подозрительный софт, да и все…
Их видно в галерее, файловых менеджерах, плеерах и тд. Если человека это беспокоит, он их удалит, я думаю.
То же самое касается и соц. сетей.
Большинству людей удобен именно такой подход, иначе эти данные скрывали бы.
Если без вашего ведома в открытую хранятся другие данные (переписка, логины, пароли, заметки), то это повод написать разработчику, а не только на хабр. Но я такого не встречал среди своих приложений.
А сам факт, что External SD, который виден по USB подключению, является открытым, по-моему довольно очевиден для хабраюзера, да и для большинства обычных.
То, что какие-то ваши мессенджеры туда фигачат свои файлы (пусть даже временные), не говорит вообще ни о чем. Это проблемы (или фичи) их реализации.
Например, когда передача идет во фрагмент, а не Activity. Может, в этом дело?
В целом, подход интересный, можно подтюнить под свои нужды
Лучше сразу писать о более продвинутом использовании Rx, имхо.
Ну, или во всяком случае о чем-то, о чем не пишут на каждом заборе все блоггеры.
Вы будете удивлены, на сколько быстрее обрабатывается одномерное представление.
Вообще, метод Виолы-Джонса рассчитан на использование в реал тайме, так что вы должны понимать, что ваша реализация уж очень сильно проседает по производительности.
Что сразу бросилось в глаза — использование двумерного массива для работы с изображением. Это сильный удар по производительности и я считаю, что в таких алгоритмах следует использовать одномерную структуру.