In the second quarter of 2015, the share of Android in the global smartphone market rose to nearly 83%. Although iPhone is still the ‘rich man’s device’ and iPhone-users are more likely to spend money on applications (i.e., higher average revenue per user for developers) than their Android counterparts, the overwhelming dominance of Google’s mobile platform ensures that the TOTAL revenue it generates is higher, or at least close to, that by iOS. In fact, that is the reason why new app developers often prefer working on the Android platform first. Over here, we will do a roundup of some common errors and mistakes that any Android app developer might face while coding:
- Bugs in the emulator/device – The ADB, or Android Debug Bridge, handles all code interactions with actual devices and emulators (in Eclipse). The communication can break down at any time – and to rectify the problem, app makers have to click on ‘Window → Open Perspective →…’ and select the ‘DDMS Perspective’ option. After that, click on ‘Reset adb’ (from ‘View’), to restart the Debug Bridge. In case the problem persists, use the ‘adb kill-server’ and ‘adb start-server’ commands.
- Emulator does not start up – This is generally caused by a manual error. While coding for Android apps, if a developer makes a mistake (e.g., leaving an extra space) while writing out the path in which the SDK is present – the emulator would not be activated. Double check all the addresses and paths you have specified in your program. Looking for the error at the end in a long program can be frustrating.
- Android securityException error – Right from contacts and status of wifi connectivity, to SD card usage and web access – all permissions have to be declared separately in the application Manifest. Failure to do so will lead to the securityException Error being thrown up. Make sure you have followed the right Naming Conventions in your code as well (for all the IDs, variables, etc.).
- Problems with the LogCat – LogCat is one of the most useful features of the Android Studio (v.1.5.1 of the IDE was released in December). It allows mobile app developers to check all messages, errors and other exceptions from emulators and devices on a real-time basis. To activate LogCat, you need to browse to Window → Show View → Other →… Android → LogCat. At times, the LogCat can become unresponsive. To rectify matters, simply click on the ‘Restart’ tab. LogCat should be back to working fine.
- Version compatibility – Again, more of a developer error than a technical glitch. Testing new app prototypes on devices running on Android Lollipop is all very fine – but due attention has to be given for determining the backward compatibility of the application as well. There are two factors at work here: firstly, the extreme fragmentation in the rollout of Android versions makes it virtually impossible for developers to predict what version MOST or ALL of their targeted users are on; second, the Google Play Store accepts apps that are compatible with Android 2.2 Froyo. The more versions a new app is compatible with, the greater would be its downloads and overall user-base. Just because your application works like a charm on your own Android phone does not mean it will function properly on older devices as well.
- ActivityNotFoundException error – In the LogCat, this error can suddenly be generated – and the execution of your app will be halted immediately (or it might simply not start). The entire error message is ‘android.content:ActivityNotFoundException’, and it occurs when the AndroidManifest.xml file does not have all the explicit activities listed on it. Find out which activity(ies) you have not declared in the XML, and correct the error.
- Problems with @Override – Experts from the domain of the Android app development have identified the @Override annotation in Java as another probable cause for error. Problems occur when Java 1.6 is not selected as the working Java compiler level. Go to Properties → Java Compiler → Compiler Compliance Level, and set it to Java 1.6 – to get @Override functioning properly. Of course, you have the option of entirely deleting the annotation as well.
- StackOverflowError – If the Java code you have written for your Android app has multiple layouts, the StackOverflowError might rear its ugly head. The problem is also likely to occur when the app codes are infinitely recursive (making this both a Java and an Android problem). Whenever the layouts in the code go beyond the available program stack, this error message is thrown – and you will have to make the necessary corrections.
- Frequent crashes and freezes – Android Studio, according to most mobile app makers, is a more than worthy alternative to the Eclipse tool. However, the new IDE can crash suddenly and/or the display screen might freeze. If such problems start occurring rather frequently, you should uninstall the /Logs, /ApplicationSupport, /Caches and /Preferences folders from ‘Library’, delete the IDE next, and reinstall it (make sure that you have chosen the latest stable edition of Android Studio). Repeated crashes are clear signs that your existing IDE has become corrupt.
- Issues that require Project Cleaning – There are three common types of Android development errors, which can all be resolved by the ‘Clean Project’ option. If the ‘gen’ source folder cannot be opened, the R.java file cannot be accessed/opened, or the project simply cannot be created (mainly due to path errors), click on Project → Clean (from the ‘Projects’ menu). If additional libraries are being used, they need to be cleaned as well. You might have to repeat the process a couple of times to flush out the errors completely.
- The ANR error – ANR stands for ‘Application Not Responding’, and this error freezes the entire UI thread, preventing Android app developers from doing any work. Large processes that overuse network functions are most susceptible to this error. Adding a doBackground() as an extension of AsyncTask (which performs additional tasks). If you can ensure that the methods declared in the main thread do minimal work, the ANR problem is not likely to crop up.
- Unresponsive Android editor – Bugs and glitches in Android Development Tools (ADT) are the most common cause for this. The Android editor (which should open automatically) can become unresponsive. In such cases, you have to follow the Right Click (on menu) → Open With → Android Menu → Editor method, to manually open the Android editor. However, if the problem persists you might have to delete and reinstall the IDE.
- Field references exceeding maximum limit – Those who are into making Android apps can face this problem at the time of compiling their code. The ‘too many build references’ message gets displayed in the build console whenever one bytecode file contains more than 65536 references (which is the method limit). Using a large number of external libraries (the Google Play Services library, for instance) leads to incremental addition of new classes – resulting in this problem. To get things running properly again, developers have to make certain changes in the app gradle file. Going for a multidex configuration is another way to counter this error.
- Inadequate storage in emulator – 64M is all the space you get in the Android Virtual Device (AVD). This opens up the risk of large applications not getting installed in the emulator, and the INSTALL_FAILED_INSUFFICIENT_STORAGE notification being displayed. You can either change the data partition system in the AVD or use the ‘Wipe user data’ option (after rebooting the emulator), to clean up space.
While creating Android applications, developers might face problems while trying to delete certain virtual devices as well. In Eclipse, timeout during app deployment is a fairly common issue, and it can be addressed by changing the default timeout settings in the IDE. Trying to enter the same fragment more than once also generates an error message (Binary XML file Duplicate ID). Even the best app developers can face these problems while working on the Android platform, and you should be aware of how to get rid of them quickly.