Trebuchet (the launcher) contains a proprietary tracking solution

[mar-v-in]

Tracking and reference to ambient sdk, a proprietary library by Cyanogen Inc., was added with commit https://github.com/CyanogenMod/android_packages_apps_Trebuchet/commit/90106d85b75a60a8bdc9c4ad891e4a2e7ce548dd

[nvllsvm]

AFAIK, the only option here is to have the script remove Trebuchet. Though that would potentially leave some without a functioning system.

Two options come to mind:

• Make the user responsible for having another launcher installed.
• Package a free launcher with the script.

As a safe guard, there might be a way for the script to verify that another launcher is installed before removing. I'm not aware of how to do this.

Taking suggestions. I'm leaning to providing two versions of the script:

• A release containing an alternative launcher and potentially browser ( #23 ).
• A minimal, remove-only script that does not contain alternative apps.

[mid-kid]

Unfortunately, the launcher doesn't seem to be the only app subject to this.

AudioFX: https://github.com/CyanogenMod/android_packages_apps_AudioFX/blob/cm-13.0/Android.mk#L25 Contacts: https://github.com/CyanogenMod/android_packages_apps_Contacts/blob/cm-13.0/Android.mk#L25 ContactsCommon: https://github.com/CyanogenMod/android_packages_apps_ContactsCommon/search?utf8=%E2%9C%93&q=com.cyanogen.ambient&type=Code ContactsProvider: https://github.com/CyanogenMod/android_packages_providers_ContactsProvider/blob/cm-13.0/Android.mk#L34 Dialer: https://github.com/CyanogenMod/android_packages_apps_Dialer/blob/cm-13.0/Android.mk#L47

The worst part however is that while it's fairly easy to remove ambientsdk in both Trebuchet and AudioFx, given you obtain the source and build them yourself, it's pretty deeply woven into Contacts{,Common,Provider} and Dialer.

[nvllsvm]

Sigh, this is what I've feared. I've since considered switching to CopperheadOS, though the fact that it only supports a small number of Nexus devices is off-putting.

Anyway, I'm curious if those apps could be forked and made standalone. Much like how I prefer Etar (from F-Droid) to the included calendar app in CyanogenMod, I would want these apps to be decoupled from the ROM itself.

[mid-kid]

I'm not sure what would be the advantage of having these apps be standalone. If you want to redistribute an update zip with prebuilt, patched versions, I think there are methods to do that reliably in-tree. After an hour of trying to untangle Contacts and Dialer, I gave up. Apparently there's some plugin interface that depends on ambientsdk, and that is scattered all over the place. I think building the AOSP version of those might be a better idea.

[nvllsvm]

After an hour of trying to untangle Contacts and Dialer, I gave up. Apparently there's some plugin interface that depends on ambientsdk, and the hooks for that are scattered all over the place, sometimes even replacing the old functionality. I think building the AOSP version of those might be a better idea.

Exactly my point in making them standalone apps. You shouldn't have to untangle ROM-specific changes from an app. IMO, I want a ROM to provide the bare minimum in terms of an Android experience. Apps like contacts, dialer, calendar, etc. should be provided outside of the ROM releases. This is the direction Google is taking Android and I feel like the FOSS community should also follow route. It would be so much easier if one could install contacts, dialer, calendar, etc. updates separate from the core ROM's updates.

I also have to mention that outside of compiling various open source Android apps, I am not an Android developer.

[Roboe]

Is not possible/viable to decompile those apps and replace the library with a dummy one, just like NoAnalytics? Another chance could be integrating an AROMA-alike installer for launcher, browser and, maybe, app store, but that will add complexity.

@BRNmod is coming to my mind right now... How will the Replicant team tackle this dependency issue?

[mid-kid]

BRNmod sounds exactly like what I've been looking for for a while. Too bad it hasn't been updated in a while.

[mid-kid]

Update: Apparently cm-14.1 stopped using AmibentSDK? It already wasn't being used anymore in all the phone-related apps and AudioFX, and now it was removed from vendor/cm and it isn't referenced anymore in Trebuchet. Can someone verify I'm right and it's not somewhere I haven't looked? Trebuchet still contains the stats classes, but the're not used from anywhere at all (only Launcher.java has an unused import for them), and don't link to ambientsdk anymore. Relevant commit: https://github.com/CyanogenMod/android_packages_apps_Trebuchet/commit/7b7aab45b223d0a6d551aebbe3f421c7376343b2 SetupWizard still has cmstats however.