Closed Bug 710575 Opened 8 years ago Closed 8 years ago

INSTALL_FAILED_CONFLICTING_PROVIDER when installing a custom build

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: glandium, Assigned: blassey)

References

Details

Attachments

(1 file)

This happens when a nightly is also installed.

I could work around the issue with the following patch:

diff --git a/mobile/android/base/AndroidManifest.xml.in b/mobile/android/base/AndroidManifest.xml.in
--- a/mobile/android/base/AndroidManifest.xml.in
+++ b/mobile/android/base/AndroidManifest.xml.in
@@ -139,9 +139,9 @@
                   android:label="@string/preferences_title"
                   android:excludeFromRecents="true"/>
 
         <provider android:name="org.mozilla.gecko.db.BrowserProvider"
-                  android:authorities="org.mozilla.gecko.providers.browser"
+                  android:authorities="org.mozilla.gecko.providers.browser_unofficial"
                   android:exported="false"/>
 
     </application>
 </manifest> 
diff --git a/mobile/android/base/db/BrowserContract.java b/mobile/android/base/db/BrowserContract.java
--- a/mobile/android/base/db/BrowserContract.java
+++ b/mobile/android/base/db/BrowserContract.java
@@ -39,9 +39,9 @@ package org.mozilla.gecko.db;
 
 import android.net.Uri;
 
 public class BrowserContract {
-    public static final String AUTHORITY = "org.mozilla.gecko.providers.browser";
+    public static final String AUTHORITY = "org.mozilla.gecko.providers.browser_unofficial";
 
     public static final Uri AUTHORITY_URI = Uri.parse("content://" + AUTHORITY);
 
     public static final String DEFAULT_PROFILE = "default";

I guess we could do something like what has been done for the android package name.
Well, this looks like it might answer part of Bug 710407, anyway: Android won't let you get into that situation :)

Thanks for the report!

Note that your workaround, Mike, could leave consumers of the content provider -- including Sync -- talking to the 'wrong' Firefox profile, because the other provider would be the one listening for the URI that Sync users. (Separate modules won't necessarily be using your definition of AUTHORITY, because that value is part of the documented interface, not looked up at runtime. The CP is _how_ runtime lookup happens!)

Depending on how Android accounts work, this could lead to two different Sync installations syncing to the same database (which is not what I'd describe as a supported scenario!), or failing to find the database at all. Neither is good.

The outcome of Bug 710407 dictates whether any situation like this can be allowed for installations with Sync enabled. If the SyncAdapter that handles a given account isn't predictable, regardless of CP URI, then we mustn't get ourselves into that situation.

Needs more thought.
Blocks: 710407
It looks like my tree was just a few days too old. A build against current m-c does install properly.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Duplicate of this bug: 711188
blassey suggested (by opening a bug!) that this is still an issue.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached patch patchSplinter Review
got review from rnewman on irc
Assignee: nobody → blassey.bugs
Attachment #582080 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/b3785a681491
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
You need to log in before you can comment on or make changes to this bug.