This allows the camera service to hang onto the callback interface
until all callbacks have been processed. This prevents problems
where pending callbacks in binder worker threads are processed
after the Java camera object and its associated native resources
have been released.
Bug 1884362
The function is used to rebuild any caches associated with the bitmap.
In the case of purgeable bitmaps, this call ensures that the pixels
are decoded for drawing, and therefore prefetching techniques
implemented by callers can be leveraged.
* changes:
when we reset a paint, it should return to the state it was in when it was first created. for java, this means setting its text-encoding to UTF16...
The GPS engine needs the hostname for the secure SUPL case
and deferring the DNS lookup to the HAL might be helpful in the future
if the SUPL server is on a carrier's private network.
Signed-off-by: Mike Lockwood <lockwood@android.com>
In eventLoopMain we were correctly translating from unix events to dbus flags,
but a coding typo then gave the unix events to dbus. Fix this typo.
Also noticed that we were passing raw dbus flags to poll() in another area.
This did not cause any immediate problem, since POLLIN | POLLPRI is harmless
and we do not usually need POLLOUT. But fixed anyway.
This was causing the system server to quietly die. Naughty DBUS!!
Now you will just see errors in the log "DBUS connection disconnected"
on every DBUS call.
There is still the root cause problem of why the DBUS connection disconnects,
which is not addressed by this change.
Apps targeting Donut and newer will throw an exception.
We use a heuristic to determine whether an app is pre-Donut or not:
We take the address space's __progname, and use that as the application's
package name. For simple applications this is correct.
As of this change, LocalTransport is successfully propagating data changes from
the backup data format into a repository stored in /cache/backup/[packagename].
Each backup key gets a separate file there for ease of manipulation and testing.
The general semantics of BackupDataReader have been tweaked, too; it now just
returns simple "we're done with the data" when it hits the end, even if no
footer has been found, because on the writing side the footer isn't being
written. Also, reading an entity now merely requires a "big enough" buffer, not
an exactly-sized one.
This is all a work in progress, but this is at least working now for purposes of
this local transport.
Still to do: proper change vs deletion detection, as well as expanding the data
format itself to include necessary metadata etc.
and lower the threshold of bitmap size for using ashmem().
For the decoding logic, we now go through the "non-purgeable" path if isShareable is false,
irrespective of the value of the purgeable flag.
This allows content providers to use in-memory data to implement
ContentProvider.openAssetFile(), instead of just normal files
and sockets as before.
To test cross-process use of AssetFileDescriptors for MemoryFiles,
a test content provider and a client for it are added to
AndroidTests.
Fixes http://b/issue?id=1871731
This will reduce copying or pinning, depending on GC policies, which should
improve performance. See dalvik/docs/jni-tips.html#RegionCalls for more information.
Fixes http://b/issue?id=1887911
As reported in http://b/issue?id=1398215 MemoryFile did not
munmap(2) the ashmem region after closing it. This
causes the process to leak virtual address space.
This change fixes the problem by calling munmap(2) in
close(). The unmapping is done by a helper method deactivate().
The change also replaces the use of an int for the
file descriptor with a FileDescriptor object to
make sure that we keep track of when the file descriptor
has been closed. I chose to implement it this way because I
will need decativate() and a FileDescriptor object in an
upcoming change that allows sending MemoryFile file
descriptors between processes.
The change also adds a number of tests for the behavior
of close(). The testCloseRead() and testCloseWrite() fail
with the old MemoryFile implementation, and testCloseLeak()
causes a segfault. They all pass now.
This change is the first part of a fix for issue 1846343, :
- Added new enum values for input sources in AudioRecord and MediaRecorder for voice uplink, downlink and uplink+downlink sources.
- renamed streamType to inputSource in all native functions handling audio record.
A second change is required in opencore author driver and android audio input to completely fix the issue.
This eliminates the requirement that all sensors share a single file descriptor.
This, along with concurrent changes in other projects, fixes bugs b/1614524 and b/1614481
Signed-off-by: Mike Lockwood <lockwood@android.com>
JSR239 and android.opengl gl Pointer functions (glColorPointer, etc.)
now respect the current setting of the Buffer position.
This fixes a regression introduced when we started requiring the
Buffers passed to the Pointer functions to be direct Buffers.
Use java.text.DateFormat where possible, since that is already using
the CLDR data for the things it supports. Remove an unused date format
object from DatePickerDialog.
Add a new method for getting the standalone month names from applications,
although @hidden for now because it is an API change.
Pass the standalone month names down to native code in Time so that
tztime's strftime() can use them.
And then the bulk of the change: replace all the names for the months
and the days of the week, and AM and PM, and yesterday, today, and tomorrow,
with strings from CLDR. And replace several of the date format strings
with ones derived from CLDR, but reformatted to use strftime() style
instead of SimpleDateFormat style.
All these resource changes go into new donottranslate-cldr.xml files
and are removed from strings.xml so that they aren't part of the
normal translation process and the translators don't have to bother
with them (and risk messing them up).
* changes:
Check the size of the data to write for STATIC AudioTrack objects. Extracted actual writing from write jni function so it can be reused in an upcoming change.
This was always a documented restriction, but was not enforced by the runtime until now.
Until now, if you passed in some other kind of buffer, it would sometimes work, and
sometimes fail. The failures happened when the Java VM moved the buffer data while
OpenGL was still holding a pointer to it.
Now we throw an exception rather than leaving the system in a potentially bad state.
