It is nicer to make sure the screen stays on while we are shutting
down, so the screen goes off when we are actually complete rather
than some time before.
Change-Id: I8725ac9884df6d21344f35288da3e375d9779b3b
- fix a bug when hacking video buffers into gralloc buffers
where the buffer size was incorrect this was causing the
"direct-form-texture" mode to fail
- also when the above fails, make sure to revert to the
"mdp copy mode" before going to "slow mode"
- finally disable completely the "direct-from-texture" mode
for now. It cannot work because the allocated buffers can't
respect the GPU constraints (alignment and such). We'll
have to find a solution for that.
a bug in maintaining the cache caused these warnings. when the cache
is full, caching code in SQLiteDatabase dropped an entry from the cache
to accommodate the new one. and if the just-dropped one is not in use
that object got GC'ed and caused a finalizer warning. Calendar is one app
that didn't use ? for bindargs (sometimes) and noticed this bug in that app
Fix is to not add the new enry to cache if the cache is already full.
that will cause the app's close() to release the entry.
another common case where this finalizer warning occurs is when unittests run.
if the test does not close the database in tearDown(), it will cause
database object and the compiled sql statement cache within the database
obj get GC'ed which cause finalizer warnings.
Currently, the regex used to extract the port matches ':' followed by 1 or more
digits. This means that when passed a malformed URL of type <host>:<path>, no
match is made for the port and the ':' is matched as part of the path. Since the
handling of the path adds a leading '/' where absent (see http://b/1011602),
this leads to the URL being converted to <host>/:<path>.
This change updates the port regex to match ':' followed by zero or more digits.
This means that the ':' is always matched, so it does not leak into the path
and the result is <host><path>. This matches the behavior of desktop browsers.
Bug: 2494876
Change-Id: I34b47c8187cf03aa7674c14cd6593de53dce3169
It is a prt of the following bug fix: http://b/issue?id=2478548
The CL adds the ability to pass HTTP headers to the Browser
Change-Id: Ibf0ad8f678fc5aeef4ac098e5dfbcaed9ada8600
Update the cookie parser to correctly detect "a=b" cookies and add comments.
Also change the comparator to compare null values before the name so that all
cookies with null values come after cookies with values.
Also added a cts test in cts project.
Bug: 2487245
Only the system can enable the car mode and the system should
already have appropriate permissions.
But since we wanna allow all other apps to disable the car mode
again, we don't want to enforce them to specify the DISABLE_KEYGUARD
permission in their manifest.
Change-Id: I1ad244a98d65b7193ea9817bff8406cfc2bce6f3
For each location provider, call getInternalState() to see if it has any
state information to include in a bugreport. If the returned string is not
null, then print a header with the provided name followed by the returned
string.
Change-Id: I0a388d7fba14ac8cadcb80eda0a0ceb95032410b
Signed-off-by: Fred Fettinger <fred.fettinger@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
This works around a bug in the
"Q3Dimension MSM7500" driver. That driver only
supports a single active EGLContext, so we must
release and restore the EGLContext when pausing
and unpausing.
Unfortunately the test for deciding whether to
release the context was inverted. We were
releasing the context on every device besides
the MSM7500 devices, which was a performance
drain, and we were not releasing the context on
the MSM7500, which meant the underlying driver
bug was not worked around.
Now we release the EGL context when pausing only
on the devices that have the bug.
The DatePickerDialog in the Settings application is not updated correctly if you follow
the following step-by-step:
1. Enter Date option in settings application
2. Modify the values of the date, then cancel the changes
3. Once again enter the date option
and you can see that the title in the dialog has not been updated correctly. This is
due to a missing call to onDateChanged callback in the DatePicker class. Solution was
to add the notify call when updateTime has been called.
