| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| |
| |
| | |
* commit '36612112760df799ef89f7e324e5dfabd5ca0d2b':
Implement new social stream permissions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reading/writing social streams now requires READ_SOCIAL_STREAM or
WRITE_SOCIAL_STREAM permission. The special stream item insertion
that occurs on status update insertion is exempt from this
requirement.
Bug 5406886
Change-Id: I6a711d7f33b501e2c331c71684b2eb3a6bfd5ec5
|
| |
| |
| |
| |
| | |
Bug: 5316982
Change-Id: I2870778c8056468730d82794ddae90c74cab85fc
|
|\ \
| |/
| |
| |
| |
| |
| | |
ics-factoryrom
* commit 'ae94a710dbc0ea239277c25986e39ba53904c5fc':
Change Settings insert conflict to do an update.
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This was the behavior the Settings table had before (when uniqueness
was enforced by the primary key), and it was assumed by external
apps, including Twitter.
Bug 5336876
Change-Id: Iab792df6a5d31c780a33ddebabdb26c7768f373b
|
|\ \ \
| |/ /
| | |
| | | |
Change-Id: I17e4d57df3bb24388ca9ead92f9a40fc57bc0fd3
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rather than extending SQLiteContentProvider, the profile and contacts
providers now extend AbstractContactsProvider, which handles keeping
track of a thread-local transaction with awareness of what databases
have been enlisted in the transaction and whether it is being run in
the context of a batch operation.
This is intended to solve the issue of how the content provider can
manage transactions that operate across multiple databases without
risking deadlocks.
Bug 5320369
Change-Id: I08a7d518a3eae1b0bf438402d02f1f1d8e8df7b9
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
The URIs profile/photo and profile/display_photo can be used to load
the thumbnail and display photo (respectively) for the user's profile
entry.
Also had to move ContactDirectoryManagerTest to MediumTests because
the LargeTests are starting to crash due to the SQL memory issue
again.
Bug 5226635
Change-Id: I7bf9787b06a49bf59c758421552dc969e6c6907d
|
|
|
|
|
|
| |
Bug 5235737
Change-Id: Iec2ef8ada5b70e22e35b6912ab62e6e680309dc6
|
|
|
|
|
|
| |
The tests need to be aware of (and use) deferred snippeting.
Change-Id: Ib566a2884f445c0ff02d8968a9362717798aafb8
|
|
|
|
|
|
|
|
|
|
|
| |
Since data_set may be null, it can't be part of the primary key
for the table, so we need to re-create the table and add
provider-side protection from inserting duplicate settings
records.
Bug 5156004
Change-Id: I25ae53c5670087a116058f0daef5b06cb6ce372b
|
|
|
|
|
|
| |
Bug 5239627
Change-Id: I0c45baeaf6e3a1730760f49696e1f489ef22490f
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Bug 5250048
Change-Id: Ibb0daef7a089ec851a9201cfd4163173f713f839
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a problem with a status message being added to a contact's
update stream. The text contains an extra <p> tag, which leads to extra
newlines being rendered.
Bug: 5176548
Change-Id: I28854bf053508e63ac0345556129e82c9e7984cb
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also added support for raw_contact/#/stream_items/# URIs, which we
were returning on stream item inserts for a raw contact.
Bug 5239627
Change-Id: I32116b32f1ebd28f7c86d6dc7567fca8f7c7ff07
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This should help avoid running out of memory when running the test
suite.
Bug 5199245
Change-Id: Ibb2591c3f58777c680eba8f5a89a6cc01f09c198
|
|\ \
| | |
| | |
| | | |
number."
|
| |/
| |
| |
| |
| |
| |
| | |
number.
Bug: 5197612
Change-Id: Ia38f097e1e1e8ecad9c41a15d5c7593807d13571
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fundamentally, this works as follows:
1. A separate, structurally identical database is created for
storing profile data. The view columns for identifying whether
a contact or raw contact belongs to the user's profile are
initialized with constant values for each database.
2. Sequence numbers in the new profile database are set to a very
high value (MAX_LONG - MAX_INT) to designate an ID-space in which
profile data is stored. This is important for distinguishing
between contact and profile requests.
3. Contacts Provider URIs are divided into several sets, bucketed
automatically by a new profile-aware URI matcher.
- URIs that explicitly reference the profile.
- URIs that contain IDs (which may be in the profile ID-space).
- URIs that contain lookup keys (which may be a special profile
lookup key).
- URIs for insertion that may contain a profile ID as the parent
for the inserted record (in content values). These can't be
detected by the URI matcher by itself, so this mapping is
maintained in the provider.
By identifying whether a URI falls into one of these sets, the
contacts provider can efficiently determine whether the request
is intended for the profile database or contacts database.
4. The Contacts Provider holds onto two separate copies of the
following, one each for contacts and profiles:
- Database helper
- Transaction context
- Aggregator
- Photo store (the profile one uses a separate directory)
5. During any query/update/insert/delete/openAssetFile operation,
the URI (and content values, if applicable) are examined to
determine whether the operation is intended for the Contacts DB
or the profile DB. If intended for the profile DB, the provider
is switched (in a thread-local manner) to a profile mode, and the
operation is handed off to the profile provider. The profile
provider does a permission check, substitutes the profile database
as the active DB in the contacts provider, and continues the
operation in the Contacts Provider by calling the in-transaction
or local version of the operation, which does its normal
processing, but with everything pointing at profile-specific
databases, aggregators, etc.
6. If the operation isn't determined to be targeted to the profile
database, the provider is similarly switched (thread-locally) into
contacts mode, and the active DB is set to the contacts DB.
7. For batch operations, we only create a transaction for the
contacts DB initially. If any of the operations in the batch end
up targeting the profile DB, we start a transaction for the
profile DB. When the batch is finished, we check for that and
also commit the profile transaction if there were no errors.
Bug 5204577
Bug 5161066
Bug 5155743
Bug 5087853
Bug 5031883
Bug 5198777
Bug 5230140
Change-Id: Ic43a6625cbb6edf52ea076b084647fb0656e28e5
|
|
|
|
|
|
|
|
|
|
|
|
| |
These columns store additional information about the contact associated
with a call log entry and are needed by the new functionality present in
the call log.
This change matches the newly defined columns in
android.provider.CallLog.
Bug: 5101753
Change-Id: Ife45e7034af098bf0e1ca35d05bb389a2c47909a
|
|
|
|
|
| |
Bug: 5201809
Change-Id: Ie21abb12736715358dd33bc690269f51ae1e0944
|
|
|
|
|
|
|
|
|
|
|
|
| |
When status updates are added to the stream items, they need to be
converted to HTML. In the process, an extra new line was added at the
end of each of them.
This commit removed this trailing new line, so that the updates are
shown correctly in the UI.
Bug: 5193689
Change-Id: I223070eeb1439a8ffacbfb61d6e86355b14c68db
|
|
|
|
|
|
|
|
|
|
| |
NORMALIZED_NUMBER may become null when the number isn't able to be
parsed by the library (e.g. pager address). Current implementation
groups multiple numbers with null normalized values into one
result, which confuses users.
Bug: 5040732
Change-Id: I1ad7dfb72dbc5d239aa95a913d35c2d8dfe3167c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Switch from resource ids to names to prevent breakage on package upgrade
Bug:5135277
- Add SYNC1...SYNC4 columns to StreamItems and StreamItemPhotos
Bug:5119385
- Remove ACTION, ACTION_URI from Groups, StreamItems and StreamItemPhotos
(this reduces db size and prevents click intercepting)
Bug:5135808
- Add some raw-contact fields to the StreamItem and StreamItemPhotos query
Bug:5134081
Doing those changes in one block to prevent too many db upgrade steps
Bug:5135277
Change-Id: I1d1661c9a507d9efd4ef334fe21481097e820b7c
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For reference, the issue was occurring because the file descriptor
passed back to the caller is parceled immediately, which closes the
file descriptor on the provider side before it even gets to the
caller. The solution was to stop fiddling around with temp files
and just pass back a pipe instead - the provider then can simply
read the image content from the pipe and process it.
Bug 5156644
Change-Id: Ie210f65b5b8681524fed12a53df0c852fc951e5a
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since stream items text is HTML but status updates are text only,
convert the text to HTML when inserting a status update into the stream
items.
Bug: 5122642
Change-Id: I61e3d9802e527c6977e7d29660ffd137ae899dae
|
|/
|
|
|
|
|
|
|
|
|
|
| |
This change adds a geocoded location value to entries added to the call
log.
One limitation is that this is unaware of changes to the locale. We
needed to decide whether this is fine or if we should update the stored
geocode on locale changes.
Bug: 5129581
Change-Id: I2ad1b3fbd24491df2febf3e1fd615c16dd74398f
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since we perform our own permission check, uri permission check
done by the content resolver is not sufficient. Our implementation of
the content provider should also explicitly check for uri level permission.
This is needed to allow sharing of voicemail uri from the contacts app.
In a follow up change we will allow sharing of URIs only to those apps that has
ALL permission. Right now the provider definition does not allow sharing
of uri.
Bug: 4961053
Change-Id: I5af53ee76ea10fa5f45c8cdcb95c773cc7ad138e
|
|/
|
|
|
|
| |
Bug 5122027
Change-Id: I4c0c4dc3b8b9eedbca347929fe16893aa1630005
|
|
|
|
|
|
|
|
|
|
|
| |
The tests were broken in two areas following recent changes
- permission READ_WRITE_OWN_VOICEMAIL was renamed to ADD_VOICEMAIL in
the production code, but was not renamed in test.
- Two new synthetic fields DISPLAY_NAME and SIZE were added in the
production code but the expected num fields were not updated in the
tests.
Change-Id: I96c1997af8dadb5a95d7224b0364cf48e6244977
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The deletion of voicemail data for the uninstalled package is done
through a service. The PackageIntentReceiver just forwards the package
removal intent to the service after sanity check that the intent is
really for an uninstalled package.
The logic to check whether the intent should trigger a clean up is
repeated in VoicemailCleanupService as well. This provides an extra
safety net and and also lets the unit test cover this functionality.
Bug: 5056159
Change-Id: Id7315a1318d510b50878f26c2e0d380c1920ee4e
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For accounts without a data set, this should be handled automatically
when the account is added. But with data sets, we need to handle it
specially so that the profile raw contact ID reference has a row to
hang off of.
Other raw contacts or groups with a data set will have the account
record created in the background when the provider is initialized.
Change-Id: I24ea0c389c3bc839aee295f1297e2236c473d66f
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the uri handling simpler, as we voicemail uris can now only
be of item or dir and does not depend on the content.
This also avoids strict mode violation when getType is called from UI
thread.
There is no change needed in the contacts app because the URI mime type
is right now used by the app.
Bug: 5090052
Change-Id: Ie2e502f9b09465dc343e873d43e206aaad8b6076
|
|
|
|
|
|
|
|
|
| |
Modified MockPackageManager to stub checkPermissions. This method was
recently used in production code in
Change-Id: I20982572d7f9a08ce98b03b23c9d2d8aa60efc9f
but I missed to update the Mock. Consequently the tests now fail with
unsupportedoperation exception.
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: 5087645
Change-Id: Ib60353fd44c23566ae0d2cbaa695f5bbdfd26eb0
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent of the data set field is to provide a way for multiple
sync adapters from the same account name + type to manage separate
sets of data in the raw_contacts and groups table.
For example, this would allow for Focus groups to be synced in from
Focus via the Google Contacts sync adapter, and for Google+ Circles
to be synced in from the Google+ app, even though both are tied to
the same account name + type.
Bug 5077096
Change-Id: I641c5d233d8d4d70988d209179c4e79bdb9c7ea1
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change fixes two primary issues:
1) If a voicemail record is modified through call log provider, a
voicemail provider notification is now generated.
2) voicemail notifications are now sent with permission ALL if the
receiving component packages is not the owner of the modified record.
This ensures that a voicemail source (having OWN permission) gets notified
only of changes for records that it owns. But a package that has ALL
permissions get notified of everything,
A new interface DatabaseModifier is now used by both voicemail as well as
calllog provider to perform any operations that can modify the
underlying table. DbModifierWithVmNotification implementation of this
interface fires relevant notifications under the hoods.
All logic related to sending notifications is now moved from
VoicemailContentProvider to this new class.
bulkInsert has no special treatment anymore. We now fall back to the framework's
default implementation. It was complicated to optimize for provider_changed events
for bulk insert when using the DatabaseModifier interface.
TODO: I am yet to write unit tests for broadcast intents. I have done
manual testing to make sure that they work. Also the existing unit tests pass,
proving that none of the existing content provider operations are broken by
using the DatabaseModifier wrapper.
Bug: 5060354
Bug: 4974222
Change-Id: I0935105f146a71abeffbde634d79f8806b8e0ed2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We added the IS_READ column, so that we can distinguish between items
that are new and items that have not been read (or heard, for
voicemail).
However, there is no reason to expose the NEW status of voicemail, since
that is about whether the user should be notified and it is handled
entirely by the content provider and Contacts application.
This is part of the changes needed to fix notifications for voicemails.
Bug: 5036195
Change-Id: I74d760a73d5ffbbb6eb26f2dbe7c7ca2a92ad2d6
|
|/
|
|
|
|
|
|
| |
A recent change added a new 'IS_READ' field into the content provider but
this test was missed to be updated for the number of columns expected
out of the content provider.
Change-Id: I03885e2b2ac827fe04e06e528e9ffd51823004ee
|
|
|
|
|
|
|
| |
Also add unit test for it
Bug: 5073384
Change-Id: I7fa41f50883e14a84ef95d2b098379b1d6b47bae
|