مطلوب برمجة تطبيق أندرويد ب kotlin او java
مطلوب برمجة تطبيق أندرويد ب kotlin او java
Here is the complete, copy-paste ready prompt . It includes all technical requirements, the new remote control logic, and the specific behavioral rules.
Project: Android App for Automated Bulk Calling & SMS Notification
Platform: Android (Java or Kotlin)
Goal: Build an app that periodically fetches configuration, phone lists, and remote commands to automate bulk calling and SMS notifications.
1. Data Sources & Configuration
The app must fetch configuration and data from remote URLs (configurable by the user via UI):
Phone List URL: A plain text file containing one phone number per line.
App Config URL: A JSON file containing app settings (e.g., call intervals, start/stop flags).
SMS Config (Optional): A JSON file mapping numbers to specific SMS messages. If not present, use the Default SMS.
Control URL (NEW): A plain text URL (configurable in UI) containing commands to start, stop, pause, or burst the process.
2. Core Logic & Rules
A. Calling Logic
Frequency: Call each number 2 times within a 24-hour period.
Ringing Limit: Each call rings for a maximum of 10 seconds. If unanswered after 10s, terminate the call.
Answer Handling: If the call is answered, disconnect immediately.
Cycle: Loop through the list, adhering to the 24-hour constraint per number.
B. SMS Logic
Trigger: Send SMS only once when a phone number is first detected in the updated list (i.e., it was not in the previous list).
Tracking: Maintain an internal list/database of "already messaged" numbers. Do not send SMS to numbers already in this list.
Default SMS Text: "لقد قمت بالطلب اونلاين ولم تستلم . يرجى استلام طلبك ."
C. Status Reporting
After every 5 calls, POST the status of those calls (e.g., success/failure, answered/not answered) to a specified API endpoint (URL to be defined in settings or hardcoded).
D. Remote Control Logic (New Requirement)
Source: Poll the Control URL every 60 seconds (configurable, min 30s).
Format: Plain text, one command per line. Newest line has highest priority.
Supported Commands:
START / RESUME: Resume normal 2x/24h cycles.
STOP: Pause new calls/SMS. Pending calls finish, but no new calls are initiated.
PAUSE <minutes>: Pause for N minutes (e.g., PAUSE 30). Auto-resumes after elapsed.
BURST <count>: Force count additional calls across the list (overrides 24h limit for this pass), then return to previous state.
STATUS: App posts current state to a status endpoint.
Persistence: Mark commands as "consumed" after execution. Cache last known state locally if network is down.
State Machine: IDLE → RUNNING → STOPPED → PAUSED → BURST → RUNNING.
Error Handling: If Control URL returns HTTP 4xx/5xx, retry with exponential backoff (max 5 mins).
3. Background Service & Permissions
Service Type: Use a ForegroundService with a persistent notification to ensure the app is not killed by the OS.
Permissions Required:
CALL_PHONE (Direct dialing)
READ_PHONE_STATE (To detect call answer status via PhoneStateListener)
SEND_SMS
INTERNET
FOREGROUND_SERVICE
WAKE_LOCK (To prevent CPU sleep during calls)
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS (Request via Intent to Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)
Doze Mode Handling: Keep ForegroundService active. Use setExactAndAllowWhileIdle() for precise timing.
Battery Optimization: If denied, guide the user manually in settings.
4. User Interface (UI)
A simple, clean UI with the following elements:
Input Field: URL for the Phone List.
Input Field: URL for the App Config.
Input Field: URL for the Control URL (Remote Control).
Toggle/Button: Start/Stop the calling process.
Status Badge: Display current state: RUNNING, STOPPED, PAUSED, or BURST.
Status Display:
Total calls made.
Total SMS sent.
Current errors/logs (scrollable text view) including:
Fetch events.
Call events (start/end/timeout).
SMS events.
Remote commands received and executed.
5. Error Handling & Logging
Robustness: Catch all exceptions (Network, IOException, SecurityException) to prevent app crashes.
Logging: Log all critical events.
Storage: Store logs locally (e.g., in files/ directory or SQLite) for easy retrieval by the user for debugging. Store last N remote commands for audit.
6. Technical Constraints & Notes
Dialer vs. Direct Call: Use native ACTION_CALL for simplicity. Detect answer via PhoneStateListener on TelephonyManager.
Rate Limiting: Ensure the app doesn't burn through the 24-hour limit too quickly if the list is small.
Android 10+ Compatibility: Ensure proper handling of background SMS sending and foreground service notifications.
7. Data Formats
Control URL Example Content:
Copy
STOP
# This is a comment and will be ignored
PAUSE 15
Status Endpoint Response (POSTed by App):
Copy
{
"state": "RUNNING",
"totalCalls": 42,
"totalSMS": 15,
"lastControlCommand": "START",
"nextScheduledRun": "2026-08-14T12:00:00Z",
"errors": []
}
Default SMS Text:
Arabic: "لقد قمت بالطلب اونلاين ولم تستلم . يرجى استلام طلبك ."
Implementation Note: The app must use a reactive pattern (e.g., StateFlow in Kotlin or LiveData in Java) to update the UI badge and logs in real-time as remote commands are received and executed.
التعليقات (4)
