AndroidAudit. Your Android app as a crime scene

Original author: Pedro Vicente Gómez Sánchez
  • Transfer

From a translator: evaluating the process and the result of development is a rather subjective thing if no measure of weight is used. You can argue for a long time: tabs or spaces, git or mercurial, maven or gradle, but such disputes nevertheless slip into taste and some special cases. Another thing is the observance of the homogeneity of the project, this is already a measurable quantity.
A bad methodology is better than no methodology.
In addition to general things, there are specific ones that are inherent only in mobile development, only for Android. Pedro Vicente Gómez Sánchez from Karumi in his work disassembled the main technical areas by bones and asked accurate questions for a correct, objective assessment of development for the Android platform. If the task appears: to evaluate someone else's project, then I recommend using its methodology. I used this methodology as a checklist. The result was a document quite understandable to a non-professional, where, in front of each category, there is a specific value of the correspondence to correctness from 0 to 1.

Technical audit of iOS and Android applications has become an integral part of our daily work at Karumi. Although it looks simple, there are many details of the implementation of such a check that are worth considering. In this document, we will consider what we consider to be the most important during the audit and divide it into technical areas.

Version control

system Whether a version control system is used, which system and how work processes are organized - this will tell a lot about the development process.
  • Do you have a correctly 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 in storage?
  • Are you using concise and expressive comments on commits?
  • Is the size of your commits reasonable?
  • Are all files in the commit related to the same problem or functionality?
  • Do you use any branch schemes like "feature branch" or "git-flow"?
  • Are the branch names informative enough?
  • Do you use pull request / code review before merging code into master?
    • Do you have any regulations regarding what you need to pay attention to when considering PR (pull request)?
    • How many comments are on average for each PR?
    • How many people consider each PR?
    • How much "+1" to PR do you need to merge?
    • Who is responsible for closing the branch?

  • Do you use release branches for each release?
  • How long has the staging process been open?
  • How many corrections do you make to a release candidate before releasing 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 merge (squash) commits before merging it into a master / develop branch?
  • Are master / develop branches ready for release anytime?

Build tools A

determining factor is the ability to start 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 closer to the limit of the number of methods in .dex files at a dangerous distance? Or already beyond?
  • Do you use libraries that are not needed in the project?
  • Is multidex used?
  • Are all external dependencies updated to modern versions?
  • Are all third-party library licenses respected?
  • Are obsolete or unsupported third-party libraries used?
  • Is the minimum SDK subject to the requirements of the technical specifications (product description)?
  • Is the target SDK relevant?
  • Is ProGuard or any other obfuscation tool used (obfuscation)? Is it turned on and configured correctly?
  • Are keystore credentials credentials and Google Play credentials stored 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 build type configured correctly?
  • Is the backup option enabled?
  • Is Lint Enabled? Does it pass the test successfully?
  • Is there a static analysis tool? Is it configured and passes the test successfully?
  • Is there a checkstyle? Is it configured and passes the test successfully?
  • Is the application id and version name / code configured correctly?
  • Are you using any id versioning structure or strategy?
  • Is the continous integration tool used, is it configured correctly?
  • Is the release process automated?

Using Android resources

There is a wide range of devices in the Android world, each of them 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 experience with 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 densities according to the technical specifications?
  • Does the application use drawable / mipmap, fonts, or vector resources?
  • Are there any missing translations?
  • Is the translation process automated?
  • What language is selected by default for translation?
  • Does the application use third-party fonts?
  • Does the application use configuration values ​​inside a string resource file?
  • Is there an agreement to assign uniform names to resources?
  • Are there any configuration parameters related to the hardware of the device, are they configured correctly?
  • Are 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 screen density. The determining factor is the proper use of Android Layouts.
  • Are there performance issues due to the number of layers in the application’s layouts?
  • Do you use themes and styles?
  • Are layouts reused using the include tag?
  • Are you using the correct type of grouping in layouts?
  • Are the different screen sizes included in the layouts?
  • Is any naming convention used to keep the names assigned to layouts and widgets uniform?
  • Are lists implemented using ListView or RecyclerView?
  • Is the Android Support Library used correctly?

Access rights

Request for possible actions of the application (permissions) increases the trust of users in it, and also expands its capabilities due to "transparent" integration with other services.
  • Are all requested permissions really necessary?
  • Is permission used intentionally?
  • Are there any missing permissions?
  • If the target SDK is greater than 23, then are “dangerous permissions” requested by the compatibility permissions system?
  • Permission requested when they will be used?
  • Is there any user feedback explaining why any permission is needed?

Security Issues

As developers, we must be conscious about the security of our applications. We do not want our users' data to leak or their sessions be stolen.
  • Is the HTTP client configured to use HTTPS?
  • Is the HTTP client configured to use the built-in certificate (certificate pinning) and authentication messages with HMAC?
  • Does the application keep user confidential information? Where?
  • Does the application save information outside the internal storage system?
  • Is the application logging when building the release?
  • Is the application code obfuscated?
  • Does your application provide an Android content provider, receiver, or service to other applications?
  • Is the debuggable option disabled in the release build?

Push Notifications

Push is a great mechanism to inform our users at any time, but it is a more complex problem than it seems at first glance.
  • Is a third-party library used to implement the push notification system?
  • Is the GCM system used to convey information to the application, or simply to display messages to the user?
  • How does the application behave when it receives push notifications?
  • How does the application behave when the information related to the push notification is not what was expected?
  • Are notifications displayed using the compatibility API?


Performance is important. Nobody wants to use a slow application on their expensive devices. Productivity is money.
  • Are there any memory leaks in the application?
  • Is any memory analyzer configured in the develop assembly, such as LeakCanary?
  • Is Android Strict Mode connected and configured in the develop build?
  • How are streams used in the application? Are you using async tasks, intent services or any other third-party libraries?
  • Does the number of background threads cause performance issues?
  • Do you use any scheduler policies or just create threads on demand?
  • Do you support Android Doze Mode?
  • Are network status events or any other recurring events from the operating system heard?
  • Is the main thread used only for 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 application user interface work at 60 frames per second?
  • Are there any custom views for which too much memory is allocated, or that perform "expensive" tasks in a UI thread?
  • Are you testing your application on lower-end (low-cost, non-productive) devices?
  • Is scrolling recycler view "slowing down"?
  • Is any third-party library used to download images or do you have your own solution?
  • Are the images scaled to fit the screen or are they immediately loaded for a specific device screen?
  • Is memory wise?
  • Is the "Static" modifier used correctly in Java?
  • Are all image processing tasks capable of processing multiple images at a time?
  • Does the statistics system work in the 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 or features (e.g. Login vs User)?
  • Are Java visibility modifiers used to hide implementation details inside packages?
  • Are all packages coming out of the root package?
  • Does the test directory repeat the structure of the source folder?
  • Are different features organized using the same package structure?
  • Are classes in the correct packages?
  • Are package uniform conventions respected?
  • Is the name of the root package associated with the company name?

Code Style A

consistent codebase in terms of style helps our engineers read code easier. An engineer reads MUCH more code than he writes, so this is an important concept.
  • Is the codestyle uniform?
  • Do you use Hungarian notation?
  • Is there any Checkstyle tool? Is it configured and working?
  • Does Java code match codestyle?
  • Do you use tabs or spaces?
  • Are the classes named correctly?
  • Do you use "I" as an interface prefix or "Impl" as implementation suffixes?
  • Are you using the correct variable names?
  • Are you using the correct names for the fields?
  • Are you using the correct names for the methods?
  • Are method attributes and visibility modifiers used properly?
  • Is the code written in English?
  • Do you use Javadoc?
  • Are you writing code comments?
  • Do you use constants or enums to avoid duplicate literals?

Offline implementation

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


Application architecture, from a code point of view, is one part of the audit that gives us a deeper understanding of the application. In our review of 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 the GUI (graphical user interface)? Model View Presenter or Model View ViewModel are two of the most commonly used application development templates. Are they implemented correctly?
  • Is the presentation layer implementation related to the view implementation?
  • Is a view implementation related to a model implementation?
  • Does the presentation layer include business logic?
  • Does the view implementation use the Android SDK tools correctly?
  • Do you use third-party libraries to simplify the implementation of the view?
  • Is the implementation of different functions divided by separate activities or fragments?
  • Is the behavior of the user interface uniform?
  • Do you use custom views to reuse user interface code?

Domain Implementation
  • Is there a separate domain layer or is the whole business logic implemented in the presentation layer?
  • Are domain rules and various application requirements expressed in the main objects of business logic?
  • Is the domain layer implemented using OOP principles?
  • Is the domain layer tied to the Android SDK or any third-party library?
  • Is the domain layer connected to the presentation layer?
  • Is the domain model "anemic"?
  • Do you use thick domain models?
  • Is the code based on loosely coupled and, at the same time, components that interact well with each other?
  • Is error handling implemented using exceptions or some other error handling mechanism?
  • Are data mapped between different layers?
  • Does the architecture of external components (such as database schemas or JSON parsing) affect the architecture of the domain model?
  • Developers abuse inheritance?
  • Is the code duplicated?
  • Are there dependency injection libraries or a configured service locator?
  • Is the complexity of classes and methods too high?

API implementation
  • Is the API implementation tied to the Android SDK?
  • Is there any “leak” through the API of any implementation details due to the HTTP client or the library used to implement the network layer?
  • Does the API client send the correct headers?
  • What is the behavior of the client API for various HTTP responses?
  • Does the client API implement an authentication mechanism?
  • Is the session resuming process implemented correctly?
  • Is there any support for JSON obfuscation?
  • Is the implementation of the API shared between different clients?

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

  • Does the application have tests?
  • Is the application testable?
  • Does the application use different types of (unit / integration / end-to-end) tests?
  • Are the tests named correctly?
  • Are the tests enough to cover the project?
  • Is there overspecification in the tests?
  • Is the lead time reasonable?
  • Is the code coverage too low?
  • Are there any ignored tests?
  • Are there any unstable tests (flaky tests)?
  • Do you use modern frameworks for testing?
  • Are there any tests without asserts?
  • Tests and production code are written by the same developers?
  • Do you have a QA team?
  • Do you have a QA team that automates part of the tests?
  • Do you have any continuous integration systems?
  • Do you use builders, factories or mothers to reduce the cost of creating some of the objects that are needed for the tests?
  • Are assertions tests correctly written?
  • Do you have 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?
  • Are you using any monkeyrunner?
  • Do you follow any TDD or BDD methodology?
  • Do you use Java to write test cases?

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

Posted by: Pedro Vicente Gómez Sánchez.
Thanks for helping translate
I cannot but mention those without whom this translation would be a terrible promt, which is a shame to share with the public.
Thank you for your help in translating and thoughtful proofreading to Kochkina Yana, Zaostrovsky Roman (@firsto), Polezhaev Maxim (@ itsme_42).
Special thanks for both KDPV, which were not in the original article, Kochkina Yana.

Alternative CAP
In memory of the once-very popular library from JakeWharton .

By the way, if ActionBarSherlock lives in your project to this day, then I recommend thinking about refreshing the project.

Also popular now: