On improving the Scanner page

Scanner page currently displays number of classes, trackers, libraries, apk checksums, cert checksums. It should be possible to add other info which are usually known as **anti-features** in F-Droid. Since AM not only scans open source apps but also closed source apps containing proprietary codes, the anti-features defined by F-Droid don't really work here. Therefore, instead of using anti-features, I will be analysing the apk itself (like what AM's already doing) in various ways. These include:

- Analysing signatures with commonly used signatures used by malware, e.g. `android.telephony.TelephonyManager` is widely used by malware to get device phone number. AM cannot yet scan all the used libraries in an apk as it only scans classes, methods and fields. Therefore, the results may not always be reliable. For instance, a method may call `dalvik.system.DexClassLoader` but only returns `ClassLoader` in which case AM can only see `ClassLoader` but not `DexClassLoader`.
- Analysing permissions such as `android.permission.WRITE_SETTINGS`
- Analysing intent-filters
- Finding build type (i.e. whether the build is a debug build)
- Analysing custom dex files or any other compressed files in the res directory. Although Android itself cannot read a dex file to list classes, apk-parser can do that. Scanning res directory is important because the app stores additional classes containing malware there and after the install is complete and the app is opened, the app copies the dex file to the data folder, loads it using `DexClassLoader` and activates the malware.
- Check native libraries for strings that might match any signature said above. Some malware store the signature as a string in the native library in order to bypass malware checks and simply fetch it using a native call in run time.

These features are by no means easy to implement and some of them require a database (I could use the one provided by virusshare) that has to be maintained actively.