AIMSICD is not persistent enough about android-imsi-catcher-detector

[xLaMbChOpSx]

Yes once the app is killed the notification will disappear because it is dependant on the app being running, I believe the only way to achieve a truly persistent notification and app is to use a service and bind to that. This can be implemented to achieve that goal.

Starting prior to network services is a totally different matter I am not aware of anyway that this could be possible, happy for any info that would help achieve this but I don't know if it is possible.

[E3V3A]

@xLaMbChOpSx I don't understand what you're saying. "Starting prior to network services"... Can we run as a service or not? So that if its killed,it get automatically restarted? Can we look at other apps how they do it?

[xLaMbChOpSx]

Yes we can run a service to bind to but I don't think I can force the service to start before the Android system initiates network/radio connections, I can look into that but I think the service will start after the base internal services start.

[SecUpwN]

@xLaMbChOpSx, don't worry. I'm not even sure AIMSICD needs to start before radio connection. But as @E3V3A already mentioned, letting it start up on boot and restarting it upon kill would rock.

[E3V3A]

Yes, that's what I was wondering about. Why would it need to start before network? I don't think that is necessary for us, unless there's a programming thing (I don't understand).

[xLaMbChOpSx]

I was only responding to what was said in the initial post of this issue which stated it should start on boot and before network services. I have created a service and boot receiver which addresses this issue.

[SecUpwN]

@E3V3A, my initial thought was to protect the user right from the very beginning and before the radio connection starts. But protection once booted up should be fine enough. Furthermore, I'd like to ask @xLaMbChOpSx if he integrates the protection mechanism of FemtoCatcher from @iSECPartners as he said he'll be integrating the FemtoCatcher capabilities into AIMSICD. The current protection mechanism of FemtoCatcher is to force the phone to switch into flight mode until the users disables flight mode himself again. The fear I have, though, is that if a user does not recognize that AIMSICD protected him, he's practically walking around with a dead phoen for the rest of the day. Maybe we can let AIMSICD automatically switch back into normal connection mode after a set period of time?

I guess when @E3V3A is reading this, he'll very likely tell me that I'm ahead of time asking this. Again. But I can't help it: Just got too much excitement and passion for this project, dudes! 😃

[E3V3A]

@SecUpwN Yes, good thinking! Perhaps an even better suggestion would be to:

1. Have a (shutdown?) service that ensures that the phone always starts up in AirPlane mode (remember Wifi is still on) and then warns user (about airplane mode + AIMSICD settings) once bootup is complete.
2. Have a selectable (sound / vibration?) alarm that goes off after a certain period of AirPlane Mode.
3. ...and yes, this is also for later. :)

Since we're having this as an ongoing brain dump of wanted features, I think perhaps its better if we start a "Wanted Features" Vs "TO-DO" features page, we can just edit, when we have new ideas. I'm afraid that all these posts can be distracting for the programmer. What do you think @xLaMbChOpSx ? What I'm saying is that we need to stick to the development plan and separate features noise from taking up too much attention. Also remember people are following these threads, so we don't need people to start labeling our project as vapour-ware when we can't deliver on all points.

It is clear that I'll have to bring back that old development time plan with strategic way-points.
(Sorry, that is my fault, I should have brought that to the table long ago. I'm on it!)

[SecUpwN]

Thank you for telling me, @E3V3A. Created WANTED_FEATURES. Hope devs look at it.

[xLaMbChOpSx]

Pushed commits and published a new release to address this issue.