Library Workflows
How interception happens
In terms of a DMA team interception is the process of interrupting a usual call flow and replacing the call with opening a profile. So, technically, we hang up the call and instead of it show the profile.
The DMA library intercepts only particular numbers that are linked to a particular Android package (so the list of phone numbers to be intercepted for example.com package will be different from the dialmyapp.com package).
With the exception of when we already have a profile containing the number to be intercepted, the Bloom filter detects and intercepts the number.
Usually we deliver the library with some profiles already preloaded to make it work without any internet access. Then, the numbers defined within these profiles are used for interceptions before application connects to the internet for first time (and downloads the available updates and the bloom filter).
API Requests
In this section we'll try to describe different API calls. XXX differs for different countries. For Mexico it is "mx" for Israel it is "il".
| Name | URI | Description |
|---|---|---|
| Bloom update | https://api-XXX.dialmyapp.com/phone.bloom?bloom |
Update the bloom filter, if it changed or is not preloaded. Empty response if no changes |
| Wellknown update | https://api-XXX.dialmyapp.com/wellknown/update |
Request for updates of different assets of the library from the server. Empty response if no updates |
| Phone info update | https://api-XXX.dialmyapp.com/phone.update |
Post some tech data about phone to server (OS, versions, etc.). Response contains some signaling instructions from server. |
| Profiles update | https://api-XXX.dialmyapp.com/phone.address |
Update of JSON profiles, that loaded on the phone. Empty if nothing to update |
| Google analytics | https://ga.dialmyapp.com/collect |
Post data of usage to google analytics |
| Resources download | http://cdn.dialmyapp.com |
We use this server for pictures in profiles, and other static files. Once they are downloaded, they are cached locally. |
Application first start
Below is the description of what happens inside the library for different cases. The initial state of the application - the application was never opened.
| Internet available | Internet not available | |
|---|---|---|
| User clicks application icon | Bloom update request, Wellknown update request, Post phone info request, Profiles update | No activity |
| User dial the number (app pre-installed) | Broadcast receiver get the number. Broadcast receiver check number against preloaded profiles. If number matches, show profile. Bloom update request, then check against the bloom filter. If number is in bloom filter, request to get the profile from server (profile update with name of profile). Then call to show that profile. Wellknown update request, Post phone info request, Profiles update request | Broadcast receiver get the number. Broadcast receiver check number against preloaded profiles. If number matches, show profile. |
| User dial the number (app not preinstalled) | Nothing happens | Nothing happens |
Stop/Resume library inside application
In order to prevent the library from starting, and prevent it from further interceptions/internet usage, you can use the DMAController.stopDMA(Context) method. This will set a special preference and cancel created alarms within the Android AlarmManager. Next time the application starts, DMA library processes, initialization etc. will not happen, as well as all internet traffic will not be active.
In order to resume the library to normal work, initiate DMAController.resumeDMA(Context). This will start the preference to normal processing and during the next start of the application, the library will function normally.
Custom intercept logic
Upon request, the SDK can be prepared with custom interception logic for both outgoing and incoming calls (referred to as ProtectCall). Intercept customization is based on flags, which indicate user acceptance for both types of interception. User acceptance must be requested within the app. Lists of profiles for outgoing calls and ProtectCall are provided to the DMA team by app owners and configured on the server side to be delivered to the app.
When a call event is processed, the DMA SDK decides whether to intercept it based on the flag status and the association of the phone number with the profiles provided to DMA for custom intercept configuration.
To set and check flag states in accordance with user acceptance from the app, use the following functions:
package org.mbte.dialmyapp.util;
public class InterceptUtils {
public static void setOutgoingInterceptAccepted(Context context, boolean value)
public static boolean isOutgoingInterceptAccepted(Context context)
public static void setProtectCallState(Context context, boolean accepted)
public static boolean isProtectCallAccepted(Context context)
}