710575 - INSTALL_FAILED_CONFLICTING_PROVIDER when installing a custom build

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mike Hommey [:glandium]]

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.

Comment 1

[Richard Newman [:rnewman]]

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.

Comment 2

[Mike Hommey [:glandium]]

It looks like my tree was just a few days too old. A build against current m-c does install properly.

Comment 4

[Richard Newman [:rnewman]]

blassey suggested (by opening a bug!) that this is still an issue.

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch

got review from rnewman on irc

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/b3785a681491

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/b3785a681491