Почитал ветку. Попробую дать наиболее корректный ответ.
Rx (если говорить об RxJava) не только про реактивщину, но еще и про функциональщину.
Функциональный подход имеет свои преимущества и недостатки в равной степени с другими. Если Вам функциональный подход больше нравится- то да, возможно, LiveData Вам использовать смысла нет.
Зато LiveData хорошо стыкуется с корутинами (которые, на сегодняшний день, являются рекомендуемым подходом к построению многопоточности). Такая связка хорошо укладывается в императивный или декларативный стиль.
Сам имел опыт работы с приложениями, построенными на Rx (включая mvp на rx). И связка Android Architecture Components + корутины, на мой личный взгляд, имеет больше преимуществ.
Тоже так подумал. Единственный минус interceptors для такого функционала в том, что там нужно реализовать синхронизацию в 2х или 3х местах, чтобы не пустить запросы из параллельных потоков до конца процессов установки/обновления токенов. При этом еще не получить deadlock.
Так что в целом interceptors- более правильный вариант, но требует больших знаний о многопоточности
Как уже наверное многие догадались, у Асуса вздулась батарея
Примерно по этим причинам Turbo Boost на маках всегда отключен по умолчанию (включить можно только через сторонние утилиты). Да и система охлаждения ни на виндовых ультрабуках, ни на макбуках (включая Pro) с ним толком не справляется. Температура под корпусом растет, ну и, чаще всего, первым под удар попадает аккумулятор.
А вот на игровых виндовых моделях с этим более-менее всё в порядке. У самого личная рабочая машина- Asus ROG GL552. Был куплен в конце 15 года и стоил в 2 раза дешевле его ближайшего яблочного аналога 16 года. Всё, что с ним делал за это время- менял SSD на более емкий и добавлял RAM так как Android Studio в 8гб на жирных проектах было уже тесновато (с учетом системы, кучи вкладок хрома и прочего ПО).
При этом имею опыт работы с MB Pro 17 и 18 года. И ни о чем не жалею- производительность либо примерно та же, либо быстрее (если говорить об Android Studio и Unity), так что покупка себя оправдала.
Само собой минусы тоже есть. При большой нагрузке он весьма горяч. Решение- завести режим энергопотребления с отключенным Turbo Boost и работать в режиме «макбука»- тихо и холодно, но всё еще достаточно быстро. Ну а когда надо быстрее- переключить режим.
Ну и вес- 2,5 кг. Всё-таки это не ультрабук. Но для меня не критично.
В остальном- проблем нет ни по качеству ни по производительности. Но уже задумываюсь о замене по-мощнее так как в ближайшие пару лет, скорее всего, этого хватать перестанет.
Так что
покупая топовый Асус, возможно стоит хотя бы рассмотреть вариант — а не добавить ли еще немножко и купить МакБук?
Зависит от задачи и от количества итогового платформозависимого кода.
Проблема задачи в том, что RN и Flutter основаны на подходе bridge-коммункации. Сам по себе этот bridge зачастую медленный. Он достаточно быстр для взаимодействия с большинством компонент, но при большой нагрузке может стать бутылочным горлышком.
Плюс если есть требования к размеру приложений (например, нужен Instant Apps) или к его взаимодействию с пользователем (например, управление на Apple TV и Android TV), то кроссплатформенные фреймворки сегодня не смогут предоставить подходящего решения.
Проблема в количестве платформозависимого кода состоит в том, что если его доля в проекте переваливает за 40-50%, то встает вопрос о надобности кроссплатформенного фреймворка в принципе. Соотношение время-деньги-качество получается уже не таким вкусным в сравнении с нативной разработкой. То есть две команды нативных разработчиков обойдутся дороже, но с реализацией справятся быстрее, а итоговое решение будет более отзывчиво себя вести и (при желании заказчика) соответсвовать гайдлайнам (что позволит привлечь или удерживать часть аудитории за счет привычного UX).
В итоге время здесь часто более важный фактор чем деньги. Раньше выйдешь на рынок- отхватишь больший кусок.
Это было бы не совсем корректно. React Native и Flutter позволяют создавать приложения от начала и до конца, включая UI и его поведение. Kotlin Multiplatform хорош для общей бизнес-логики для нескольких платформ, но UI и UX реализации ему нужны сторонние. Например, нативные или интеграция с Flutter
Потому CameraView deprecated. Смотрите в сторону CameraX (как и указано в readme) или в сторону Camera2 API. Там тоже, конечно, есть свои проблемы, но эти инструменты производительнее и более гибкие
Стоило бы уточнить, разблокирован ли загрузчик, сняты ли с него доп.защиты и версию ОС. В дефолтном виде не должно такого быть, иначе- недоработка прошивки. В nokia, htc, samsung на 7, 8 и 9 версиях Android такого не наблюдалось.
Не прекрасно. Социнженерию никто не отменял. Приложение может обмануть пользователя обоснованием root-запроса. Вроде «разрешите доступ для возможности записи Ваших звонков» в приложении- рекордере. И может даже честно начнет записывать разговоры. Заодно, под шумок, шариться по кешам банков и токенам аккаунтов, или выставит корневой сертификат и будет пропускать через себя весь траффик.
В современном мире само наличие легального root в смартфоне- уже дыра. Поскольку нельзя доказать функционал ПО кроме как посредством ревью исходников, что никому нафиг не надо.
Сложно, но именно для ART есть рабочие PoC
Эти PoC работают для одной конкретной версии ПО. С учетом неравномерности и интенсивности обновления- массово их применять не выйдет. Пример- Lucky Patcher.
Положим, что такие разделы не содержат файловой системы
Ага, только recovery их монтировать умеют, а вендоры иногда выводят в них регистры в ФС. Вообще было приведено в качестве примера вариантов вектора атаки на загрузчик.
не понимаю, почему важен запрет записи в system и служебные разделы, если есть root и открыта запись в /data
Очень просто- песочница приложения замыкается на Android Framework. В том числе с точки зрения ФС. В случае даже при наличии root ФС будет выдавать пустые каталоги чужой песочницы, а так же отказывать в записи. Помните, что linux-ядро Android крайне сильно модифицировано, за счет этого и достигается такая стратегия.
В итоге при наличии root нужно еще эскалировать приложение посредством добавления OEM-подписей, регистраций и прочего в System. Что, при запрете на запись без возможности перемонтировать благодаря загрузчику, не возможно. Опять же напомню про вендорские системы защиты поверх OEM-блокировки вроде HTC Boot Security или Samsung KNOX.
Так что всё просто. Хотите безопасности- покупайте белый аппарат бренда первого эшелона и не трогайте загрузчик. И в ином случае самой главной дырой в системе становитесь Вы сами.
Почему? Почитайте внимательно- звонилка из AOSP в Android One. Да, неудаляемая, но это- правильно. Ибо у пользователя всегда должен быть как минимум 1 вариант, который сможет принять звонок или принять.
Орать действительно не надо. Но, весьма вероятно, тоже конфликт.
Заказчик может зареквестить «вот эту фичу, и я принимаю проект». И так раз десять. Таким образом получая больше работы за те же деньги. И подписанное ТЗ часто не спасает так как очень абстрактно.
Конечно возникает конфликт заказчика и аутсорсера, в котором на кону два самых ценных ресурса- деньги и время. Первый хочет больше времени по-дешевле, второй- наоборот.
Мне такая идея тоже больше нравится. Оставить фреймворк и пару нужных приложений (вроде маркета и почты). Всё остальное- доустановить по желанию. В Android One сейчас так и происходит- из сервисов на старте только сам фреймворк, ассистент, почта, маркет, youtube, карты, play музыка (в качестве системного плеера), фото (в качестве галереи) и всё. Часы, звонилка и прочее- стандартные AOSP.
А где их нет? В AppStore тоже и зловреды и мошенники. Цифровую гигиену нигде никто не отменял. Но установка только из маркета снизит риски этак на 90%.
Root же раздается посредством менеджера прав типа Super SU. Он обходится эксплоитом либо для него самого, либо для загрузчика, либо для SOC (MTK). С двумя последними вариантами ситуация за пару лет стала сильно лучше. Потому использовать их сейчас массово не получится.
получает root-права независимо от того
Верно, зато сторонние приложения могут понять, можно ли такой эксплоит применить и был ли он применен путем попытки эскалации прав и анализа ФС в system на предмет опасных бинарников или настроек. И, в случае обнаружения, отказаться работать. Код, который реализует 90% из этого, состоит из ~20 строчек)
кеш jit-компилятора (откуда, собственно, код и исполняется), всё равно в /data — его и надо защищать
JIT в Android повсеместно не применяется начиная с 5й версии. В последнем его вернули ради того, чтобы запуск после установки был быстрее. Но далее работает прекомпайл. Так что искать что-то в кэше JIT нет смысла с учетом того, что 4й андроид сегодня вымирает. Что может интересовать, так это БД, shared preferences, данные аккаунт-менеджера и криптоконтейнеры.
Забыл написать, что в read only монтируется не только system, но и другие системные разделы- boot, kernel, radio и тд. Чтобы прочитать данные другого приложения, не достаточно получить root-права. После их получения нужно себя эскалировать в системе путем изменений в ФС system (или других разделов, зависит от вендора. против подобного у HTC работает S-ON). И вот это на современных загрузчиках сделать сложно, так как при применении эксплоита запрет на запись всё равно не отменяется
Да, верно. Характерно для MTK и Exynos старых ревизий и со старыми загрузчиками. С новыми от A-брендов ситуация сильно лучше. А у Snapdragon массовых уязвимостей подобного рода и не было. А если не хочется, чтобы установленное ПО перебирало эксплоиты в фоне- ставьте приложения из маркета
Только вот при наличии root нет возможности гарантировать, что одни приложения не получат доступ к данным других. Речь не о фото-видео, а о токенах, аккаунтах, базах данных. Неприятно будет, если у Вас, внезапно, спишут все деньги из банка потому, что у Вас была установлена, например, китайская игра для ребенка, которая обошла эскалатор прав, получила root без спроса и стянула все банковские кеши и потроха соседнего приложения банка.
Менеджерами прав не решается- они обходятся пусть и с разной степенью сложности. Выход- монтировать /system как read only, чем и занимается заблокированный загрузчик.
Потому многие приложения, имеющие отношение к финансам или другой более-менее важной информации, отказываются работать при наличии root. И потому это более чем обосновано.
предустановлен malware
Скорее всего будет возможность обратно заблокировать загрузчик. Разблокировать, установить мэнеджер, внести коррективы, удалить мэнеджер, заблокировать. Но когда malware в system- либо у Вас MTK старой ревизии, либо производитель, который наверняка позаботился о ресторе. Лучше уж сменить смартфон чтобы без повторений. Любой белый аппарат от любого известного бренда (кроме Xiaomi на MIUI- там даже на белых аппаратах есть дыры).
А для пользователя? Play Services отвечают за канал push-уведомлений, за точную и энергоэффективную работу местоположения и вообще много чего.
Разрабы приложений могут это сделать, конечно, своими силами. Только разработка будет стоить сильно дороже и садить батарею будет сильно больше.
В AOSP это всё тоже нельзя ибо пакет проприетарный и надо контролировать установку чтобы обеспечивать безопасность. В конце концов, сервера FCM и прочие оплачивать тоже надо, на что уходят деньги с установки на девайс.
Итого- выпиливать нельзя. Достойных аналогов нет и в Play Servises самый востребованный функционал.
Перед большинством современного «земного» софта стоят задачи сильно сложнее, чем слетать на луну. Так что 4K ОЗУ на луну- совсем не критерий.
Со студией (IDEA) та же ситуация.
У некоторых 21-ых Волг до сих пор пороги не сгнившие, а у современных машин не каждая и 4 года выхаживает… И?
Уж лучше каждые 3 года автомобиль менять, чем постоянно рисковать своей и чужими жизнями на 21 волге. Включая пешеходов.
Да она старая и крепкая, но тяжелая, с очень длинным тормозным путем, плохим управлением, без подушек безопасности, систем удержания на дороге и тд. По современным меркам это не приемлемо. В результате такой автомобиль на дороге просто опасен для всех.
Тоже самое с электроникой с длительным сроком использования- через 5-10 лет она становится либо бесполезна, либо опасна. Вспомните советскую светомассу в приборах, и как от них потом избавлялись.
И да, 2-3 года- вполне нормальный, не одноразовый, срок службы. Жизнь просто стала быстрее
речь шла про 10 лет. Ноуты с i5-i7HQ 2015 года выпуска переваривают студию очень шустро. да и ноут на T4400 я приобрел в 2009 году.
А что Вы предлагаете? Вы же не будете передвигаться на 21й волге, чтобы подвергать свою и чужие жизни опасности? Или предлагаете сидеть на 486 процессоре? 64k так никому и не хватило, всё надо менять
На мой взгляд, если вы за рулем или едете в транспорте стоя- то набирать текст больше короткого предложения- плохая идея в принципе. Потому в этом случае экранная клавиатура сгодится. А если освоить swipe- будет еще проще.
А сидя пассажиром не вижу проблемы достать из сумки 7" планшет c клавой или 11" ультрабук. Планшет, как и смартфон, не выключается вообще, ультрабуки (современные) загружаются за секунд 5. Возможно, Ваш планшет не очень компактный (нетбук не рассматриваю ибо все они, как правило, дохлые и грузятся долго)
Насчет фичерфонов- да, на закате они умели много, но это всё равно капля в море от современной ios и, тем более, Android.
J2ME- вообще отдельный разговор. Наслушался баек от тех, кто под нее писал. Такие костыли редко где увидишь. В общем разрабы ее не очень любили. Зато современная разработка на Kotlin под Android- просто песня.
на андроиде ява крутится в виртуалке на линуксе
Почитайте на досуге, что такое Android Framework на ART, и какие копеечные нагрузки они дают на железо. Для сравнения- в ios нет VM- всё бинарное. И тем не менее, современная ios сливает по автономности современному андроиду. Самые прожорливые компоненты в смартфоне- это экран и радиомодули.
редкие жирные игрушки весили мегабайт и больше
Сегодня у смартфонов fullhd и 2k-экраны. Одна графика для таких экранов весит, как j2me проги. Я писал про Smart и G-класс. И тем не менее- хорошо выполненное приложение редко весит больше 30мб. Для сравнения- клиент хабра весит 12мб, WhatsApp- 20mb.
Да, есть простые приложения, которые весят более сотни. Но это- либо игры, либо продукт недобросовестных разработчиков, которые имеют плохую привычку пихать JavaScript (ну или .net) во всё, что видят.
И потом- современный смартфон щелкает веб-запросы в десяток мегабайт как орешки. Для J2ME это до сих пор недостижимо. Возможности и мощности можно долго перечислять.
требовать ненужные права, сливать телеметрию и шпионить
Поверьте, был бы J2ME жив, точно так же было бы и там. Сегодня век торговли бигдатой. Раньше у компаний не было в этом коммерческого интереса.
Увы, GDPR не запрещает сбор данных, он просто выставляет к нему определенные требования, в частности, явное согласие пользователя на их сбор, его право на opt-out и удаление уже собранных данных
Верно, не запрещает. Как WhasApp пользоваться без указания номера телефона?..
Поправьте, если ошибаюсь- в одной из тем по GDPR говорилось о запрете необоснованного ограничения функционала сервиса в случае отказа предоставить данные. То есть нельзя не пустить пользователя в приложение, если тот не хочет давать доступ к контактам или, например, телефонии. Это как раз то, чего сейчас не хватает многим сервисам.
действенным методом воздействия может быть только жёсткая политика платформы
Есть такая политика у Apple на бумаге. Например, приложение должно объяснять пользователю, зачем ему те или иные права, и что делать в случае отказа их предоставления. Но по факту это работает странным образом- применяется избирательно. Плюс, несмотря а всю жесткость, в AppStore тоже есть мошенники (русская версия).
В итоге Модерация с жесткой политикой тоже не особо помогают- человеческий фактор + коммерция. Если что и может помочь с вопросом- так это холодный, бездушный, не делающий исключений и хорошо протестированный софт платфомы. Только никому такой делать не выгодно- об этом писал выше.
Rx (если говорить об RxJava) не только про реактивщину, но еще и про функциональщину.
Функциональный подход имеет свои преимущества и недостатки в равной степени с другими. Если Вам функциональный подход больше нравится- то да, возможно, LiveData Вам использовать смысла нет.
Зато LiveData хорошо стыкуется с корутинами (которые, на сегодняшний день, являются рекомендуемым подходом к построению многопоточности). Такая связка хорошо укладывается в императивный или декларативный стиль.
Сам имел опыт работы с приложениями, построенными на Rx (включая mvp на rx). И связка Android Architecture Components + корутины, на мой личный взгляд, имеет больше преимуществ.
Так что в целом interceptors- более правильный вариант, но требует больших знаний о многопоточности
А вот на игровых виндовых моделях с этим более-менее всё в порядке. У самого личная рабочая машина- Asus ROG GL552. Был куплен в конце 15 года и стоил в 2 раза дешевле его ближайшего яблочного аналога 16 года. Всё, что с ним делал за это время- менял SSD на более емкий и добавлял RAM так как Android Studio в 8гб на жирных проектах было уже тесновато (с учетом системы, кучи вкладок хрома и прочего ПО).
При этом имею опыт работы с MB Pro 17 и 18 года. И ни о чем не жалею- производительность либо примерно та же, либо быстрее (если говорить об Android Studio и Unity), так что покупка себя оправдала.
Само собой минусы тоже есть. При большой нагрузке он весьма горяч. Решение- завести режим энергопотребления с отключенным Turbo Boost и работать в режиме «макбука»- тихо и холодно, но всё еще достаточно быстро. Ну а когда надо быстрее- переключить режим.
Ну и вес- 2,5 кг. Всё-таки это не ультрабук. Но для меня не критично.
В остальном- проблем нет ни по качеству ни по производительности. Но уже задумываюсь о замене по-мощнее так как в ближайшие пару лет, скорее всего, этого хватать перестанет.
Так что
— Смотря какой именно Asus покупать…
Проблема задачи в том, что RN и Flutter основаны на подходе bridge-коммункации. Сам по себе этот bridge зачастую медленный. Он достаточно быстр для взаимодействия с большинством компонент, но при большой нагрузке может стать бутылочным горлышком.
Плюс если есть требования к размеру приложений (например, нужен Instant Apps) или к его взаимодействию с пользователем (например, управление на Apple TV и Android TV), то кроссплатформенные фреймворки сегодня не смогут предоставить подходящего решения.
Проблема в количестве платформозависимого кода состоит в том, что если его доля в проекте переваливает за 40-50%, то встает вопрос о надобности кроссплатформенного фреймворка в принципе. Соотношение время-деньги-качество получается уже не таким вкусным в сравнении с нативной разработкой. То есть две команды нативных разработчиков обойдутся дороже, но с реализацией справятся быстрее, а итоговое решение будет более отзывчиво себя вести и (при желании заказчика) соответсвовать гайдлайнам (что позволит привлечь или удерживать часть аудитории за счет привычного UX).
В итоге время здесь часто более важный фактор чем деньги. Раньше выйдешь на рынок- отхватишь больший кусок.
В современном мире само наличие легального root в смартфоне- уже дыра. Поскольку нельзя доказать функционал ПО кроме как посредством ревью исходников, что никому нафиг не надо.
Эти PoC работают для одной конкретной версии ПО. С учетом неравномерности и интенсивности обновления- массово их применять не выйдет. Пример- Lucky Patcher.
Ага, только recovery их монтировать умеют, а вендоры иногда выводят в них регистры в ФС. Вообще было приведено в качестве примера вариантов вектора атаки на загрузчик.
Очень просто- песочница приложения замыкается на Android Framework. В том числе с точки зрения ФС. В случае даже при наличии root ФС будет выдавать пустые каталоги чужой песочницы, а так же отказывать в записи. Помните, что linux-ядро Android крайне сильно модифицировано, за счет этого и достигается такая стратегия.
В итоге при наличии root нужно еще эскалировать приложение посредством добавления OEM-подписей, регистраций и прочего в System. Что, при запрете на запись без возможности перемонтировать благодаря загрузчику, не возможно. Опять же напомню про вендорские системы защиты поверх OEM-блокировки вроде HTC Boot Security или Samsung KNOX.
Так что всё просто. Хотите безопасности- покупайте белый аппарат бренда первого эшелона и не трогайте загрузчик. И в ином случае самой главной дырой в системе становитесь Вы сами.
Заказчик может зареквестить «вот эту фичу, и я принимаю проект». И так раз десять. Таким образом получая больше работы за те же деньги. И подписанное ТЗ часто не спасает так как очень абстрактно.
Конечно возникает конфликт заказчика и аутсорсера, в котором на кону два самых ценных ресурса- деньги и время. Первый хочет больше времени по-дешевле, второй- наоборот.
Верно, зато сторонние приложения могут понять, можно ли такой эксплоит применить и был ли он применен путем попытки эскалации прав и анализа ФС в system на предмет опасных бинарников или настроек. И, в случае обнаружения, отказаться работать. Код, который реализует 90% из этого, состоит из ~20 строчек)
JIT в Android повсеместно не применяется начиная с 5й версии. В последнем его вернули ради того, чтобы запуск после установки был быстрее. Но далее работает прекомпайл. Так что искать что-то в кэше JIT нет смысла с учетом того, что 4й андроид сегодня вымирает. Что может интересовать, так это БД, shared preferences, данные аккаунт-менеджера и криптоконтейнеры.
Забыл написать, что в read only монтируется не только system, но и другие системные разделы- boot, kernel, radio и тд. Чтобы прочитать данные другого приложения, не достаточно получить root-права. После их получения нужно себя эскалировать в системе путем изменений в ФС system (или других разделов, зависит от вендора. против подобного у HTC работает S-ON). И вот это на современных загрузчиках сделать сложно, так как при применении эксплоита запрет на запись всё равно не отменяется
Менеджерами прав не решается- они обходятся пусть и с разной степенью сложности. Выход- монтировать /system как read only, чем и занимается заблокированный загрузчик.
Потому многие приложения, имеющие отношение к финансам или другой более-менее важной информации, отказываются работать при наличии root. И потому это более чем обосновано.
Скорее всего будет возможность обратно заблокировать загрузчик. Разблокировать, установить мэнеджер, внести коррективы, удалить мэнеджер, заблокировать. Но когда malware в system- либо у Вас MTK старой ревизии, либо производитель, который наверняка позаботился о ресторе. Лучше уж сменить смартфон чтобы без повторений. Любой белый аппарат от любого известного бренда (кроме Xiaomi на MIUI- там даже на белых аппаратах есть дыры).
Разрабы приложений могут это сделать, конечно, своими силами. Только разработка будет стоить сильно дороже и садить батарею будет сильно больше.
В AOSP это всё тоже нельзя ибо пакет проприетарный и надо контролировать установку чтобы обеспечивать безопасность. В конце концов, сервера FCM и прочие оплачивать тоже надо, на что уходят деньги с установки на девайс.
Итого- выпиливать нельзя. Достойных аналогов нет и в Play Servises самый востребованный функционал.
Со студией (IDEA) та же ситуация.
Уж лучше каждые 3 года автомобиль менять, чем постоянно рисковать своей и чужими жизнями на 21 волге. Включая пешеходов.
Да она старая и крепкая, но тяжелая, с очень длинным тормозным путем, плохим управлением, без подушек безопасности, систем удержания на дороге и тд. По современным меркам это не приемлемо. В результате такой автомобиль на дороге просто опасен для всех.
Тоже самое с электроникой с длительным сроком использования- через 5-10 лет она становится либо бесполезна, либо опасна. Вспомните советскую светомассу в приборах, и как от них потом избавлялись.
И да, 2-3 года- вполне нормальный, не одноразовый, срок службы. Жизнь просто стала быстрее
А что Вы предлагаете? Вы же не будете передвигаться на 21й волге, чтобы подвергать свою и чужие жизни опасности? Или предлагаете сидеть на 486 процессоре? 64k так никому и не хватило, всё надо менять
А сидя пассажиром не вижу проблемы достать из сумки 7" планшет c клавой или 11" ультрабук. Планшет, как и смартфон, не выключается вообще, ультрабуки (современные) загружаются за секунд 5. Возможно, Ваш планшет не очень компактный (нетбук не рассматриваю ибо все они, как правило, дохлые и грузятся долго)
Насчет фичерфонов- да, на закате они умели много, но это всё равно капля в море от современной ios и, тем более, Android.
J2ME- вообще отдельный разговор. Наслушался баек от тех, кто под нее писал. Такие костыли редко где увидишь. В общем разрабы ее не очень любили. Зато современная разработка на Kotlin под Android- просто песня.
Почитайте на досуге, что такое Android Framework на ART, и какие копеечные нагрузки они дают на железо. Для сравнения- в ios нет VM- всё бинарное. И тем не менее, современная ios сливает по автономности современному андроиду. Самые прожорливые компоненты в смартфоне- это экран и радиомодули.
Сегодня у смартфонов fullhd и 2k-экраны. Одна графика для таких экранов весит, как j2me проги. Я писал про Smart и G-класс. И тем не менее- хорошо выполненное приложение редко весит больше 30мб. Для сравнения- клиент хабра весит 12мб, WhatsApp- 20mb.
Да, есть простые приложения, которые весят более сотни. Но это- либо игры, либо продукт недобросовестных разработчиков, которые имеют плохую привычку пихать JavaScript (ну или .net) во всё, что видят.
И потом- современный смартфон щелкает веб-запросы в десяток мегабайт как орешки. Для J2ME это до сих пор недостижимо. Возможности и мощности можно долго перечислять.
Поверьте, был бы J2ME жив, точно так же было бы и там. Сегодня век торговли бигдатой. Раньше у компаний не было в этом коммерческого интереса.
Поправьте, если ошибаюсь- в одной из тем по GDPR говорилось о запрете необоснованного ограничения функционала сервиса в случае отказа предоставить данные. То есть нельзя не пустить пользователя в приложение, если тот не хочет давать доступ к контактам или, например, телефонии. Это как раз то, чего сейчас не хватает многим сервисам.
Есть такая политика у Apple на бумаге. Например, приложение должно объяснять пользователю, зачем ему те или иные права, и что делать в случае отказа их предоставления. Но по факту это работает странным образом- применяется избирательно. Плюс, несмотря а всю жесткость, в AppStore тоже есть мошенники (русская версия).
В итоге Модерация с жесткой политикой тоже не особо помогают- человеческий фактор + коммерция. Если что и может помочь с вопросом- так это холодный, бездушный, не делающий исключений и хорошо протестированный софт платфомы. Только никому такой делать не выгодно- об этом писал выше.