/e/ upstream default Apps re-installed.. why? bc!

[tcecyk]

well known, anybody can use /e/'s current sync story on normal Stock ROMs: DAVx5, Etar, Opentasks, Nextcloud Notes, Nextcloud itself. Makes for an easier transition too for people considering a switch. I sometimes do this with family phones for the Addressbook/Calendar, not wanting to interfere with the rest of it.

(!) This was made in a just-for-fun mood and is no recommendation, as post-fork the integration in /e/ is much nicer - the visual language in aggregate and from an OS perspective. I prefer it the /e/ way. Forking is about control with pro/cons (!)

Anyway, what does it look like if you use upstream packages instead ? I needed to take some liberties with aosp Apps (gallery, contacts/dialer…) or Maps, but true in spirit. Here’s the comparison (slightly doctored for image height) on /e/:

I used to strip stock-roms of all components (it’s a sport) and replace with F-Droid / opensource only apps. I did this script driven for quick turn around. I applied that to the upstream appids of /e/ default apps.

Preptime:

apt install fdroidcl
fdroidcl defaults
cat  ~/.config/fdroidcl/config.json | jq '.repos += [{"id": "bromite-repo", "url": "https://fdroid.bromite.org/fdroid/repo", "enabled": true}]' > ~/.config/fdroidcl/config.json
fdroidcl update
fdroidcl devices
wget https://f-droid.org/F-Droid.apk
adb install F-Droid.apk

Apps

while read -r line; do
  package=${line%% #*} 
  echo "installing: https://f-droid.org/en/packages/$package"
  fdroidcl install "$package"  
done <<<'foundation.e.blisslauncher # Launcher: BlissLauncher
at.bitfire.davdroid # AccountManager: DAVx5 (carddav)
it.niedermann.owncloud.notes # Notes: Nextcloud Notes (webdav)
ws.xsoh.etar # Calendar: Etar (caldav)
org.dmfs.tasks # Tasks: Opentasks (caldav)
com.fsck.k9 # Mail: k9mail (imap) 
org.sufficientlysecure.keychain # Keys: OpenKeychain
com.moez.QKSMS # Message: qksms
org.thosp.yourlocalweather # Weather: your-local-weather (qqq3 fork successor, removed nowadays anyway)
net.sourceforge.opencamera # Camera: Opencamera
org.documentfoundation.libreoffice # Office: LibreOfficeViewer
com.gsnathan.pdfviewer # Pdf: PdfViewerPlus
org.bromite.bromite # Browser: Bromite
com.chen.deskclock # Clock - older aosp fork
com.xlythe.calculator.material # Calculator - old aosp fork
ch.blinkenlights.android.vanilla # Music - aosp/lineage derived
com.nextcloud.client # the cheating begins.. Sync: Nextcloud (webdav) - not in /e/ actually
com.dimowner.audiorecorder # Recorder - not aosp
me.zhanghai.android.files # Files - not aosp "Material Files"
us.koller.cameraroll # Gallery - not aosp
app.organicmaps # Maps - absolutely unrelated
com.simplemobiletools.dialer # Dialer .. simplemobiletools are spiritual siblings :)
com.simplemobiletools.contacts.pro # Contacts'

While fumbling, why not applying it to a Lineage too? closer to the truth as lineage brings the AOSP apps already.

while read -r line; do
  package=${line%% #*} 
  echo "installing: https://f-droid.org/en/packages/$package"
  fdroidcl install "$package"  
done <<<'foundation.e.blisslauncher # Launcher: BlissLauncher
at.bitfire.davdroid # AccountManager: DAVx5 (carddav)
org.sufficientlysecure.keychain # Keys: OpenKeychain
it.niedermann.owncloud.notes # Notes: Nextcloud Notes (webdav)
ws.xsoh.etar # Calendar: Etar (caldav) .. though already used as calendar on lineage
org.dmfs.tasks # Tasks: Opentasks (caldav)
com.fsck.k9 # Mail: k9mail (imap) 
com.moez.QKSMS # Message: qksms
net.sourceforge.opencamera # Camera: Opencamera
org.documentfoundation.libreoffice # Office: LibreOfficeViewer
com.gsnathan.pdfviewer # Pdf: PdfViewerPlus
org.bromite.bromite # Browser: Bromite, dl at https://github.com/bromite/bromite/releases or use f-droid repo https://www.bromite.org/fdroid
com.nextcloud.client # Sync: Nextcloud (webdav) - not in /e/ actually'

Forking is a topic of obsession to me, as I know how hard it is to upstream patches (orthogonal project missions), rebasing bugfixes or translations done downstream.

Defaults matter, I hope the xda/lineage/aosp communities can cooperate and not get caught up in partisan feuding. I do benefit from the efforts of the other AOSP/lineage distributions.

[chrisrg]

Nice. But what happened to planet earth?

[petefoth]

I prefer to use upstreams rather than forks where I can. In my opinion, in most cases, forks add a maintenance cost which is rarely worth any perceived benefit, as well as often lagging behind the upstream in bug fixes and new features.

So I make a custom /e/ build for my ‘daily driver’ device (Sony Xperia Xz1 Compact), which replaces most of /e/'s forked apps with the upstream: K-9, QKSMS, ETAR. It also includes

• Fennec (Firefox-based browser) instead of /e/'s Bromite fork (because it supports Firefox sync)
• F-Droid and Aurora Store instead of Apps
• Omega and Lawnchair launchers in addition to Bliss
• the Stock Sony Camera app instead of /e/'s Camera

The next version may include NextCloud Notes instead of /e/'s fork

[tcecyk]

yes I need to source that wallpaper… ran out of effort… good that I’m not a perfectionist I could’ve never made the post then

[chrisrg]

Ignore me. I’m just kidding.

[tcecyk]

individually there always is a better App… /e/ team acknowledges this in their roadmap to make default apps removable. This is a never ending discussion - and rightly so, defaults can change over time. I think they made good choices in which Apps they forked at the time.

forks add a maintenance cost which is rarely worth any perceived benefit, as well as often lagging behind the upstream in bug fixes and new features

true of course, I worry about it and hope with good tooling and rebasing kungfu they can lift the burden … from swiping through my Gedankenexperiment of “use-the-forks-luke” I think the result of the burden is worth it. I became homesick for /e/-v0.18 streamlined colors ui.

App developers do not have that perspective, they want to create the best app in isolation. I understand there is no incentive to harmonize with functional unrelated Apps. It would be hard to make involve them in cross-project merges for your use-case. Only from the OS perspective do you begin to care and this is why I think it great for /e/ having focused on this dark-mode / accent-colors effort the last releases.

[chrisrg]