Application: Share Flags

[DylanAkp]

Summary

People ask for flags X or Y to be implemented, some other users will enable flags and watch the changes to find the one they want.

Solution

Creating a "community flag" tab or option, so that everyone can share their flags with explanation on what it does, and everyone can use them

Examples

Same as Recommanded flags, but for community flags

Alternatives

A repository or something like this to share flags (less convenient)

Context

This feature allows user to share their flags and to be implemented faster

[jacopotediosi]

Thanks so much for your suggestion.

Implementing a feature like this would require significant effort to integrate a connection to a "community mods" repository within the application. Any mods in that repository would still need to undergo review by either myself or other trusted contributors, as applying mods can potentially impact device stability and security.

Furthermore, actually the mods applied by GAppsMod are not limited to just setting boolean flags to true/false.

Currently, the mods in our project can manipulate the filesystem (e.g., by editing files within /data/data folders) or modify the five types of flags contained in the phenotype database (intVal, boolVal, floatVal, stringVal, and extensionVal).

In particular, extensionVal flags contain raw bytes, often in the form of protobuf structures, which requires intricate reverse engineering work on the target Google applications for which mods are being developed. If you're interested in this aspect, you can refer to the following example where we perform such work:

GAppsMod/app/src/main/java/com/jacopomii/gappsmod/ui/fragment/SuggestedModsFragment.java

Lines 492 to 532 in 6970162

	// Ask the user what language the Call Screen feature should use
	String[] supportedLanguages = {"en", "en-AU", "en-GB", "en-IN", "ja-JP", "fr-FR", "hi-IN", "de-DE", "it-IT", "es-ES"};
	final int[] chosenLanguageIndex = {0};
	new MaterialAlertDialogBuilder(requireContext())
	.setTitle(R.string.choose_a_language_for_call_screen)
	.setSingleChoiceItems(supportedLanguages, chosenLanguageIndex[0], (dialog, which) -> chosenLanguageIndex[0] = which)
	.setPositiveButton(android.R.string.ok, (dialog, which) -> {
	// Update boolean flags
	modSetBooleanFlags(true, DIALER_PHENOTYPE_PACKAGE_NAME, DIALER_ENABLE_CALL_SCREEN_FLAGS);
	// Override the call screen i18n config extension flag with the user desired language
	TelephonyManager telephonyManager = (TelephonyManager) requireActivity().getSystemService(Context.TELEPHONY_SERVICE);
	String simCountryIso = telephonyManager.getSimCountryIso();
	String chosenLanguage = supportedLanguages[chosenLanguageIndex[0]];
	Call_screen_i18n_config call_screen_i18n_config = Call_screen_i18n_config.newBuilder()
	.addCountryConfigs(
	Call_screen_i18n_config.CountryConfig.newBuilder()
	.setCountry(simCountryIso)
	.setLanguageConfig(
	Call_screen_i18n_config.LanguageConfig.newBuilder()
	.addLanguages(
	Call_screen_i18n_config.Language.newBuilder()
	.setLanguageCode(chosenLanguage)
	.setA6(
	Call_screen_i18n_config.A6.newBuilder()
	.setA7(ByteString.copyFrom(new byte[]{2}))
	)
	)
	)
	).build();
	try {
	mCoreRootServiceIpc.phenotypeDBOverrideExtensionFlag(DIALER_PHENOTYPE_PACKAGE_NAME, DIALER_CALL_SCREEN_I18N_CONFIG_FLAG, call_screen_i18n_config.toByteArray());
	} catch (RemoteException e) {
	e.printStackTrace();
	}
	})
	.setNegativeButton(android.R.string.cancel, (dialog, which) -> dialog.cancel())
	.setOnCancelListener(dialog -> mBinding.dialerForceEnableCallScreen.getSwitch().setCheckedProgrammatically(false))
	.show();

Filesystem mods are also quite complex. For example, to add contacts to the list for which the Phone by Google application automatically record calls (#26), it is necessary to reverse engineer the protobuf structure contained in the /data/data/com.google.android.dialer/files/CallRecordingSettingsData.pb file.

Since these types of mods don't have a standard, the code has to be written manually. Therefore, users would still not be able to submit these mods directly through the application itself, but would have to open an issue or pull request on GitHub to contribute their own mods.

For the reasons mentioned above, it is not worth implementing a community mods repository, because it would be limited to boolean mods only.
Instead, I encourage you to submit mods through issues or pull requests so that I can add them to the "Suggested Mods" section.

Additionally, I already have plans to create a documentation (wiki) in the future where everyone can contribute by explaining the functionality of each flag in the phenotype database.