Pull to refresh

Comments 34

Интересные изменения. Жаль только, что не доберется до моего смартфона.
Google старается минимизировать количество работающих фоновых сервисов и предлагает использовать JobScheduler и GcmNetworkManager.

То есть совсем режется возможность запускать вечноживущие сервисы?
Это и не всегда хорошо. Было бы здорово, если бы они дали пользователю право выбора — разрешить приложению работать в фоне или нет, и по умолчанию — что бы было запрещено. Бывают легитимные ситуации, когда я, как пользователь, очень хотел бы что бы приложение работало в фоне, и не зудело постоянно висящим уведомлением.
А можете пример дать, когда действительно это надо(без висящего уведомления)? Я лично не могу придумать особо. Пользователь же всё равно не видит результат вашей фоновой задачи пока не вернётся в приложение, а когда вернётся хз ещё…
Например, обновление информации на виджетах. Пользователь не желает трогать приложение, но информация на виджетах должна быть все время актуальна.

В последних версиях андроида такие приложения засыпают, виджеты не обновляются, а при входе в приложение начинают все обновляться, что может быть не быстро. А актуальную информацию хочется видеть быстро, для чего приложение и работает в фоне.
Например приложения для работы со смарт-гаджетами (кроме Android Wear). Меня лично все время раздражает висящее уведомление от Pebble, которое висит там только за тем, что бы OS не прибила сервис. Своему Android Wear приложению Google как-то разрешили висеть в фоне и не быть убитым.

Или например — есть у меня приложение для календаря, расширяющее его фукнциональность, для чего приложению нужен переодический рескан calendar provider-а. Сейчас все прекрасно работает, приложение раз в 30 минут просыпается на 10 секунд, проверить изменения в календаре, и засыпает дальше. Судя по системной статистике — батарейки на это уходит доля процента в день. Я так полагаю — мне теперь прийдется каждый раз показывать уведомление о том, что «я тут что-то делаю в фоне» при каждом таком просыпании. Пользователи то переживут, но недовольных много будет, да и выглядит это как-то криво.

(10 секунд — это на очень загруженном календаре с многими сотнями событий в месяц, как у меня, если событий меньше — то тратится еще меньше времени).

Так для переодических тасков есть JobScheduler + Alarm для старых версий. Зачем держать сервис в фоне все время? Тем более что он и так уже с 6-й версии в сон уходит без WakeLock'а, а с ним батарею жрет.

Сервис и так не висит постоянно. Он просыпается по таймеру, но вот на те 10 секунд работы приходится запускать сервис фоновый, т.к. иначе прилетит сразу ANR. А теперь получается (если я все правильно понимаю) нельзя запустить фоновый сервис по таймеру, только foreground сервис.

Из броадкаста разрешается стартовать сервис на несколько минут, поэтому в вашем случае ничего не поменяется.
Любой мессенжер, который не хочет зависить от сторонних, пусть и гугловых, пуш-сервисов. Предугадывая претензии «будет жрать», отвечу — не будет, если нормально написать.
Аналогичное предложенному тут решение было в ранних версиях Windows Phone, но в более поздних таки добавили полноценный неприбиваемый сокет, хоть и неконтролируемый извне и весьма дико выглядящий.

По поводу экономии ресурсов путем прибивания фоновых задач — очень понравился подход Huawei, который предлагает пользователю в настройках питания опции убивания приложения, когда оно не на экране. При этом эта опция включена по умолчанию везде, кроме некоторого списка популярных приложений. В отличие от сторонних менеджеров активности, которые мониторят запуск программ и прибивают их сразу же, что нерационально, встроенная в ядро Android система даже не дает ничему не разрешенному запускаться.
Например мое приложение для волонтерской программы попавшим в ДТП мотоциклистам. Одна из востребованных пользователями опций — отсылка пуша только если ДТП произошло рядом с ними (расстояние настраивается), а на моте в городе даже 10 минут — это 10 километров при неспешной езде.
Запустите foreground сервис. Я, как пользователь, хочу видеть какие программы сейчас реально работают.

Как по мне, можно более элегантно решить проблему надоедливого уведомления для foreground service при помощи группировки оных в какую-нибудь секцию в шторке уведомлений (рядом с WiFi, BT и т.п.). Там это не так бросается в глаза, но в то же время может быть более доступным и кастомизируемым (положение, видимость).
Конечно, это yet another icon в шторке, и тем не менее, так аккуратнее и остается понимание того, какие приложения сейчас работают, imho.

Так они же ввели Notification Channels — если разработчик приложения сделает иконку foreground сервиса и другие нотификации в разных channel-ах, то пользователь легко может скрыть только channel с foreground сервисом.

Время, когда Android позволял делать все что угодно, уходят в прошлое.

Лично для меня как пользователя была бы удобной возможность самостоятельно выбирать, что запрещать, а что нет. Например, мне было не очень удобно, когда они решили запретить сторонним приложениям управлять режимом полета.
Вот здесь, кстати, поддержу. Не могу представить себе случая когда зловредам понадобится переводить аппарат в режим полета, зато, к примеру, это теперь мешает сделать приложение для использования телефона в качестве пассивного GPS-маяка в автомобиле (который изредка выходил бы на связь по расписанию).

Большинству пользователей или до лампочки(им некогда смотреть) эти настройки или они тупые(ну бывает), включают все настройки подряд и потом жалуются на слабую батарею. Я поддерживаю Google в этих ограничениях. Идут по стезе яблочной компании, потому что поняли, что на разработчиков положится нельзя в плане экономии ресурсов устройства.

Это Вы говорите о приложениях, которые отключали бы режим полета, тем самым тратя батарею (если я правильно Вас понял), однако речь идет о приложениях, которые наоборот включали бы его. У меня рутнутый девайс и сторонняя шторка, которая может включать/выключать его, однако это занимает секунд 5, ибо ждет освобождения процессов. И зачем, спрашивается?
И все-таки, даже после улучшения и доработок контроля разрешений, до идеала еще очень далеко. Да, теперь приложения отдельно запрашивают доступ к камере, файловой системе или контактам, но подавляющее большинство при отказе в разрешении просто перестает работать.
Проблему бы решило некое подобие sandbox'а: чтобы при запросе прав доступа были вариант «Разрешить», «Запретить» и «Пусть играется в песочнице».
Программе за каким-то фигом захотелось залезть в список моих контактов? Окей, вот тебе доступ, только контактов что-то нету особо, или есть только несколько фейковых. Понадобился доступ к смс? Вот тебе доступ к сообщениям, только вот не приходило нам сообщений за последнее время что-то (или покажем приложению только те, на которые явно поставил галочку пользователь). Хочется доступа к камере? Вот тебе доступ, только камера у нас снимает заранее заданную статичную картину. И так далее.
… и захватывающая гонка вооружений: «создать достоверную песочницу» vs «определить, что приложение запущено в песонице и упасть назло хитрому юзеру!»

такое поведение породит только больше проблем как для нас(разработчиков) так и для пользователей, будут миллионы проблем из-за "неверно предоставленного разрешения", недопонимания как это должно работать и тд. Разрешение либо есть, либо его нет.

Если переживать за неопытных пользователей — можно сделать чтобы подобное было отключено по умолчанию, но включалось при наличии понимания своих действий и осознанного желания (как «Настройки для разработчиков» в Andoid, например).
В конце концов, на ПК никого не пугает наличие таких вещи как chroot/fakeroot и sandboxie, и с этим нет никаких проблем.

Слишком много работы для малого количества людей

подавляющее большинство при отказе в разрешении просто перестает работать.
вы пользуетесь какими-то неправильными приложениями. У меня таким, насколько помню, страдало всего одно.
На самом деле для разрабов жарко процесс идет: последний SDK для него признал ProgressDialog deprecated, вместо этого рекомендуется использовать прогресс-бары прямо в адаптерах, но так как все эти рекомендации до сих пор чисто на бумаге уже кучу времени — пока приходится созерцать эти deprecated везде без возможности исправления, дабы не изобретать велосипеды. Для перфекционистов, привыкших иметь галочки перед каждым файлом в проекте, это сущее мученье)
И да, удивлен, что название его еще не расшифровано, хотя уже известно в определенных кругах. Oreo. И не благодарите)
Да, но оно скорее всего отметется, ибо в Oreo больше сладкого (это печенье черного цвета с белой прослойкой), чем в Octopus, а попробуй докажи юзерам, что Octopus — это на самом деле сладость такая, в форме осминога, мол, вы ничего не понимаете в нейминге.

Или Oatmeal cookie — так называется желтое лого android 8. Название было на IO 2017
image

Извиняюсь, забыл ответить… Oatmeal cookie, судя по названию — это овсяное печенье? Тоже может быть, правда сладостью это не назовешь) А это из выступления каких лиц на IO?

What's new in notifications, launcher icons, and shortcuts. Тайминг на видео 13:24

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.kaspersky.ru
Employees
1,001–5,000 employees
Registered