db5dec271e
To reduce the number of times that we load resources based on configuration changes ActivityThread employs an optimization strategy that merges relaunch operations. If it receives a relaunch request why one is already queued, it will just update the queued request instead of creating a new one. Unfortunately this breaks the guarantee of executing lifecycle events in the order they were received. Consider following scenario of requestes from Activity Manager: 1) relaunch the activity in not resumed state; 2) resume the activity; 3) relaunch the activity in resumed state. The Activity Thread can process these commands in following order: 1) receive the request to relaunch in not resumed state; 2) receive the request to resume the activity; 3) receive the request to resumed state, update the exisiting request; 4) execute the request to relaunch in resume state; 5) execute the request to resume. This causes the activity to perform resume twice. Since we need the merging of relaunch operations for performance reasons, we need to introduce a secondary mechanism for ordering of lifecycle requests. Relaunching, pausing, stopping and resuming receive a sequence number based on when the request was received. If the last executed sequence number is higher then the operations sequence number then the operation will be dropped. In the above scenario the sequence number would be: 1) request to relaunch not resumed receives seq + 0; 2) request to resume receives seq + 1; 3) request to relaunch resumed receives seq + 2; 4) execution of of request to relaunch resumed set current sequence number to seq + 2; 5) since seq + 1 < seq + 2, then the execution of request to resume is prevented. Bug: 24806374 Change-Id: Ia520dd1aa215827d4172a9891a7cc01db2ce627e