Frequent Errors and Solutions
- Dagger Unresolved reference
- Crashing layout tags in tablet
- Push failed
- Facing error while debugging code
Error: Unresolved reference DaggerXXTest_TestApplicationComponent
Solution: Don't worry this is not an error. Just run the test file and it will solve the error. For running tests, you can see Oppia Android Testing document.
Error: java.lang.IllegalArgumentException: The tag for topic_lessons_title is invalid. Received: layout-sw600dp-port/topic_lessons_title_0 Solutions: This error occurs when we remove any xml file which is related to tablet devices To solve this
- Uninstall the app from tablet
- Rebuild the app.
- Run the app again.
Error: Failed to push some refs to git@github.com:<your_user_name>/oppia-android.git
Solution: If you are using Android Studio or another UI-based git to push and got the above error, this might not provide many details. Try to push using the command line. Also, we suggest using the command line, as all our scripts, project building, APK building are done using the command line as we are moving towards the Bazel build system and removing the Gradle build system.
If there is an error with any of the lint failures it will be detailed in the command line itself.
Whenever you are debugging a problem, you may find it useful to keep a record of your debugging process. We often do this already in issues. Issues usually begin with a detailed description of the problem, which is followed by discussion, reports of attempted debugging steps, and what root cause was identified. However, issues' linear comment structure makes them more amenable to communication among team members than organizing your thoughts. Debugging docs, on the other hand, serve primarily to organize your thoughts.
Primarily, debugging docs help keep your thoughts organized. When you have written down the steps you've already tried and the results of your investigations, you don't have to worry about forgetting your earlier work. Further, when you document your work, you force yourself to reflect on what you've already tried. Debugging docs also make it easy for you to bring someone else up to speed on your bug.
Your description should include:
- Context: What branch or PR is the bug happening on? If this is happening locally, what system are you running, and what code changes have you made?
- How the Bug Manifests: This might include error logs that you pasted into the document, screenshots, or links to a test run on a PR. If you provide a link, copy the relevant part of the page you are linking to. This keeps the document self-contained so we can search them. It also makes the doc easier for people to read.
What did you try, and what happened when you tried it? You want to include enough detail so that someone could reproduce your investigation to see if they get the same results.
After some investigation, you might have some ideas for what might be going wrong. Document your guesses and describe how you go about testing them. Report the results of that testing and describe whether you think your guess was right. What's your reasoning?
Keep going! Continue documenting your investigations, guesses, and tests of those guesses. You can share your debugging doc with your assigned onboarding mentor to review and help you in finding the root cause of the issue or the solution.
Once you figure out what the problem was, write that down too! Include an analysis of how the root cause you identify caused the errors you described at the top. Often, this will take the form of one of your suspected solutions.
Ready to get started with your own debugging doc? You can make a copy of this template to get started.