Android - Runtime enable/disable debug options

  I have been used to control application debug options via adb shell or recompilation with debug turned on etc. Although this works fine, in some cases its not convenient, especially when testers work on the applications.

   So found this nice little trick that lets anyone enable and disable debug options. It doesn't need the app to be recompiled or access to adb. Users would just need to increase or decrease the volume to control the debug options.


   DebugActivity extends Activity {

          public boolean dispatchKeyEvent (KeyEvent event) {

                 final int keyCode = event.getKeyCode();
                 if (keyCode == KeyEvent.KEYCODE_VOLUME_UP) {
                      // Enable Debug options
                 } else if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
                      // Disable Debug options
                 }

          }

   }

Comments

Post a Comment

Popular posts from this blog

Android Shared User ID and android:process

      Android's shared user id (android:sharedUserId) is a way for different applications to share the same user id for permissions, which lets them access their data and host their components in other process space. By declaring a new sharedUserId in the manifest, a new user id is creating during installation and is ready to be used by other applications provided they are signed with the same certificate and one such use is to update android:process of an application component to host it in other process space.    However, if the applications don't share a user id and aren't signed with the same certificate, a new process is launched with the same name as in android:process and this new process automatically shares userId with the requested application.    If the applications share user id and and aren't signed by the same certificate, the installation of the apk would fail.     If the applications share user id and are signed by the ...
Read more

Android's Watchdog daemon

    Android framework's Watchdog (Java implementation) is meant to handle cases when the framework ends up in an unresponsive state. However, this doesn't help handle kernel or other OEM specific driver issues. Chip vendors usually provide a hardware watchdog to hard reset the system to handle software failures. The hardware watchdog just waits to be reset by software within a specific duration and force resets the system if otherwise. The hardware watchdog is just handled by a vendor specific watchdog driver and it exposes IOCTL APIs for user space to set timeout interval, reset the watchdog etc. So does Android provide any support?     Its supported by a daemon process (/sbin/watchdogd) and OEMs could use this to fine tune timeout intervals or even completely disable it. watchdogd is really a symbolic link to init process.     lrwxrwxrwx root     root              1969-12-31 19:00 watchdogd -> ../init ...
Read more

Android : Watchdog is killing system server

Here goes my first fix in Android. Watchdog of the android framework is implemented to make sure the framework is rebooted in case of non-recoverable errors like deadlocks etc. Usually, i have seen frameworks where in the entire phone is rebooted upon such errors. Android is smart in the sense that its efficient by offering the framework reboot within seconds [Technically, it is just spawning of a linux process, system_server]. Monkey is a tool available to feed in random key events for stress testing and we happened to see a lot of scenarios where in the watchdog would kill the system server, causing android framework reboot. It seemed as if the root cause was within the framework and moreover it was random key events passed to the framework over many hours. The pattern to reproduce was not known but yet happened quite often. Like all bugs, it turned out to be 100% reproducible just that it took time to figure out the pattern. Monkey has an activitycontroller to report ANRs an...
Read more