Closed
Bug 1182442
Opened 8 years ago
Closed 7 years ago
Need a way to update distribution files post first install
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(p11+, fennec-)
RESOLVED
WONTFIX
People
(Reporter: krudnitski, Unassigned)
Details
Attachments
(4 files)
Reasoning: Distribution files are unpacked once during first-run, then the browser ignores any new distribution files that may be bundled with an APK. The only way a user could get new distribution file settings would be to uninstall and re-install. However, there will be instances when a partner's search code may need changing or an add-on removed or replaced (such as an updated home panel with new static URLs). There could also be instances of bookmark URLs changing or wanting more granularity on metrics with a new Partner ID. However, some files should likely be ignored so as not to 'modify' an existing user's browser settings, unless some really crisp UX is inserted (but we could likely assess this at a later stage if deemed needed). Requirement: * Be able to over-write (at least some) distribution files post install (whether by OTA or by pre-installation) * Updates to the following files would be seen as definitely required: ** Search provider (updating search code / favicon, not changing the user's default) ** Add-ons * Updates to the following files would be seen as nice-to-have: ** Bookmarks ** Partner ID * No update would be wanted (ie ignore these bits) for: ** First-run thumbnails ** Preferences Putting this in a bug for discussion to figure out what's possible before turning this over for a break-down.
Reporter | ||
Comment 1•8 years ago
|
||
I tweaked the requirements a bit and included user stories in the Aha Feature Card: https://mozilla.aha.io/features/6169843846517514115
Comment 2•8 years ago
|
||
Be warned: some bits of this might get hairy. So to take a step back: is bundling a replacement distro with a newer version of the APK the best way forward? Don't we expect most users to start with a distro APK then migrate onto a vanilla Play APK? Is this mechanism intended for OTA partner OS upgrades with bundled Firefox? Would it be better to define an add-on based way of doing this? That'll be able to make changes for all users who ever started with that distro, not just ones that are willing to install another 35MB APK. Feel free to grab some time on my calendar if you think it'll help to talk this through.
Comment 3•7 years ago
|
||
This is something we may try to target for 45. Richard, let's find a time to get together with product to talk about the details of what's possible here.
tracking-fennec: --- → ?
Reporter | ||
Comment 4•7 years ago
|
||
Some further comments and honing in on actual requirements have been made in the Aha feature card here https://mozilla.aha.io/features/6169843846517514115. There is no preconceived notion on how best to implement this, provided it gives us the ability to modify / add certain components of the distribution when a distro is 'in the wild'. I think some of the funnel review should be spent discussing this one, if we could!
Comment 5•7 years ago
|
||
Karen - I want to push back on this bug. I don't think this is a priority and would rather WONTFIX this until we have a very explicit need. Changing the homepage can be done by the partner by just redirecting. I'd rather spend time working on other features.
Flags: needinfo?(krudnitski)
Reporter | ||
Comment 6•7 years ago
|
||
Scope has reduced a bit (and detailed in the Aha card as per comment 1). Not worried about how it's done, provided there could be a mechanism. We need this for a vetted viable opportunity.
Flags: needinfo?(krudnitski)
Comment 7•7 years ago
|
||
Looking at the Aha card, we know that partners use PartnerBookmarksProvider [1] to get bookmarks to appear in Chrome. These seem to be loaded from a combination of resources and a flat file [2]. These can only be updated via a firmware update. No OTA updates here. We could consider using a similar approach where we create dynamic bookmarks from a file in the system distribution folder. Those would be displayed in the application like normal bookmarks but could not be edited or deleted, sadly. They would be updated any time the system distribution folder is updated. I would love to know if Chrome displays these bookmarks as top level bookmarks, or if they are shown in a folder. [1] http://androidxref.com/6.0.0_r1/xref/packages/providers/PartnerBookmarksProvider/ [2] http://androidxref.com/6.0.0_r1/xref/packages/providers/PartnerBookmarksProvider/src/com/android/providers/partnerbookmarks/PartnerBookmarksProvider.java
Updated•7 years ago
|
Assignee: nobody → s.kaspari
tracking-fennec: ? → 45+
Comment 8•7 years ago
|
||
Bug 1182442 - (Part 1) Save version of distribution. r?
Comment 9•7 years ago
|
||
Bug 1182442 - (Part 2) Detect distribution updates. r?
Comment 10•7 years ago
|
||
Bug 1182442 - (Part 3) Update preferences from distribution. r?
Comment 11•7 years ago
|
||
Bug 1182442 - (Part 4) Update or insert bookmarks from distribution. r?
Comment 12•7 years ago
|
||
This is my current set of patches. I can update bookmarks and Android preferences for a distribution. However I'm having a hard time to update favicons in a batch operation. I can't update existing favicons because they might be used by other distribution bookmarks (deduplication) or the new guessed(!) favicon URL is already used (unique constraint). Even if I do not use batch operations and query/insert/update manually then I still have to handle somehow updating a favicon that might be used by multiple distribution bookmarks: Bookmark A - Favicon X -> Bookmark A - Favicon K Bookmark B - Favicon X -> Bookmark B - Favicon X In this situation I can't update Favicon X because it's used by Bookmark B too. I can't insert Favicon K because the ContentProvider will guess a favicon URL and it will be the same like Favicon X -> UNIQUE constraint fails.
Flags: needinfo?(rnewman)
Flags: needinfo?(mark.finkle)
Flags: needinfo?(margaret.leibovic)
Comment 13•7 years ago
|
||
Actually a variation of this issue can already happen at first-run - without distribution updates: Bookmark A: http://www.example.org/ - Favicon X Bookmark B: http://www.example.org/news - Favicon Y Inserting the favicons fail because for both favicons we guess the favicon URL to be http://www.example.org/ and run into the UNIQUE constraint failure. The bookmarks will be inserted but will have the default favicon.
Comment 14•7 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #13) > because for both favicons we guess the favicon > URL to be http://www.example.org/ and run into the UNIQUE constraint > failure. This should be http://www.example.org/favicon.ico of course.
Comment 15•7 years ago
|
||
https://reviewboard.mozilla.org/r/25961/#review23421 ::: mobile/android/base/distribution/Distribution.java:948 (Diff revision 1) > settings = GeckoSharedPrefs.forApp(context); Will it cause problems that we're currently saving distribution preferences per app instead of per profile? In the short term, it probably won't cause any problems, but technically it's not correct, since we're doing things like writing the bookmarks into a DB in the profile.
Comment 16•7 years ago
|
||
https://reviewboard.mozilla.org/r/25965/#review23423 ::: mobile/android/base/distribution/Distribution.java:475 (Diff revision 1) > + update(); This could have problems if `runReadyQueue` depends on an updated shared preferences state, since we post a runnable in `update`. Probably not an issue for the homepage pref, but something to consider if we're supporting more in the future.
Comment 17•7 years ago
|
||
I was going to point you at testDistribution, but I don't see any current test coverage there for bookmarks... However, it probably wouldn't be that bad to add a testcase that does a DB query to see if the bookmarks ended up where they should. I'm not sure how hard it would be to add a test for this update path, but it would certainly be nice to have one. Right now we include a .zip file with a dummy distribution directory in the test assets, and we use that to create a test distribution. Maybe we could add a second test asset, and point our update logic at that to see if it works.
Flags: needinfo?(margaret.leibovic)
Comment 18•7 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #12) > This is my current set of patches. I can update bookmarks and Android > preferences for a distribution. > > However I'm having a hard time to update favicons in a batch operation. I > can't update existing favicons because they might be used by other > distribution bookmarks (deduplication) or the new guessed(!) favicon URL is > already used (unique constraint). > > Even if I do not use batch operations and query/insert/update manually then > I still have to handle somehow updating a favicon that might be used by > multiple distribution bookmarks: > > Bookmark A - Favicon X -> Bookmark A - Favicon K > Bookmark B - Favicon X -> Bookmark B - Favicon X > > In this situation I can't update Favicon X because it's used by Bookmark B > too. I can't insert Favicon K because the ContentProvider will guess a > favicon URL and it will be the same like Favicon X -> UNIQUE constraint > fails. I would not worry about favicons. If the user visits the bookmark ever, I think (hope?) that we update the favicon. And in practice, I don't think the favicon is likely to change in an update anyway. (In reply to Sebastian Kaspari (:sebastian) from comment #13) > Actually a variation of this issue can already happen at first-run - without > distribution updates: > > Bookmark A: http://www.example.org/ - Favicon X > Bookmark B: http://www.example.org/news - Favicon Y > > Inserting the favicons fail because for both favicons we guess the favicon > URL to be http://www.example.org/ and run into the UNIQUE constraint > failure. The bookmarks will be inserted but will have the default favicon. Let's file a separate bug for the favicon problems. We can land that patch separately, since it's less important to have that ready for uplift.
Updated•7 years ago
|
Status: NEW → ASSIGNED
Flags: needinfo?(rnewman)
Version: Firefox 41 → Trunk
Comment 20•7 years ago
|
||
*finger hovers over WONTFIX*
Comment 22•7 years ago
|
||
This doesn't need to track anymore. mfinkle, can we WONTFIX this?
tracking-fennec: 45+ → -
Flags: needinfo?(mark.finkle)
Comment 23•7 years ago
|
||
(In reply to :Margaret Leibovic from comment #22) > This doesn't need to track anymore. > > mfinkle, can we WONTFIX this? Yes. Done.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mark.finkle)
Resolution: --- → WONTFIX
Assignee | ||
Updated•2 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•