- Has first 4 quick tiles shown in collapsed mode
- Shows date + settings gear in expanded mode
- Still has a few gaps (alarms probably don't work)
- Fix issue with placement of cell data type indicator
Change-Id: I629798b96f4f088fde47c7b67feea304dcc8450c
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
When multi-thread renderer is used, delay the report to draw to the
first doFrame in ResizeFrameThread. Otherwise we could unfreeze the
window before the frame is drawn.
Also when content draw bounds is updated for the first frame, let
content draw before ResizeFrameThread so that the bounds get applied.
bug: 24715185
Change-Id: I5485dc0be3eae24c555bcc31ee8f71523b68ca8d
IBinder has a new common interface for sending shell commands
to it. This can be implemented by system services to provide
a shell interface to the service, without needing to have separate
shell java code.
This includes changes to DeviceIdleController to implement the
shell interface for all of the commands it has been providing
through dumpsys.
Change-Id: I76518ea6719d1d08a8ad8722a059c7f5fd86813a
* commit '3d3f766c8b37dcf495235ca4a500494498712eed':
Support DHCP replies with multiple default gateways.
Accept DHCP responses from non-67 server source ports
Improve logging of DHCP parse errors using exceptions.
When system has more than one built in display, displayReady needs
to be called for all built in displays when window manager is ready.
Otherwise, some system services, such as presentation, mediarouter,
etc, won't work on these displays.
Bug: 24103683
Change-Id: Ibf08074eff555c14a318236bd06e7b4855503140
Not to resume home activity in finishing stage as following case:
When only home task has 2 activities,
(ex: SetupWizard & DeviceOwnerProvisioningActivity),
If SetupWizard crashed during DeviceOwnerProvisioningActivity in
finishing stage,
makes DeviceOwnerProvisioningActivity cannot destroy immediately,
In resumeHomeStackTask, will resume DeviceOwnerProvisioningActivity
(returned by getHomeActivity),
But actually, DeviceOwnerProvisioningActivity cannot be resumed.
Caused ANR when back key since no more running activity can resume.
Change-Id: Icec49e092d2e7bee7f6a2d198913c1c5db7122f2
The timing issue cause some port/device select request
to return error if made while the service is being initialized
waking up from sleep.
This CL buffers the request so that it can be handled as
expected once the service initialization and device discovery
is completed.
Bug: 23084229
Change-Id: I8bcdaf3b708c6b9bf75ea15304c08bd35bd0f6d0
(cherry picked from commit d0b01dfe0aaebd054165dfe2f5f4bd7d68703970)
* commit '871d96b44c9665238d1df87ed89656f742abe2fa':
Support DHCP replies with multiple default gateways.
Accept DHCP responses from non-67 server source ports
Improve logging of DHCP parse errors using exceptions.
* commit '13c5dd5c19c5bcc60910b4e37f4e9e171adf099b':
Support DHCP replies with multiple default gateways.
Accept DHCP responses from non-67 server source ports
Improve logging of DHCP parse errors using exceptions.
* commit 'eb0bbd45f62fcaff26151b54a7b3ea16bb67e3be':
Support DHCP replies with multiple default gateways.
Accept DHCP responses from non-67 server source ports
Improve logging of DHCP parse errors using exceptions.
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: Ib090273a417f7eb2ac1ee3309260249b72fb8345
