This adds a camera button on phones that can be used to show
and launch the camera.
- Minor refactoring of touch event dispatch in PagedView.
- Disables usability hints when keyguard loads.
- Only add a touch handler for camera icon once during layout.
- Update after review.
- Updated with latest UX camera and camera background assets
Change-Id: I09cd5cb0e501fd0f4659bea96d00c92b07f805c4
1. Move PdfDocument to android.graphics.pdf.
2. Changed the PdfDocument as per API concil request.
3. Updated the documentation.
bug:10461180
bug:10552565
bug:10681585
bug:10552336
Change-Id: I08e15b34cf37bb064248c887e6f59808019cafe8
Different devices can have different default SMS apps.
Bug: 10818725 Allow OEM to specify or override a default SMS app (package)
Change-Id: I02cee9a3276ae39838cda181c9911041c81ea399
...be uncached and too large
When the device is in a low RAM state, when we go to pull a cached
process out to use for some background operation, we can now kill
the current process if we consider its size to be too large.
Note that the current implementation for killing processes is to
just use the same killUnneededProcessLocked() method that we already
have for other things like too many cached processes. This is a
little wrong here, though, because in this case we are at the
point where the caller is actually looking for a process to use.
This current code is not actually removing or cleaning up the
process, so we still need to return the now killed ProcessRecord
and let things fall out from there, which typically means the caller
trying to make an IPC on it and failing and falling into its "oh
no the process died unexpectedly" path. All code using this
*should* be able to handle this correctly, anyway, since processes
really can be killed at any time.
At some point we may to make this implementation cleaner, where it
actually tears down the process right in the call and returns a
null ProcessRecord. That is very dangerous however (we'd need to
go through all paths into this to make sure they are going to be
okay with process state changing on them like that), and I'm not
sure it is really worthwhile. This intention is that killing
processes like this is unusual, due to processes being too large,
and anyway as I wrote all of our incoming code paths must already
be able to handle the process being killed at this point and one
could argue this is just another way to excercise those code paths.
Really, the main negative to this is that we will often have spam
in the log with exceptions about processes dying unexpectedly.
If that is the only issue, we could just add some conditions to
quiet that up at in this case.
We don't want to compute the size of the process each time we try
to evaluate it here (it takes 10s or ms to do so), so there is now
a new field associated with the process to give us the last pss
size we computed for it while it was in the cached state.
To be able to have better cached pss data when we now need it, the
timing for computing process pss has been tuned to use a much
shorter delay for the situations when the process has first switch
into a new state. This may result in us having a fair amount more
pss data overall, which is good, as long as it doesn't cause us to
be computing pss excessively and burning cpu.
Procstats now also has new state to keep track of the number of
times each process has been killed by this new system, along with
the min, avg, max pss of all the times it has happened. This has
slightly changed the checkin format to include this additional data
at the end of pkgkills/prockills lines.
Other changes here:
- Fixed a problem where GPU RAM was not being seen when dumping
the full RAM details of a process. This was because in that
case the system would ask the process to compute its own MemInfo,
which it returned, but the process doesn't have permission to
access the files containing the GPU RAM data. So now the system
always computes the MemInfo and hands it to the app.
- Improved broadcast delays to not apply the delay if the next receiver
of the broadcast is going to run in the same process as the last
one. A situation I was seeing was an application that had two
receivers, one of which started a service; we are better off letting
the second receiver run while the service is running.
- Changed the alarm manager's TIME_TICK broadcast to be a foreground
broadcast. This really should have been anyway (it is supposed to
go out even minute, on the minute, very accurately, for UI elements
to update), and is even more important now that we are doing more
things to delay background broadcasts.
- Reworked how we maintain the LRU process list. It is now divided
into the two parts, the top always containing the processes holding
activities. This better matches the semantics we want (always try
to keep those around modulated by the LRU order we interleave with
other cached processes), and we now know whether a process is being
moved on the LRU list because of an activity operation so we can
only change the order of these activity processes when user operations
happen. Further, this just makes that common code path a lot simpler
and gets rid of all the old complexity that doesn't make sense any
more.
Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
Always update to the newest available frame from a GLConsumer.
Otherwise, with a synchronous queue, rendering can fall behind and
eventually deadlock with producer.
Bug: 10830400
Change-Id: I7f1d752c80ae5dac892a26d82e86806c27f5d955
If pixel memory was just allocated by Java, tell our decoders not
to write 0s, since the memory was initialized to 0. Likewise,
when drawing to a bitmap with memory just allocated by Java, do
not erase to 0.
Depends on a change to external/skia to add the new option on
image decoders:
https://googleplex-android-review.git.corp.google.com/362663
BUG:10016979
Change-Id: I9a3dc969870f8516e7d8495fe96d0a6b8225eda2
* Make sure that pm.getHomeActivities() returns the activity metadata
as well, so that the caller can trace the reference
* Add a public canonical name for that metadata key
Bug 10749961
Change-Id: Ic4d0750d61001ffe5af180398f042afa30eea1ce
Public API, under system|signature permission for access to
currently playing metadata and playback state.
Public API for sending media key events.
Bug 8209392
Change-Id: I39b9309ca3fb1bc305492bad98740df0ae0842b2
Removed boolean param to ask for exception on detached fd. Use a
subclass of IOException instead.
Bug: 10461576
Change-Id: If7db16120297edcdb7d5d5905ed453003be0e38e
Fixes bug that double tapping on an entry in the intent disambig dialog
can result in the picked activity being launched twice.
Bug: 10770501
Change-Id: Ibb7c6bea5f3c25fa204a2f0e65c8044c2a2549f7
This reverts commit 3954fd9a05232cb6f7fc52aa49a0b34c1539028a, which
is equivalent to re-applying 8a1597b39632956cdbcb6b76874ccca786047d4c.
The change ("Take the input device into account for meta state") was
valid but caused CTS test failures because the test was wrong. The
test injected a key event with the meta state missing. This faulty
test was masked by the old toggle behavior.
Bug 10361803
exportToPdf use-case not supported in K so removing that dangling
reference from the javadoc
Change-Id: Ia0fe3aa9ed5150639d1f72341c89568a0a7e1c7d
1. The print dialog was resizable and as a result when printers
come and go its size changes which looks bad. The dialog is
now trying to be maximally large limited by a max size or the
screen - whichever is smaller. This required moving from
GridLayout to several LinearLayouts since the former does not
support distribution of empty space evently between the items
in a row. Also we want all items in a column of inputs to be
of equal size (the spinners specifically).
2. Added labeledBy attribute to associate a view with another one
that serves as its label for accessibility purposes. We have
lebelFor attribute but it is not useful in most layout files
since it has to refer the auto-generated id of a view which
usually appears later in the layout file, thus generating a
compilation error. This was needed for the accessibility support
of the print dialog.
bug:10631660
2. Disabling the spinners or the print button did not produce
visual feedback leading to user frustration.
bug:10741907
Change-Id: I0c12eddabc4035bc7becd1b86c1f1b8fdcf4289c
...while setting up a new user from settings.
We can now delay broadcasts when there are enough background services
currently starting (still set to 1 for svelte devices, 3 for normal
devices).
Add new intent flag to not allow receivers to abort broadcasts, which
I use to fix an issue with the initial BOOT_COMPLETED broadcast not
actually requesting pss data at the right time -- it can now be sent
as an ordered broadcast without the ability for the receivers to cancel
it.
Change-Id: I51155bbbabe23e187003f3e2abd7b754e55d3c95
This reverts commit 8a1597b39632956cdbcb6b76874ccca786047d4c. That
commit broke some of the handling of meta state, which in turn caused
CTS test failures, notably bug 10210151 (CTS:
android.text.method.cts.BaseKeyListenerTest#testBackspace_withSendKeys
is failing on KLP).
So this revert fixes those test failures, but leaves bug 8303489
(Pressing shift on the hardware keyboard messes with unrelated
keypresses, including virtual ones) still present. We'll plan to
address that in a future release.
Change-Id: Iea42c643b6d08f33cbd2ed1747e8de3b5f8116a6
