Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spam Caller Blocker #429

Open
DonnieBLT opened this issue Aug 7, 2024 · 9 comments · May be fixed by #465
Open

Spam Caller Blocker #429

DonnieBLT opened this issue Aug 7, 2024 · 9 comments · May be fixed by #465

Comments

@DonnieBLT
Copy link
Collaborator

Project Overview

The objective of this project is to develop a cross-platform mobile application using Flutter that blocks or identifies spam callers on both iOS and Android devices. The app will utilize platform-specific APIs and extensions to accomplish the spam blocking feature:

  • iOS: Utilize the Call Directory Extension to block or identify spam calls.
  • Android: Utilize Telephony and CallScreeningService APIs to intercept and block calls.

1. Project Structure

1.1 Flutter Project Setup

  • Project Name: SpamCallerBlocker
  • Folders:
    • lib/: Contains Flutter Dart code.
    • ios/: Contains iOS native code and Call Directory Extension.
    • android/: Contains Android native code for call blocking.
    • assets/: Contains assets like icons and UI images.
    • test/: Contains unit and widget tests.

2. Flutter Codebase

2.1 Flutter UI

  • Main Screen:

    • Display a list of blocked numbers.
    • Options to add a number manually.
    • Option to import numbers from a list or an external database.
    • Button to update the spam number list.
  • Flutter Packages:

    • provider or riverpod for state management.
    • http for API calls if needed (e.g., to retrieve a list of spam numbers from a server).
    • flutter_local_notifications for local notifications on Android.

2.2 Communication with Native Code

  • Platform Channels:
    • Use platform channels to send and receive data between Flutter and the native code (iOS & Android).
    • Example: Passing the list of spam numbers from the Flutter UI to the Call Directory Extension on iOS and to the appropriate APIs on Android.
// Example Flutter to Native Channel
const platform = MethodChannel('com.example.spamcallerblocker/extension');

Future<void> updateSpamList(List<String> numbers) async {
  try {
    await platform.invokeMethod('updateSpamList', {"numbers": numbers});
  } catch (e) {
    print("Failed to update spam list: $e");
  }
}

3. iOS Implementation

3.1 Call Directory Extension Setup

  • Create a Call Directory Extension:
    • In Xcode, add a new target for a Call Directory Extension to the existing Flutter project.
    • Configure the extension to manage a list of blocked and identified numbers.

3.2 Native iOS Code

  • Swift/Objective-C:
    • Implement the logic to receive the list of spam numbers from Flutter via platform channels.
    • Store and manage these numbers within the Call Directory Extension.
// Example Swift code to handle the platform channel in iOS

@objc class CallDirectoryHandler: NSObject, CXCallDirectoryExtensionContext {
    let spamNumbers = UserDefaults.standard.array(forKey: "spamNumbers") as? [String] ?? []

    func updateSpamList(with numbers: [String]) {
        UserDefaults.standard.set(numbers, forKey: "spamNumbers")
    }

    func addSpamNumbers(to context: CXCallDirectoryExtensionContext) {
        for number in spamNumbers {
            if let phoneNumber = Int64(number) {
                context.addBlockingEntry(withNextSequentialPhoneNumber: phoneNumber)
            }
        }
    }
}
  • Update the Call Directory:
    • Periodically update the spam numbers through the Call Directory Extension using the data passed from the Flutter app.

3.3 App Group (if needed)

  • App Group:
    • If data sharing between the main app and the extension is necessary, consider setting up an App Group.

4. Android Implementation

4.1 Permissions

  • Manifest Permissions:
    • Ensure the Android app has the necessary permissions to read call logs and block calls.
    • Example permissions: READ_CALL_LOG, ANSWER_PHONE_CALLS, READ_PHONE_STATE.
<uses-permission android:name="android.permission.READ_CALL_LOG" />
<uses-permission android:name="android.permission.ANSWER_PHONE_CALLS" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />

4.2 CallScreeningService

  • Implement CallScreeningService:
    • Create a service to intercept incoming calls and block or identify spam calls based on the list received from Flutter.
public class CallBlockerService extends CallScreeningService {
    @Override
    public void onScreenCall(Call.Details callDetails) {
        String incomingNumber = callDetails.getHandle().getSchemeSpecificPart();

        // Check if the number is in the spam list
        if (isSpam(incomingNumber)) {
            CallResponse.Builder responseBuilder = new CallResponse.Builder();
            responseBuilder.setDisallowCall(true);
            respondToCall(callDetails, responseBuilder.build());
        }
    }
    
    private boolean isSpam(String phoneNumber) {
        // Implement logic to check if the number is spam
        return spamList.contains(phoneNumber);
    }
}

4.3 TelephonyManager (for older Android versions)

  • For Devices on Android Below API 29:
    • Use TelephonyManager to monitor incoming calls and block them if necessary.

5. Testing and Deployment

5.1 Testing

  • Unit Tests:
    • Write unit tests for the Flutter code to ensure that the list of spam numbers is handled correctly.
  • Integration Tests:
    • Test the communication between Flutter and the native code on both platforms.

5.2 Deployment

  • App Store & Google Play Compliance:
    • Ensure that the app complies with the respective app store guidelines, especially regarding permissions and access to sensitive data.
  • Beta Testing:
    • Use TestFlight for iOS and Google Play's beta testing tools to gather feedback before public release.

6. Additional Features (Optional)

  • Crowdsourcing Spam Numbers:
    • Allow users to report spam numbers, which can be added to a shared database.
  • Push Notifications:
    • Notify users when a known spam number is blocked.
  • Periodic Updates:
    • Implement a mechanism to periodically fetch the latest spam numbers from a server.

7. Conclusion

This project document outlines the architecture and development plan for a cross-platform spam caller blocker app using Flutter. By leveraging platform-specific APIs, we can effectively block or identify spam calls on both iOS and Android, ensuring user privacy and security.


Note: This project requires proficiency in both Flutter and native iOS/Android development due to the need for platform channels and native code integration.

@krrish-sehgal
Copy link
Contributor

krrish-sehgal commented Nov 10, 2024

I would love to work on it,
I had a few questions about the contribution system. Will this be developed as a new app with its own repository, or will it be added as a major feature in an existing app, like Sizzle? Given the scope, it seems like it could be a standalone project, but wanted to understand the planned approach.

@DonnieBLT
Copy link
Collaborator Author

It would be in this app

@krrish-sehgal
Copy link
Contributor

Will there be a 3rd party API call for checking that the number is spam, or will we maintain a database on our backend and the app will timely fetch the phone numbers and update in shared preferences?

@DonnieBLT
Copy link
Collaborator Author

We will maintain the db

@krrish-sehgal
Copy link
Contributor

Then we can do this
Local storage(Sqflite): Keep high-priority spam numbers and user-specific preferences.
Server-side database: Manage the full dataset and push relevant updates to the device periodically.

In order to begin working on this should i first be looking towards creating a database and api on the backend or i can just start with taking some blocked numbers from user , storing them the same way that i'll store the fetched spam numbers from the database in the future, and work on the app part first.

@DonnieBLT
Copy link
Collaborator Author

Sounds like starting with some blocked numbers is good

@krrish-sehgal
Copy link
Contributor

In order stay synced,
I had a following rough draft proposal...
PR1: initial setup for the pod files and manifest, along with some android integrations setup
PR2: complete android implementation
PR3: complete IOS implementation
PR4: Enhancemnt for Flutter UI/UX
PR5: adding backend support from our database to fetch latest spam numbers
PR6: additional features
PR7: major/minor bug fixes
PR8: unit tests and integration tests
PR9 : Documentation
PR10: app store and google play store compliance

Does this workflow makes sense and goes with what you had in mind?

@DonnieBLT
Copy link
Collaborator Author

How about 1 and 2 together? The rest look good!

@krrish-sehgal
Copy link
Contributor

sure , sounds great.

@krrish-sehgal krrish-sehgal linked a pull request Dec 17, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

2 participants