Skip to main content

MobiSpec Analyzer

vProject: I have been part of a project is called MobiSpec Analyzer.

v Purpose: Its purpose is to extract detailed information about various phone properties using adb commands, compare the specs across multiple phones, and analyze which phone is superior in different aspects. The results were presented through summary reports in Excel and JSON formats.

v Initial Approach: Initially, we extracted all the information manually by executing commands in the command-line interface. This included gathering data on CPU specs, hardware details, battery properties, and display specifications. 

  • Phone properties were extracted manually using adb commands and grep in the command-line interface.
  • Commands were executed individually to retrieve CPU specs, hardware details, battery properties, camera specifications and so on.
  • Each property required separate commands, leading to repetitive execution for each device.
  • Data outputs were stored in multiple files, one for each device, creating organizational and storage challenges.
  • Variability in data collection methods and manual execution led to inconsistencies in the gathered information.
  • Different devices produced different formats or structures of data, complicating the comparison process.
  • Manual execution was time-consuming which slowed down the overall progress, requiring significant human effort for each device.
  • Handling large volumes of data manually became increasingly difficult as the project expanded.

v Challenges: But  we noticed that the data we collected varied greatly, making it difficult to compare and keep consistent records across multiple phones. This inconsistency and the manual effort required made the process difficult.

v Solution Development: To address these issues, we designed an automated framework to retrieve this information. We aimed to build a baseline framework which was later expanded by adding scripts for automated retrieval of phone properties.


 AUTOMATION FRAMEWORK DIRECTORY STRUCTURE

 Organizing files and folders is crucial for maintaining content efficiently.

Base: This folder contains base classes  that define common functionalities.

  • ADB.py: Handles interactions with Android Debug Bridge (ADB).
  • Commands.py: Contains definitions for various device commands.
  • FrameworkConstants.py: Defines constants used throughout the framework.
  • LogConf.py: Configures logging settings.
  • init.py: Initializes the Base module.

Lib: This folder includes libraries for interacting with devices and parsing data.

  • FileSystemUtils.py: Provides utilities for file system operations.
  • LibUtils.py: Contains general utility functions used across the project.
  • ParserUtils.py: Includes functions for parsing device data.
  • init.py: Initializes the Lib module.

Logs: Stores logs from running the project.

Runner: Contains the main script to start grepinfo.

  • Runner.py: The main script to execute the test suite and trigger device spec collection.
  • init.py: Initializes the Runner module.

SpecsInfo: This folder contains specification files detailing various device properties.

  • CpuSpecsInfo.py: Information about CPU specifications.
  • HwSpecsInfo.py: Details about hardware specifications.
  • MobileSpecsInfo.py: Comprehensive mobile specifications.
  • SwSpecsInfo.py: Information about software specifications.
  • CameraSpecsInfo.py: Information about camera specifications.
  • init.py: Initializes the SpecsInfo module.

Test: Contains the actual test cases and scripts for different scenarios.

  • GrepInfo.py: Test script for extracting specific information.
  • Run.py: Script to run the test cases.
  • init.py: Initializes the Test module.

This structured approach ensures clarity and maintainability, making it easier to navigate and manage your project files.

 

CLASS DIAGRAM

Core Functional Classes (Green)

These are instantiable classes accessible through instances/objects and represent different core functionalities:

  • ADBinfo: Handles ADB commands and information, closely working with the Commands class to execute these commands on the device.
  • Commands: Manages the execution of shell commands on the device.
  • FilePaths: Helps in managing file paths used throughout the project.
  • MobileSpecsinfo: Main class for handling mobile device specifications. It serves as a parent class for  various specifications, such as hardware, CPU, and software specifications.

Interactions and Workflows:

  • Setup: Initializes the environment.
  • CmdObj: Interacts with ADBObj to execute commands.
  • FpObj: Provides file paths for storing outputs.
  • Grepinfo: Searches through outputs for specific patterns.
  • Cleanup: Restores the environment.

Method:

  • executeCommandOnDevice: Integrates functionalities from CmdObj, ADBObj, and FpObj to execute commands and handle outputs seamlessly.

Static Function Classes (Orange)

These utility classes do not require instantiation and are accessible through class names:

LogConf:

  • configureLogging: Sets up how logs should look, where they should be saved, and what kind of messages should be logged.
  • handler: Decides whether logs go to the console or to a file.
  • getConsoleLog: Fetches messages displayed on the console to understand what happened during execution.
  • get/setShellValue: Changes or retrieves a value related to shell operations, customizing logging based on commands run in the shell.

Lib Section: Includes utility classes for file handling and data parsing.

FileSystemUtils:

  • createJsonFromDict: Converts a dictionary into a JSON file for saving data in a structured format.
  • searchFile: Searches for a file in a directory to quickly locate files like logs or configurations.

ParserUtils:

  • parseDataViaRegex: Uses a regex pattern to search through text and find matches for further processing, such as finding email addresses, dates, IP addresses, or error messages.

Trigger Class (Blue)

This class is utilized for triggering execution and initiating primary actions in the project:

  • Runner: Contains the main script (Runner.py) to start grepinfo, executing the test suite and triggering device spec collection.

Test Section

Grepinfo Class:

  • Functionality: Performs operations searching for specific patterns in text files or streams.

Compareinfo Class:

  • Functionality: Provides methods to compare files or outputs to determine similarities or differences.

Summaryinfo Class:

  • Purpose: Generates summaries or reports based on test results.


SEQUENCE DIAGRAM


  1. Start: The process begins with the initiation of the project.
  2. Run.py Execution: The execution of the Run.py file is triggered, which serves as the entry point for the project.
  3. Command Line Argument : The project takes a command line argument "" which helps in locating the complete path.
  4. Instantiates Testobj: Upon locating the complete path, the project instantiates a Testobj, representing the test object.
  5. Test Object Setup: The setup phase of the Testobj creates either hardware (hw) or CPU software (cpu) specifications information object (SwSpecsInfo obj).
  6. Execute: The Testobj then calls the execute() method to start the execution process.
  7. Generate Specsinfo JSON: Within the execute() method, there's a call to generate specsinfo JSON, which involves creating specifications information.
  8. Grepinfo Process: The project then proceeds to the grepinfo process, where it searches for specific information within files.
  9. ADB Object Creation: During the grepinfo process, ADBObJ, fpobj, and cmmdobj are created.
  10. ADB Function Call: ADB function is invoked to retrieve the adbCommand.
  11. Execute Command On Device: The retrieved command is executed on the device, and the result is returned.
  12. Fill Specsinfo Dictionary: The result obtained from the device is used to fill the Specsinfo dictionary with relevant information.
  13. Generate JSON and Log: The filled Specsinfo dictionary is used to generate a relevant JSON file and console output log.
  14. Generate XLS Device Collation: Multiple JSON files per device are collated to generate an XLS device file.
  15. Generate Summary of Different Specs: Summary of different specifications is generated based on the collated information.
  16. Generate Comparative Info: If multiple device specifications are available, a comparative info summary report is generated.
  17. Summary Report Generation: The summary report can be either in XLS or HTML format.
  18. Stop: The process concludes here.

v Role and Contributions: I was part of the team responsible for designing and developing this automation framework. My specific contributions included implementing scripts for the automated extraction of camera properties and ensuring the framework was scalable and reliable across all aspects, converting the results from Excel format  into JSON format to ensure accessibility and ease of viewing.

v Motivation and Benefits: The motivation behind developing this automation framework was to:

o   Reduce manual work

o   Increase scalability

o   Establish consistent execution steps

o   Eliminate human errors

o   Enhance productivity

v Key Takeaways: Throughout the project, I gained a deep understanding of Android architecture and its underlying components. I also improved my Python coding skills, particularly in implementing object-oriented concepts, and expanded my knowledge of designing automation frameworks.


Comments

Post a Comment

Popular posts from this blog

PROJECT GREPINFO

INTRODUCTION Project Name:  GrepInfo Purpose:   An automated framework for retrieving device specifications. Developed In Purpose:  Python Specification to be Collected: Hardware Specifications Software Specifications CPU Specifications Memory Specifications Display Specifications   ROOTED VS NON- ROOTED DEVICES Rooted Devices: Rooted devices are like super-powered phones that let you change almost anything you want. You can customize your phone to do things it couldn't do before, like making it faster or removing apps you don't need. Non-Rooted Devices: Non-rooted devices are like regular phones that stick to the rules set by the phone's maker. They're safer and more stable, but you can't tweak them as much as rooted phones.   T YPES OF DEVICES FOR RETRIEVING SPECS 1. Commercial Devices (Non-Rooted Devices): Description:  Standard smartphones ...
Post a Comment
Read more

MobiSpec Analyzer SDLC

The SDLC involves planning the project, gathering requirements, designing the system, coding the software, testing it for issues, deploying it to users, and maintaining it post-release. Each phase ensures the software meets user needs and functions correctly, from start to finish. Stage-1: Planning and Requirement Analysis Planning: Define the project goals: Automate the extraction of phone properties, enabling the comparison of multiple phone specs and determining the superior phone in various aspects, with results presented through summary reports in Excel and JSON formats. Identify stakeholders: Developers, end-users, and potential clients. Conduct feasibility study: Assess technical feasibility which involves evaluating if the project can effectively use available technology and resources. Economic feasibility assesses if the project's benefits justify the costs associated with developing and maintaining the automation framework. Risk analys...
Post a Comment
Read more