* commit 'd54bc8009f745a5f730fa013bb0084c502b18aa9':
docs: change download URLs for design assets. These new URLs are dummies that are handled by a redirect rule for all /downloads/... paths, that points to http://commondatastorage.googleapis.com/androiddevelopers/ Using this redirect allows us to change the storage location of the download assets in the future.
* commit '71c4fc818dae494f4acdb24bb6d1b899ddc5e07d':
docs: change download URLs for design assets. These new URLs are dummies that are handled by a redirect rule for all /downloads/... paths, that points to http://commondatastorage.googleapis.com/androiddevelopers/ Using this redirect allows us to change the storage location of the download assets in the future.
These new URLs are dummies that are handled by a redirect rule for
all /downloads/... paths, that points to http://commondatastorage.googleapis.com/androiddevelopers/
Using this redirect allows us to change the storage location of the download assets in the future.
Change-Id: I0dc6ecc1a6898f1256ba4c9ff90b619366e47629
Temporarily reverting this until all devices switch to using wpa_supplicant_8.
This reverts commit b31f78f93768fef269617ec788a5c6655a375f80.
Change-Id: I33fcb8415288d95289dcd46fa71e950e0f2b87ec
Signed-off-by: Iliyan Malchev <malchev@google.com>
There are two fixes here:
- precaching: instead of caching-then-drawing whenever there is a new
glyph, we cache at DisplayList record time. Then when we finally draw that
DisplayList, we just upload the affected texture(s) once, instead of once
per change. This is a huge savings in upload time, especially when there are
larger glyphs being used by the app.
- packing: Previously, glyphs would line up horizontally on each cache line, leaving
potentially tons of space vertically, especially when smaller glyphs got put into cache
lines intended for large glyphs (which can happen when an app uses lots of unique
glyphs, a common case with, for example, chinese/japanese/korean languages). The new
approach packs glyphs vertically as well as horizontally to use the space more efficiently
and provide space for more glyphs in these situations.
Change-Id: I84338aa25db208c7bf13f3f92b4d05ed40c33527
when config_showMin3G is enabled to true in a CDMA device
Change-Id: I79a4fa200dc406fc7f9f4527165046541961ef69
Signed-off-by: Madan Ankapura <mankapur@sta.samsung.com>
- Fixes a strict mode violation, defers file validity checks
to when the engine starts synthesizing audio.
- Fixes some log spam when done() is called twice.
bug:6215680
bug:5415258
Change-Id: I4001be848b5208422d4091b7398e94ed311c649f
Will be seen when createStreamingAudioTrack() returns null,
which will happen if the audioflinger / audiomanager are unhealthy.
Also removes some confusing synchronization from this class.
bug:6636401
Change-Id: Iaf68a305665b7bc973898145e9cd1563e2569a2b
For now only the device owner "user" gets cloud backups. Also, only the
device owner account has access to local backup/restore.
Bug 6956438
Change-Id: I87d7ba5969e606c23f4214469f9bf2fd47a6c61b
Get rid of duplication between find/retrieve service funcs; when
a service in a persistent process crashes, restart it immediately
since the persistent process is going to be immediately restarted
anyway; when a new process is attaching, immediately restart any
services associated with it that are waiting to restart, since
it is weird to not let them run if the process comes back for some
other reason.
Change-Id: Id087fe04ebf2b6a4bd00732796c8326364765ea7
A long time ago, we had a concept of an "empty" process -- this was
a process that didn't have any interesting components in it, which
would be placed below everything else in the LRU list.
Empty processes didn't work out well, because you could get into
bad situations where you have filled your LRU list with things that
have hidden activities, pushing empty processes to the bottom and
being immediately killed as soon as they go into the list. So this
was removed.
This change brings the concept back, but in a slightly different
form, to address a more specific problem: for people who are switching
between N different applications, we would like to try to keep those
activities available in RAM in a consistent manner. Currently the
previous activities would be killed often quickly and suprisingly,
even on devices with lots of RAM. This is for two reasons:
(1) As you sit in one application, other things going on in the
background will go to the top of the LRU list, pushing down the
previous apps you have visited, even though you aren't aware at all
of these other things executing.
(2) There is a hard limit on the number of background processes
(currently 16) after which they are killed regardless of the amount
of available RAM. This is desireable because if there is lots of
RAM we can end up with tons and tons of processes sitting around,
not really serving any purpose, but using up resources.
To improve the situation, we have again a concept of "empty" processes
but now it means one with no activities. Processes that aren't empty
but in the background list are called hidden. We maintain these as
two parallel lists, each getting half of the process limit: so with
a 16 process limit, you can have at most 8 empty and 8 hidden processes.
This allows us to consistently keep up to 8 recent applications around
for fast app switching; we will also keep around 8 other processes to
make it more efficient for background work to execute again if it needs
to.
Change-Id: Iee06e45efc20787da6a1e50020e5421c28204bd7
