AndroidAudit. Your Android application as a crime scene

From the translator: evaluation of the process and the result of the development is a rather subjective thing if no measure of weights is used. One can argue for a long time: tabs or spaces, git or mercurial, maven or gradle, but such disputes still slip into taste and some special cases. Another thing - the observance of the homogeneity of the project, this is quite a measurable value.

Bad methodology is better than no one.

In addition to common things, there are specific, inherent only in mobile development, only for Android. Pedro Vicente Gómez Sánchez from Karumi, in his work, sorted out the main technical areas and asked well-posed questions for a correct, objective assessment of the development for the Android platform. If a task appears: to evaluate someone else's project, then I recommend using his methodology. I used this methodology as a check list. At the exit, the document turned out to be quite understandable to a non-professional, where in front of each category is a specific amount of correctness matching from 0 to 1.


Technical audit of iOS and Android applications has become an integral part of our daily work in Karumi. Although it looks simple, there are quite a few details of the implementation of such a check that are worth considering. In this document, we will look at what we consider to be the most important in conducting the audit and divide it by technical area.
')
Version Control System

Whether a version control system is used, which system and how workflows are organized will tell a lot about the development process.

• Do you have a properly configured * ignore file so that IDE metadata files and other extraneous elements do not fall into the repository?
  
• Are third-party libraries configured as external dependencies or are they in storage?
  
• Are the short and expressive comments on commits you use?
  
• Is the size of your commits reasonable?
  
• Are all the files in a commit related to the same problem or functionality?
  
• Do you use any branching schemes like "feature branch" or "git-flow"?
  
• Are the branches names informative enough?
  
• Do you use the pull request / code review system before merging the code into master?
  
  • Do you have any rules regarding what to look for when considering a PR (pull request)?
    
  • How many comments on average per PR?
    
  • How many people does each PR consider?
    
  • How many +1 PR to merge?
    
  • Who is responsible for closing the branch?
  
  
• Do you use release branches for each release?
  
• How long is the staging process open?
  
• How many corrections do you make in the release candidate before you release it?
  
• Is it possible to switch to the exact code of any of the published versions of your application?
  
• How many hotfix fixes did you release last year?
  
• Do you combine (squash) commits before merging it into a master / develop branch?
  
• Are master / develop branches ready for release at any time?

Build Tools

The determining factor is the ability to run the build process on the developer's machine and on any other external system, for example, on a continuous integration system.

• How many libraries are used in the project?
  
• Is the project divided into modules?
  
• Are Maven or Gradle modules used to resolve dependencies, or are local .jar files used?
  
• Is the project at a dangerous distance close to the limit on the number of methods in .dex files? Or is it over the edge?
  
• Do you use libraries that are not needed in the project?
  
• Is multidex used?
  
• Are all external dependencies updated to modern versions?
  
• Are all licenses of third-party libraries complied with?
  
• Are outdated or unsupported third-party libraries used?
  
• Is the minimum SDK conditioned by the requirements of the technical description (product description)?
  
• Is the target SDK relevant?
  
• Is ProGuard or any other obfuscation tool used (obfuscation)? Is it on and properly configured?
  
• Are the keystore credentials credentials and google play credentials kept in a safe place?
  
• Is the application keystore and credentials stored in a safe place?
  
• Are build types properly configured?
  
• Are flavors used correctly?
  
• Is the release assembly type properly configured?
  
• Is the backup option enabled?
  
• Is Lint turned on? Does he successfully pass the test?
  
• Is there a static analysis tool? Is it configured and successfully tested?
  
• Is there a checkstyle? Is it configured and successfully tested?
  
• Is the application id and version name / code correct?
  
• Do you use any structure or strategy for id versioning?
  
• Is the continous integration tool used, is it properly configured?
  
• Is the process of releasing new versions automated?

Using Android resources

There is a wide range of devices in the Android world, each with its own screen size, capabilities, etc. You need to be very careful and carefully use some of the Android tools so that users have the best impression of your application, regardless of their device.

• Are there any missing resources for densities, flavors and build types?
  
• Does the application require support for screens with different pixel density (density) according to the specification?
  
• Does the application use drawable / mipmap, fonts, or vector resources?
  
• Are there any missing translations?
  
• Is the translation process automated?
  
• What is the default language for translation?
  
• Does the application use third-party fonts?
  
• Does the application use configuration values ​​inside a string resource file?
  
• Is the agreement honored for assigning uniform names to resources?
  
• Are there any configuration parameters associated with the hardware of the device, are they configured correctly?
  
• Are the tablets supported?

Using Android Layout

As we said earlier, there is a wide range of Android devices in the world, each of them with its own size and density of the screen. The determining factor is the proper use of Android Layouts.

• Are there any performance problems due to the number of layers in the layouts of the application?
  
• Do you use themes and styles?
  
• Are layouts reused with the "include" tag?
  
• Are you using the right type of grouping in layouts?
  
• Are different screen sizes taken into account in the layouts?
  
• Is any naming convention used to keep the names assigned to layouts and widgets homogeneous?
  
• Lists implemented using ListView or RecyclerView?
  
• Is the Android Support Library used correctly?

Access rights

Requesting possible actions of the application (permissions) increases the trust of users to it, as well as expands its capabilities through "transparent" integration with other services.

• Are all required permissions really necessary?
  
• Is permission used intentionally?
  
• Are there any missing permissions?
  
• If the target SDK is greater than 23, are “dangerous permissions” being requested using the compatibility permissions system?
  
• Permission requested when they will be used?
  
• Is there user feedback explaining why any permission is needed?

Safety problems

As developers, we must be conscious of the security of our applications. We don’t want our users ’data to be leaked or stolen.

• Is the HTTP client configured to use HTTPS?
  
• Is the HTTP client configured to use an embedded certificate (certificate pinning) and authentication messages with HMAC?
  
• Does the application keep confidential user information? Where?
  
• Does the application store information outside the internal storage system?
  
• Is the application logged (logging traces) when the release is built?
  
• Is the application code obfuscated?
  
• Does your application provide a content provider (Android content provider), receiver (receiver), or service to other applications?
  
• Is the "debuggable" option disabled in the release build?

Push Notifications (Push Notifications)

Push is an excellent mechanism for informing our users at any time, but this is a more complicated problem than it seems at first glance.

• Is a third-party library used to implement the system of push-notifications?
  
• Is the GCM system used to transmit information to the application, or just to show messages to the user?
  
• How does the application behave when receiving push notifications?
  
• How does the application behave when the information related to the Push notification is not what was expected?
  
• Are notifications using compatibility APIs shown?

Performance

Performance is important. No one wants to use a slow application on their expensive devices. Productivity is money.

• Does the application have any memory leaks?
  
• Is a memory analyzer set up in the develop assembly, like, for example, "LeakCanary"?
  
• Is Android Strict Mode connected and configured in the develop assembly?
  
• How are threads used in the application? Do you use async tasks, intent services or any other third-party libraries?
  
• Does the number of background threads cause performance problems?
  
• Do you use any scheduler policies or just create threads on demand?
  
• Do you support Android Doze Mode?
  
• Are there any events related to the state of the network or any other recurring event from the operating system?
  
• Is the main thread used only to perform tasks related to user interface code?
  
• Does the application have any caching policies?
  
• Is the HTTP client configured to use a timeout?
  
• Is the HTTP client configured to use gzip?
  
• Does the user interface of the application run at 60 frames per second?
  
• Are there any custom views for which too much memory is allocated, or which perform “expensive” tasks in the UI thread (UI thread)?
  
• Are you testing your application on lower-end (low cost, non-productive) devices?
  
• Doesn't scrolling slow down the recycler view?
  
• Is a third-party library used for uploading images or do you have your own solution?
  
• Are the images scaled to fit the screen or immediately loaded under a specific device screen?
  
• Is memory usage reasonable?
  
• Is the "Static" modifier used correctly in Java?
  
• Do all image processing tasks handle multiple images at once?
  
• Does the statistics system work in a background thread and is it configured with the correct priority?
  
• Is the code optimized in the release build?

Java Packages Structure

A good package structure will make our code more scalable.

• Are packages used to separate code by functionality (features) or concepts (for example, Login vs User)?
  
• Are Java visibility modifiers used to hide implementation details inside packages?
  
• Do all packages come out of the root package?
  
• Does the test directory repeat the source folder structure?
  
• Are the various features (features) organized using the same package structure?
  
• Are the classes in the correct packages?
  
• Are uniform naming conventions followed?
  
• Is the name of the root package associated with the company name?

Code Style

The code base coordinated in terms of style helps our engineers to read the code more easily. The engineer reads MUCH more code than he writes, so this is an important concept.

• Is the codestyle homogeneous?
  
• Do you use Hungarian notation?
  
• Is there any checkstyle tool? Is it up and running?
  
• Does the code match java codestyle?
  
• Do you use tabs or spaces?
  
• Are the classes correct?
  
• Do you use "I" as an interface prefix or "Impl" as implementation suffixes?
  
• Do you use the correct variable names?
  
• Do you use the correct names for the fields?
  
• Do you use the correct names for the methods?
  
• Are the attributes and modifiers of the visibility of methods properly used?
  
• Is the code written in English?
  
• Do you use javadoc?
  
• Are you writing code comments?
  
• Do you use constants or enums to avoid duplication of literals?

Offline implementation

Ensuring good offline operation is the hallmark of our applications.

• Can the application be used when there is no Internet connection?
  
• What is the behavior of the application with a slow network connection?
  
• What is the behavior of the application when the request is lost due to a network failure?
  
• Are changes to application data synchronized with the backend after the connection has been reestablished?
  
• Is the timeout configured for network connection?
  
• Is HTTP caching policy configured?
  
• Is the user session restored automatically?

Architecture

The application architecture, in terms of code, is one part of the audit, which gives us a deeper understanding of the application. During the review of the application architecture, we will focus on concepts related to SOLID and Clean Code principles.

Presentation Layer Implementation

• Is there any pattern associated with the implementation of a GUI (graphical user interface)? Model View Presenter or Model View ViewModel are two of the most commonly used templates for application development. Are they implemented correctly?
  
• Is the presentation layer associated with the view implementation?
  
• Is the view implementation associated with the model implementation?
  
• Does the presentation layer include business logic?
  
• Does the view implementation correctly use Android SDK tools?
  
• Do you use third-party libraries to simplify view implementation?
  
• Is the implementation of different functions divided by individual activities or fragments?
  
• Is the user interface behavior uniform?
  
• Do you use custom views to reuse UI code?

Domain Implementation (Domain Implementation)

• Is there a separate domain layer or is the whole business logic implemented in the presentation layer?
  
• Are the domain rules and different application requirements expressed in the core business logic objects?
  
• Is the domain layer implemented using OOP principles?
  
• Is the domain layer associated with the Android SDK or any third-party library?
  
• Is the domain layer associated with the presentation layer?
  
• Is the domain model "anemic"?
  
• Do you use “fat” domain models?
  
• Is the code based on loosely coupled and, at the same time, well interacting components?
  
• Is error handling implemented using exceptions or some other error handling mechanism?
  
• Is the data mapped between different layers?
  
• Does the architecture of external components (for example, database schemas or JSON parsing) affect the domain model architecture?
  
• Are developers abusing inheritance?
  
• Is code duplicated?
  
• Is there a dependency injection library or a configured service locator?
  
• Is the complexity of the classes and methods too high?

API implementation

• Is the implementation of the API attached to the Android SDK?
  
• Does the API leak any implementation details from the HTTP client or the library used to implement the network layer?
  
• Is the API client sending the correct headers?
  
• What is the client API behavior for different HTTP responses?
  
• Does the client API implement an authentication mechanism?
  
• Has the session resumption process been implemented correctly?
  
• Is there any support for obfuscation of JSON?
  
• Is the implementation of the API split for different clients?

Implementing Storage

• Where is the information stored?
  
• Are transactions used when reading and writing information to the repository?
  
• Is the storage of confidential user information secure?
  
• Does the storage layer use any third-party libraries?
  
• Do implementation details flow through the storage layer?
  
• Are the tables / schemas correctly designed?
  
• Are the queries sent to the repository optimized?
  
• Are the Android SDK APIs used to store data in the right place? Is the data stored in the database, and the settings (preferences) and small data in the Shared Preferences and files on the disk?

Testability

• Does the application have tests?
  
• Is the application testable?
  
• Does the application use different types (unit / integration / end-to-end) tests?
  
• Are the tests correct?
  
• Do the tests cover the project enough?
  
• Are there excessive documenting (overspecification) in tests?
  
• Is the lead time reasonable?
  
• Is the code coverage too low?
  
• Are there any ignored tests?
  
• Are there flaky tests?
  
• Do you use modern frameworks for testing?
  
• Are there any tests without statements (tests without asserts)?
  
• Tests and production code written by the same developers?
  
• Do you have a QA team?
  
• Do you have a QA team that automates some of the tests?
  
• Do you have any continuous integration system?
  
• Do you use builders, factories or mothers to reduce the cost of creating some objects that are necessary for tests?
  
• Assertion tests (assertions) correctly spelled?
  
• Do you conduct more than one logical statement per test?
  
• Do you have different test suites related to the same project?
  
• Do you use different testing approaches for different parts of the application?
  
• Do you use any monkeyrunner?
  
• Do you follow any TDD or BDD methodology?
  
• Do you use Java to write test cases?

Based on this list associated with various technical areas, we can assess the quality of the application. There are other points that we also consider, but this list contains the most important ones. Can you give correct answers to all these questions about your application?

Author: Pedro Vicente Gómez Sánchez.