Import/Export blocking rules with compatibility

[fabianski7]

Blocking application trackers is not easy at all and losing that work when you change your ROM or cell phone makes all that work lost. An option to export the rules of each application or all at once would solve that.

For those who are using other applications to do this blocking, like Watt or Blocker, an option to import the list of rules that these applications generate would be something very nice too. It would also make it easier to migrate to your application that seems to be much better than the others.

This is a list of rules exported from Blocker

{
  "author": "Blocker",
  "components": [
    {
      "method": "IFW",
      "name": "com.google.android.gms.analytics.AnalyticsReceiver",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.GcmBroadcastReceiver",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.NotificationOpenedReceiver",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.UpgradeReceiver",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "IFW",
      "name": "com.yandex.metrica.MetricaEventHandler",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "PM",
      "name": "androidx.work.impl.background.systemalarm.RescheduleReceiver",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "IFW",
      "name": "com.facebook.CurrentAccessTokenExpirationBroadcastReceiver",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    },
    {
      "method": "IFW",
      "name": "com.google.android.gms.analytics.AnalyticsService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.google.android.gms.analytics.AnalyticsJobService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.GcmIntentService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.GcmIntentJobService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.RestoreJobService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.RestoreKickoffJobService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.SyncService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.SyncJobService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.NotificationRestoreService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.yandex.metrica.MetricaService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.yandex.metrica.ConfigurationService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.yandex.metrica.ConfigurationJobService",
      "packageName": "me.mustapp.android",
      "type": "SERVICE"
    },
    {
      "method": "IFW",
      "name": "com.facebook.FacebookActivity",
      "packageName": "me.mustapp.android",
      "type": "ACTIVITY"
    },
    {
      "method": "IFW",
      "name": "com.onesignal.PermissionsActivity",
      "packageName": "me.mustapp.android",
      "type": "ACTIVITY"
    },
    {
      "method": "IFW",
      "name": "com.twitter.sdk.android.core.identity.OAuthActivity",
      "packageName": "me.mustapp.android",
      "type": "ACTIVITY"
    },
    {
      "method": "IFW",
      "name": "com.google.android.gms.auth.api.signin.internal.SignInHubActivity",
      "packageName": "me.mustapp.android",
      "type": "ACTIVITY"
    },
    {
      "method": "IFW",
      "name": "com.google.android.gms.common.api.GoogleApiActivity",
      "packageName": "me.mustapp.android",
      "type": "ACTIVITY"
    },
    {
      "method": "PM",
      "name": "com.crashlytics.android.CrashlyticsInitProvider",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    }
  ],
  "description": "Generated by Blocker",
  "packageName": "me.mustapp.android",
  "versionCode": 10723,
  "versionName": "1.7"
}

[MuntashirAkon]

Exporting/importing blocking rules as well as permission/appop rules is in my todo list. In the mean time, similar to Watt (whose concept this app used), all rules are saved under /sdcard/android/data/io.github.muntashirakon.AppManager/Files/ifw.

Blocker/MAT compatibility is also in my todo list. If parsing their configs require help of any external library, I'll probably skip as keeping the app size small is one of my main motto. But if they don't require any external library, I'll do it.

[MuntashirAkon]

There are three popular component blockers: Blocker, MyAndroidTools (MAT) and Watt. The first two has three blocking options: Intent Firewall (IFW), pm command and Shizuku, and Watt only supports IFW.

This project chose IFW (and pm to block providers) over others because of its simplicity and superiority over other blocking methods. MAT is a non-free software and some of its backups are binary files instead of ASCII text file. If pm method is used, the backup file contains each components in a new line with the following format:

<package-name>/<component-name> (3|s)(a|p|r|s)

The use of 3 and s is not clear to me but a, p, r, s stands for activity, provider, receiver and service.

Blocker exports configurations in JSON format (an example is provider by the author of this issue above).

Watt doesn't support exporting through app. But a backup of the configuration files are saved in the external data directory which is accessible to the user and can take a backup of them. This app (AppManager) also use the same method to store its configuration files. So, just copying files from Watt's directory to this app's directory will do.

That's being said, I'll only support importing Blocker's exported JSON (I'll ignore the method option since I only use IFW) and MAT's plain text backup. But how the system will import/export it's own files is still an open question.

[fabianski7]

Great analysis.
The compatibility with Watt and Blocker rules import will be more than enough. I believe that the MAT is not so used because it is a non-free software, so it won't be needed.

[MuntashirAkon]

...
    {
      "method": "PM",
      "name": "com.crashlytics.android.CrashlyticsInitProvider",
      "packageName": "me.mustapp.android",
      "type": "RECEIVER"
    }
...

Oops, a provider is given the type RECEIVER.

[MuntashirAkon]

I may not be able provide full compatibility of Blocker because of that.

[MuntashirAkon]

Import/export feature

Import support for external app

I'll only support Watt and Blocker (I don't want to endorse any non-free app so MAT will not be supported). Their limitation, however, is that you can only import one package at a time. Therefore, users can choose multiple files if they want to import configurations for multiple packages.

Import/Export within app

My app currently supports blocking activities, broadcast receivers, providers, services, app ops and permissions, and in future I may add more blocking options. In order to add more portability, it is necessary to import/export all of these data. Currently, the app is modularised in a way so that each feature acts more like a separate API (with only dependency of the utils package). This will also help in making the export/import process much easier.

Storage

Component blocker currently uses /sdcard/Android/data/<package-name>/Files/ifw which is inherited from the app Watt. However, this method is not secure as any app having access to these directories can create or delete the files. Therefore, it is my intention to save them internally within /data/user/ so that no non-root app can access these files.

Maintaining a database should be the best choice when it comes to storing data. But for now, I'll be using several tsv files with each file having the name of the package and a .tsv extension. The file/database will be queried/processed by the .storage.StorageManager class. Due to this abstraction, it should be easier to switch to database or encrypted database systems in future without changing the design of the entire project.

TSV file format:

<name> <type> [<mode>|<component_status>|<is_granted>]

Where:

• <name>: Component/permission/app op name (in case of app op, it could be string or integer)
• <type>: One of the ACTIVITY, RECEIVER, PROVIDER, SERVICE, APP_OP, PERMISSION
• <mode>: For app ops: The mode name
• <component_status>: For components: Whether the configuration is applied Denotes component status
  • true: Component has been applied (true value is kept for compatibility)
  • false: Component hasn't been applied yet, but will be applied in future (false value is kept for compatibility)
  • unblocked: Component is scheduled to be unblocked (new)
• <is_granted>: For permissions: Whether the permission is granted or revoked

Import/Export file format

Unlike other projects, this app will generate a single file containing all the configurations (for all packages). In future, I may let users select which packages they want to restore. I may also let users export configurations for a single app in the App Info window (which can be useful for sharing with others). Due to several reasons, I will use JSON tsv to export all data.

TSV file format (using trivial notation)

<package_name> <component_name> <type> [<mode>|<component_status>|<is_granted>]

This is the same as the tsv format above except the first item. The advantage of such scheme is that both can be parsed in a similar manner and doesn't loose the modularity at the same time.

Milestones

• v2.5.4: Blocker and Watt compatibility
• v2.5.5: Store custom permission/app ops grant/revoke
• v2.5.6: Merge ComponentBlocker with StorageManager, support Blocker's buggy configurations
• v2.5.7: Fix various issues with ComponentBlocker and StorageManager
• v2.5.8: Full implementation
• v2.5.9: Replace <is_applied> with <component_status>. This is done to introduce a new parameter unblock which denotes the components that are scheduled to be unblocked, once unblocked these components will be removed from the list

[MuntashirAkon]

Closed via beb8f9a