[Extensions] Allow installation of locally downloaded extensions/addons

[DevPika]

Related to #22
This PR adds a Developer Setting to Allow installation of locally downloaded extensions.

Flow:

1. User enables Developer Option to Allow local addon installation (Settings > Developer Options > "Allow Installation of Local Addons")
2. User downloads .xpi file from the extension's website
3. User clicks on the corresponding entry in the Download Manager
4. The addon is installed and enabled

The installation flow for a LocalExtension is quite different from a regular addon. The primary difference is that for local extensions, we do not have an "Addon" class instance available prior to installation when we refresh our addons list, as info related to that is populated from the extension manifest only after installation. So the local addon installation needs to happen similar to how BuiltInExtensions are installed in the existing code.

Installation workflow difference:

For regular addons (flow already exists):

1. Get list of Addons
2. User presses the + icon for installation
3. ...UI Confirmations for download and install...
4. Install method requires passing an existing instance of Addon
5. All registered listeners receive onAddonsUpdated through notifyListeners in the same file

For local addons (added through this PR, similar to BuiltInExtension):

1. User clicks on downloaded addon
2. Extension installed through WolvicWebExtensionRuntime, not through AddonManager
3. All registered listeners receiveonAddonsUpdated through notifyListeners, but this time inside LocalExtension class after installation is done

I searched through FirefoxForAndroid codebase and GeckoView API, but could not find a way to construct an Addon object from xpi file before installation. A possible change in workflow can be to register to installPrompt call, but I wasn't sure how to integrate that deeply into GeckoView. So I kept the changes straightforward for now

TODO

• Dialog / toast message to show success/failure of local addon installation instead of a silent install
• Tests for the feature?
• Fixed - Rating Bar and Icon were incorrectly assigned for fresh installation of local addons, now custom/default icon is shown and rating bar gets hidden if no info
• What happens when "same" extension clicked multiple times? Seems to only get installed once currently.
• Update Addons List as soon as addon installation complete
• Fix addon showing up in the Disabled section even though Enabled. This is because of AddonManager code in AC 75.0.22, which provides list of addons, ignores installedstate and forces enabled = false Fixed by updating list with correct state and adding a new section "Experimental"

[DevPika]

I am opening a draft PR for feedback and suggestions

[svillar]

This is really cool. I'm pretty sure extensions devs will love it. I just have some nits here and there, but overall looks great

[DevPika]

Thank you so much for your review! I have tackled all of the comments and some of the TODOs, for the remaining TODOs I am not very sure how to proceed. I am not expecting to make any major changes so I have marked the PR as Ready for Review.

[DevPika]

I have made the requested changes and added some supporting features like having the addons in an "Experimental" section and showing their correct enabled/disabled state. I have marked the previous comments as resolved and requested a re-review

[DevPika]

I was able to fix the bugs related to incorrect data being shown in the rating bar and icon for new addons. The PR seems pretty complete after these fixes.

[svillar]

We're almost there. Fantastic job!

[svillar]

I have finally the chance to test this and it works great to me. I've a last request though (thanks for your patience), it'll be difficult, even for devs, to realize that they have to enable the setting in developer mode in order to be able to install local extensions. The current situation is that, if the switch is disabled, Wolvic will complain about "unsupported filetype", I'd very much prefer to show a dialog informing the user about the switch. Could we add that?

I've also found a bit ankward the "silent" installation process. I've just seen that it's in your radar, so I'm fine landing this without that feature and do it in a followup.

[DevPika]

Thank you so much for your quick and helpful feedback and patience throughout! I have added two dialogs: one for blocked installation (with an explanation of where the toggle to enable is present), and another for confirming installation of addon. Please let me know if you have any further suggestions and feedback!

[svillar]

I'm quite happy with the final result. I just have a question before merging it. I've downloaded several xpi from https://addon.mozilla.org and after installing them, none of them displays their actual icon in the addons list. All of them get a white square one, is that expected?

I checked the addon.iconURL field for the local addons and it's always null, is it because that info is retrieved by Mozilla's android components from the web and is not part of the .xpi?

[DevPika]

I checked the addon.iconURL field for the local addons and it's always null, is it because that info is retrieved by Mozilla's android components from the web and is not part of the .xpi?

Yes, this was the issue. I have made some changes now so that the locally available icon from the manifest is loaded if the web icon fetch doesn't work (similar to correcting the enabled state in abab3d4). Thanks for looking into this!

I tried the changes with some of the recommended addons on AMO homepage, for some reason the Tomato Clock addon's icon doesn't load, all the others I tried seemed fine after the changes. Warning for Tomato Clock:

org.mozilla.geckoview.Image$ImageProcessingException: Could not process image: 0x80004005
	at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method)
	at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:677)

I wasn't able to find the cause though, mentioning it here for future reference in case this crops up for any other extensions.