Android гарантирует порядок намерений?

Question

При отправке двух намерений (от одного до startService с последующим другим через startActivityForResult для примера), гарантирует ли Android, что первое намерение (услуга) обрабатывается до второго (действие)? Более конкретно, в этом случае, это гарантирует, что Service.onStartCommand вызывается перед Activity.onCreate?

Предполагается, что все выполняется в одном и том же процессе, поэтому проблемы потоков из нескольких основных потоков не мешают работе.

Я знаю, что Android не гарантирует порядок обработки для одного намерения (порядок получателей не гарантирован, но может зависеть от приоритета фильтра намерений), но я не смог найти ничего, упоминающего порядок между намерениями.

Лично я бы подумал, что, учитывая единственный основной поток приложения, порядок будет поддерживаться, но я сталкиваюсь с некоторыми ошибками, которые мне сложно объяснить, если не изменится порядок намерений.

Answer 1

1. Я не верю, что Android дает какие-либо гарантии - в частности, я считаю, что Context.startService будет асинхронным . Редактировать : После вашего комментария я считаю, что вы правы в том, что startService вернется только после того, как служба вызовет свой метод onCreate.Однако, если Service находится в другом приложении, то он обычно не будет работать в том же процессе, не говоря уже о том же потоке.
2. Android, вероятно, не дает этой гарантии, поскольку он уже заявил, что пока попытается сохранить работоспособность служб, теоретически может уничтожить службу между вашим вызовом Context.startService и вашим вызовом Activity.startActivityForResult.
3. Зачем вамнужна такая гарантия в первую очередь?Получите услугу startService или bindService, когда вам это нужно, укажите, что должно произойти с вашим приложением, когда оно достигнет фазы жизненного цикла, и позвольте Android управлять самим жизненным циклом.

Сноска: также, если ваш Activity уже запущен, метод onCreate может не вызываться при вызове onActivityStart.

Answer 2

Это должно помочь. Страница разработчика BroadcastReceiver

Ключевым битом является то, что намерение, которое запускает действие, семантически сильно отличается.

Кажется, что было бы довольно легко проверить заказ путем регистрации.