Temporary fix until audio routing is refactored in Eclair release:
- centralized and synchronized all audio routing control in AudioService.setRouting()
- deprecated AudioManager.setRouting() and AudioManager.getRouting() methods
The previous implementation used a database for storing all of its state, which could cause
a significant amount of IO activity as its tables were updated through the stages of a sync.
This new implementation replaces that in-memory data structures, with hand-written code
for writing them to persistent storage.
There are now 4 files associated with this class, holding various pieces of its state that
should be consistent. These are everything from a main XML file of account information that
must always be retained, to a binary file of per-day statistics that can be thrown away at
any time. Writes of these files as scheduled at various times based on their importance of
the frequency at which they change.
Because the database no longer exists, there needs to be a new explicit interface for
interacting with the sync manager database. This is provided by new APIs on IContentService,
with a hidden method on ContentResolver to retrieve the IContentService so that various
system entities can use it. Other changes in other projects are required to update to the
new API.
The goal here is to have as little an impact on the code and functionality outside of
SyncStorageEngine, though due to the necessary change in API it is still somewhat extensive.
Copy 3.xml to 4.xml, and patch 4.xml to deal with the fact that
Config.DEBUG's value is no longer actually fixed. We don't want
to modify 3.xml directly, because it's the official cupcake API.
Update current.xml to reflect the differences between 3.xml and 4.xml
and to reflect the new deprecation states.
The deprecated fields should be @hidden if possible before the
next API release, but it can't be done yet because there are
SDK-linked platform apps that use some of the deprecated fields.
Signed-off-by: Dave Bort <dbort@android.com>
Merge commit '275555c8eb3fb5df6e7320873b88b77cdde85a9e'
* commit '275555c8eb3fb5df6e7320873b88b77cdde85a9e':
location: Add support for location providers outside of the system process.
Also added new permissions android.permission.INSTALL_LOCATION_PROVIDER
and android.permission.INSTALL_LOCATION_COLLECTOR to the public API.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '9a81736176f507489f262344b6e3d55bbe53be7c'
* commit '9a81736176f507489f262344b6e3d55bbe53be7c':
Add the ability to specify the onClick handler with XML. The new android:onClick attribute defines the name of the method in the Activity to invoke when the button is clicked. The method has to be public and get one View parameter.
Fixes conflicting attr IDs due to donut-to-master automerge.
As a side effect, it fixes the "Field android.R.attr.contentAuthority
has changed value from 16843373 to 16843374" error introduced by change
804.
Background:
I submitted two changes to donut that add new public attributes:
https://android-git.corp.google.com/g/Gerrit#change,795https://android-git.corp.google.com/g/Gerrit#change,796
This was fine in donut (though still waiting for build server to
finish), but when auto-merged to master it caused a new build breakage.
This was on top of existing breakage due to
https://android-git.corp.google.com/g/Gerrit#change,804
The problem is that there are now multiple attribute definitions with
identical IDs, as you can see at the bottom of:
https://android-git.corp.google.com/w/?p=platform/frameworks/base.git;a=blob;f=core/res/res/values/public.xml;h=becc90ef05481321c60301176b91ca7b4553a6d7;hb=master
This did not cause an automerge failure, since my new attributes were
in the "platform 4" section, whereas the new attributes in master were
in the "platform 5" section. It seems like the temporary solution
would be to change the resource IDs in "platform 5" to come after the
ones in "platform 4". But the next time someone adds an attribute in
"platform 4", we will have the same problem. Any ideas?
If this attribute is provided and true, the searchable activity will be
included in any global lists of search targets.
This is needed to support third-party suggestion providers in
global search. See http://b/issue?id=1819651
This lets the searchable activity specify the number of
characters needed to trigger suggestions. Before, this was
hard-coded at 0. This caused unnecessary querying of the
suggestion provider in cases where the provider does not
return suggestions for empty or short queries.
Also adjust based on comments:
+ changed service intent string to conform to usage guidelines
+ only publish the IBackupService binder when invoked with the right
intent action
+ docs tweaks
Also tweak the dataChanged() api to have the client supply a package name. We
don't necessarily TRUST this, but we use it to narrow the set of packages requesting
a backup pass, no longer blithely scheduling a pass for all packages associated
with the caller's uid.
This change adds a sketched outline of the backup system architecture, with
all of the major pieces represented other than client-side helpers for
specific types of data. IBackupManager and BackupService are public so that
we can write test apps against SDK-domain symbols from the outset.
What code exists in this change hasn't been tested and may crash. It's the
beginnings of the real implementation but of course is barely begun.
This is just plumbing. The Java APIs existed already, but there were no C APIs to hook the Java APIs
up to. Now there are C APIs, so we can call them.
Of course, whether or not the C APIs actually work when you call them depend upon the
capabilities of the active OpenGL driver, which must be checked at run time.
Also, while we're here, make the glGetString method static. It was always supposed to be static,
but was accidentally implemented as non-static, because the code was copied from the non-static
OpenGL ES classes.
This adds a static OpenGL ES API.
Here are the three commit messages for the original changes:
Clean up trivial Eclipse warnings and fix whitespace.
Added @Override to overridden methods.
Removed unused imports.
Converted tabs to spaces.
Removed \r characters from end-of-lines.
Add .gitignore file to ignore the .class files that are
generated when the "gen" script is run.
This is the 2nd commit message:
Improve glgen
+ gen script is really a bash script rather than a sh script,
so declare that to be true. (For example, it uses pushd,
which is a part of bash, but not a part of sh. Not sure
how this worked until now. Possibly gen was only run in
environments where /bin/sh was really bash.
+ Check the results of the java compile of the code generator,
and abort the script if the compile fails.
+ Turn on the bash shell option that guards against using
uninitialized variables in the script.
+ Remove the generated class files.
Refactor JniCodeEmitter into two classes: a general-purpose
JniCodeEmitter and a specific Jsr239CodeEmitter. The hope is
to use JniCodeEmitter as a base for emitting static OpenGL ES
bindings.
This is the 3rd commit message:
Add an Android-specific static OpenGL ES 1.1 Java API.
This change adds four new public classes that expose a static OpenGL ES 1.1 API:
android.opengl.GLES10
android.opengl.GLES10Ext
android.opengl.GLES11
android.opengl.GLES11Ext
Benefits:
+ The static API is slightly faster (1% to 4%) than the existing Interface based JSR239 API.
+ The static API is similar to the C API, which should make it easier to import C-based
example code.
+ The static API provides a clear path for adding new OpenGL ES 1.1 extensions
and OpenGL ES 2.0 APIs, neither of which currently have a JSR standard.
Example:
import static android.opengl.GLES10.*;
...
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Note that it is possible to mix-and-match calls to both the static and JSR239 APIs.
This works because neither API maintains state. They both call through to the same underlying
C OpenGL ES APIs.
Implementation details:
This change enhances the "glgen" "gen" script to generate both the original JSR239 and
new static OpenGL ES APIs. The contents of the generated JSR239 classes remained the same as before,
so there is no need to check in new versions of the generated JSR239 classes.
As part of this work the gen script was updated to be somewhat more robust, and to
work with git instead of perforce. The script prints out commands to git add the generated files,
but leaves it up to the script runner to actually execute those commands.
This change adds four new public classes that expose a static OpenGL ES 1.1 API:
android.opengl.GLES10
android.opengl.GLES10Ext
android.opengl.GLES11
android.opengl.GLES11Ext
Benefits:
+ The static API is slightly faster (1% to 4%) than the existing Interface based JSR239 API.
+ The static API is similar to the C API, which should make it easier to import C-based
example code.
+ The static API provides a clear path for adding new OpenGL ES 1.1 extensions
and OpenGL ES 2.0 APIs, neither of which currently have a JSR standard.
Example:
import static android.opengl.GLES10.*;
...
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Note that it is possible to mix-and-match calls to both the static and JSR239 APIs.
This works because neither API maintains state. They both call through to the same underlying
C OpenGL ES APIs.
Implementation details:
This change enhances the "glgen" "gen" script to generate both the original JSR239 and
new static OpenGL ES APIs. The contents of the generated JSR239 classes remained the same as before,
so there is no need to check in new versions of the generated JSR239 classes.
As part of this work the gen script was updated to be somewhat more robust, and to
work with git instead of perforce. The script prints out commands to git add the generated files,
but leaves it up to the script runner to actually execute those commands.
that ought to be exposed. Hid and deprecated the single-arg public
constructor for NetworkInfo, and modified a CTS test that was testing it.
Ran the android.net test package to make sure it still works.
Original author: ers
Merged from: //branches/cupcake/...
Automated import of CL 145980
It should be renamed to something more meaninful before being exposed.
Original author: jsharkey
Merged from: //branches/cupcake/...
Original author: android-build
Automated import of CL 146012
