Тесты на рут могут проверять только очевидный рут, однако может, например не стоять SU, и половина тестов скажет что рута нету, плюс разные тесты на разных устройствах по-разному работают. Если Кнокс ругается, значит попытки рута были: может не до конца доделанные, а может после этого поставилась чистая ось, поэтому вы следов не видите.
У самсунга уже есть Galaxy Apps, который они устанавливают параллельно с Play Store, и при первом запуске телефона активно пытаются заставить пользоваться именно первым, так как многие предустановленные приложения (все приложения самсунга, офис от майкрософта, может что-то еще) обновляются именно через него. Некоторые популярные приложения действительно дублируются в Galaxy Apps, но там, увы, есть далеко не всё.
На мой взгляд добавление альтернативных магазинов усложняет жизнь пользователям, потому что мало подобрать/выбрать приложение, ещё придется выбирать магазин, из которого его установить и в дальнейшем обновить. Да и в экосистеме гугла выпилив плэй стор страдают и другие функции, вот если бы была хорошая альтернатива всей экосистеме, тогда для пользователя это было бы лучше. И, кстати, такая альтернативная экосистема работает в виде Baidu в Китае.
Кроме play market на девайсах крутится еще несколько приложений, которые отвечают за уведомления, за гелокацию, за слежение за вами, за сохранение истории использования приложений, перемещений и так далее. В целом на устройство устанавливается порядка 5-15 приложений гугла и далеко не все из них вы увидите у себя на домашнем экране.
На китайском маркете Baidu сервисы, и при разработке приложений под китайский маркет приходится не использовать GCM/FCM для нотификаций, например, а использовать BaiduCM (условно) — читать документацию на китайском с гуглтранелсейтом и имплементить. У байду есть свои аналоги сервисов гугла практически для всего.
Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
Для больших команд существуют различные способы масштабирования скрама, например Nexus — для него тоже есть гайд на scrum.org.
Так что это точно ошибка тех организаций, в которых вы работали.
Больше скажу, если не ошибаюсь, то в скрам гайде примеры вопросов приведены как-то вроде:
— что я сделал для достижения цели спринта?
— что мне мешает в достижении цели спринта?
С остальным согласен полностью, если обсуждать реальный синк о том что блокирует и кого уже разблокировал, то 5-15 минут хватает и картина становится полностью ясной.
На сколько я помню, баг был в том, что в случае удаления клиента яндекс диска с Windows XP, винда превращалась в синий кирпич. 200 Гб подарили тем, у кого был замечен клиент на Windows XP.
Давно не хватало хабру английского. Общаясь с ребятами из штатов, периодически возникало желание отправить ссылку на хабр, чтобы они почитали статью… беда в том, что статья то на русском. Приходилось основные моменты переводить самому.
Добавление английского — очень большой и уверенный шаг, который, я думаю, должен окупиться полностью, причем в первую очередь для пользователей. Ведь чем больше умных голов, тем лучше всем нам.
А там уже можно будет статьи от англоязычных авторов спокойно переводить сообществом на русский для тех, кому на английском читать сложно.
Должно получиться что-то очень классное!
Если будете использовать JobScheduler придется самому предусматривать механизм прерывания и возобновления закачки, т.к. JobScheduler может как дать вам «рабочее» время и пространство, так и отобрать его.
Да, действительно, это неоспоримая польза комментариев:)
JobScheduler строго ограничивает использование себя, собственно он для этого и создавался, чтобы избежать утечек WakeLock, поэтому нужно успеть все выполнить за отведенное время, или же разбить задачу на мелкие, чтобы их можно было продолжить выполнять потом.
С одной стороны да, вызвав jobFinished мы информируем о том, что нам WakeLock больше не нужен (но не факт что JobScheduler его сразу снимет, ведь он может быть нужен другой задаче), с другой стороны, если удержание WakeLock не уместно (например запланирован уход в Doze или еще что-нибудь подобное), то немедленно будет вызван onStopJob для всех задач и WakeLock будет отпущен.
В теории onStopJob действительно может не вызваться тогда, когда нечего останавливать, но в этом случае он и не несет никакого смысла.
На практике JobScheduler выделяет определенное время («окно») для каждой задачи, и если за это время задача все еще выполняется, то onStopJob для неё вызовется и будет иметь смысл.
Я полностью согласен с тем, что при выполнении задач в других потоках избегать вызова jobFinished — плохая практика, именно поэтому я об этом упомянул, но пример реализации не поместился в данную статью, так как для конкретного примера это не является чем-то значительным, что может сказаться на работе комплекса. Ведь все что делает задача — отправляет интент в IntentService на базе applicationContext, в котором и находится этот IntentService, таким образом у нас нет бесконечных циклов или утечек памяти. Единственный побочный эффект это то, что перестает держаться WakeLock, а тестовый IntentService вполне это переживет.
Тут нужно понимать, что вызов onStopJob не говорит, что сейчас вот все будет уничтожено и потеряно, основная его функция — сообщить об окончании удержания WakeLock. И если для целевой логики это действительно важно, то имеет смысл выполнить какие-то действия по информированию рабочего потока о том, что ему нужно экстренно завершать работу, а также очистить ресурсы для следующих задач.
Все верно, я об этом и упомянул в конце статьи. С jobFinished я хочу показать возможности передачи информации между сервисами, а также варианты обработки ситуаций, когда нужно прекратить выполнение задачи, или когда нужно перезапланировать её выполнение и так далее.
Добавив всё это в текущую статью, я бы увеличил её размер в 2 раза.
На данный же момент, чтобы избежать повторов по BackoffCriteria можно вернуть false из метода onStopJob, и следующее выполнение будет обусловлено либо новой задачей либо запланированной повторяющейся.
Но Apple предлагает модификации экранов — больше и поменьше, ведь тоже исходя из предпочтений пользователей. Кто-то любит побольше (модификация Plus), а кто-то поменьше. Практически больше ничем девайсы не отличаются друг от друга.
А почему нельзя создать две модификации? По аналогии с LTE/3G модулем в планшетах: когда вся начинка одинаковая, кроме поддержки связи и слота для симки. Так можно и в электронной книге сделать: все железо и экран одинаковые, но за доп плату можно получить разъем для наушников и поддерживающую музыкальные функции прошивку.
Тогда будущим покупателям не нужно будет голосовать на хабре, а просто каждый сможет выбрать подходящий для себя вариант: подешевле без музыки, подороже с музыкой.
Мне кажется звание флагмана вполне может допустить себе иметь модификации, тогда и рынок легче будет покрыть, и обе группы пользователей будут рады, что о них позаботились.
С одной стороны molnij прав, если устройство не рутовано, то для легальных способов навредить нужно выдать права приложению, т.е. например сделать его девайс админом, Knox же (либо другие аналогичные приложения от других производителей) устанавливается как системное приложение производителем, а системное приложение по сути имеет рут, т.е. гораздо больше прав, чем у самого пользователя. И таким образом, если вы даете разрешение приложению на девайс админ, а оно в свою очередь работает с Knox API, то получается что у приложения есть «полурут» (в рамках функций Knox API).
В нехороших руках вполне можно наделать много бед, тем более когда приложение использует Knox и девайс админ.
Без использования этого есть и другие средства для злоумышленников, которые как путем обмана, так и путем использования дырок в самой системе могут сделать что угодно. Однако, стоит отдать должное разработчикам, дырки закрываются, и, например Google постоянно выпускает заплатки для своих девайсов.
Первая попытка: краш после принятия лицензии KNOX (репорт отправил, смотрите в девелопер консоли ну или в крашлитике).
Вторая попытка: вроде все ок. Спасибо, попробую пользоваться, может будут еще какие-то отзывы.
Для начала, если Вам нужно создать и запустить новую активити, то нужно воспользоваться примерно следующим кодом:
Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);
Ну и в принципе с onReceive() в BroadcastReceiver нужно быть очень осторожным, потому что у него есть жесткие ограничения, например, на время выполнения кода.
На мой взгляд добавление альтернативных магазинов усложняет жизнь пользователям, потому что мало подобрать/выбрать приложение, ещё придется выбирать магазин, из которого его установить и в дальнейшем обновить. Да и в экосистеме гугла выпилив плэй стор страдают и другие функции, вот если бы была хорошая альтернатива всей экосистеме, тогда для пользователя это было бы лучше. И, кстати, такая альтернативная экосистема работает в виде Baidu в Китае.
Для больших команд существуют различные способы масштабирования скрама, например Nexus — для него тоже есть гайд на scrum.org.
Так что это точно ошибка тех организаций, в которых вы работали.
— что я сделал для достижения цели спринта?
— что мне мешает в достижении цели спринта?
С остальным согласен полностью, если обсуждать реальный синк о том что блокирует и кого уже разблокировал, то 5-15 минут хватает и картина становится полностью ясной.
Добавление английского — очень большой и уверенный шаг, который, я думаю, должен окупиться полностью, причем в первую очередь для пользователей. Ведь чем больше умных голов, тем лучше всем нам.
А там уже можно будет статьи от англоязычных авторов спокойно переводить сообществом на русский для тех, кому на английском читать сложно.
Должно получиться что-то очень классное!
JobScheduler строго ограничивает использование себя, собственно он для этого и создавался, чтобы избежать утечек WakeLock, поэтому нужно успеть все выполнить за отведенное время, или же разбить задачу на мелкие, чтобы их можно было продолжить выполнять потом.
С одной стороны да, вызвав
jobFinishedмы информируем о том, что нам WakeLock больше не нужен (но не факт что JobScheduler его сразу снимет, ведь он может быть нужен другой задаче), с другой стороны, если удержание WakeLock не уместно (например запланирован уход в Doze или еще что-нибудь подобное), то немедленно будет вызванonStopJobдля всех задач и WakeLock будет отпущен.onStopJobдействительно может не вызваться тогда, когда нечего останавливать, но в этом случае он и не несет никакого смысла.На практике JobScheduler выделяет определенное время («окно») для каждой задачи, и если за это время задача все еще выполняется, то
onStopJobдля неё вызовется и будет иметь смысл.Я полностью согласен с тем, что при выполнении задач в других потоках избегать вызова
jobFinished— плохая практика, именно поэтому я об этом упомянул, но пример реализации не поместился в данную статью, так как для конкретного примера это не является чем-то значительным, что может сказаться на работе комплекса. Ведь все что делает задача — отправляет интент в IntentService на базе applicationContext, в котором и находится этот IntentService, таким образом у нас нет бесконечных циклов или утечек памяти. Единственный побочный эффект это то, что перестает держаться WakeLock, а тестовый IntentService вполне это переживет.Тут нужно понимать, что вызов
onStopJobне говорит, что сейчас вот все будет уничтожено и потеряно, основная его функция — сообщить об окончании удержания WakeLock. И если для целевой логики это действительно важно, то имеет смысл выполнить какие-то действия по информированию рабочего потока о том, что ему нужно экстренно завершать работу, а также очистить ресурсы для следующих задач.Добавив всё это в текущую статью, я бы увеличил её размер в 2 раза.
На данный же момент, чтобы избежать повторов по BackoffCriteria можно вернуть false из метода onStopJob, и следующее выполнение будет обусловлено либо новой задачей либо запланированной повторяющейся.
Тогда будущим покупателям не нужно будет голосовать на хабре, а просто каждый сможет выбрать подходящий для себя вариант: подешевле без музыки, подороже с музыкой.
Мне кажется звание флагмана вполне может допустить себе иметь модификации, тогда и рынок легче будет покрыть, и обе группы пользователей будут рады, что о них позаботились.
KNOX 2.2 Standard SDK 5.2.0, Android 4.4.4.
Без использования этого есть и другие средства для злоумышленников, которые как путем обмана, так и путем использования дырок в самой системе могут сделать что угодно. Однако, стоит отдать должное разработчикам, дырки закрываются, и, например Google постоянно выпускает заплатки для своих девайсов.
Вторая попытка: вроде все ок. Спасибо, попробую пользоваться, может будут еще какие-то отзывы.
Ну и в принципе с onReceive() в BroadcastReceiver нужно быть очень осторожным, потому что у него есть жесткие ограничения, например, на время выполнения кода.