Android Development resources

References -

1. http://mobileorchard.com/android-app-developmentthreading-part-1-handlers/
2. http://mobileorchard.com/android-app-developmentthreading-part-2-async-tasks/

My AVD commandline

"-scale 0.6 -qemu -m 512 -enable-kvm"

Android emulator taking too much of screen size?

Source: http://stackoverflow.com/questions/2359895/android-emulator-screen-too-tall

(Little modified)

Using AVD Manager

1. Open AVD Manager 
1. If using eclipse then Go to Window -> Android SDK and AVD Manager -> Virtual Devices
2. Select the AVD you want to launch and click Start
3. Check the "Scale display to real size" button
4. Enter how big you want it to appear in inches and press Launch. For this to work, you'll have to also enter a reasonable approximation of your mac's screen resolution. I'm using 7 inches and 113 dpi for my 13" Macbook Pro, but you may be able to get away with 8 or 9 inches.

While debugging (add this to command line)

Source: http://stackoverflow.com/questions/2359895/android-emulator-screen-too-tall/4963984#4963984

This is actually possible from your project as well, no need to start the emulator through the AVD manager:

1) go to Run > Run Configurations... > (Select your application on the left hand side) > (Click the "Target" tab on the right hand side). 2) At the bottom there, you'll see 'Emulator launch parameters'. In the 'additional emulator command line options', add '-scale 0.75' (to make the screen 75% of full size)

Next time you start the emulator it will have scaled properly, hooray!

Change when the Emulator is running

Source: http://stackoverflow.com/a/6049246

There is also a way to re size the emulator through a windows command prompt.

1. From command prompt run: telnet localhost 5554
2. window scale 0.75
3. quit

Assuming there is one emulator running with on port 5554.

Setting up adb on Linux for android development

Taken from - http://developer.android.com/tools/device.html#setting-up

Setting up a Device for Development

---

With an Android-powered device, you can develop and debug your Android applications just as you would on the emulator. Before you can start, there are just a few things to do:

1. Declare your application as "debuggable" in your Android Manifest.
   When using Eclipse, you can skip this step, because running your app directly from the Eclipse IDE automatically enables debugging.
   In the AndroidManifest.xml file, add android:debuggable="true" to the <application> element.
   Note: If you manually enable debugging in the manifest file, be sure to disable it before you build for release (your published application should usually not be debuggable).
2. Turn on "USB Debugging" on your device.
   On the device, go to Settings > Applications > Development and enable USB debugging (on an Android 4.0 device, the setting is located in Settings > Developer options).
3. Set up your system to detect your device.
   • If you're developing on Windows, you need to install a USB driver for adb. For an installation guide and links to OEM drivers, see the OEM USB Drivers document.
   • If you're developing on Mac OS X, it just works. Skip this step.
   • If you're developing on Ubuntu Linux, you need to add a udev rules file that contains a USB configuration for each type of device you want to use for development. In the rules file, each device manufacturer is identified by a unique vendor ID, as specified by the ATTR{idVendor} property. For a list of vendor IDs, see USB Vendor IDs, below. To set up device detection on Ubuntu Linux:
     1. Log in as root and create this file: /etc/udev/rules.d/51-android.rules.
        Use this format to add each vendor to the file:
        SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"
        
        In this example, the vendor ID is for HTC. The MODE assignment specifies read/write permissions, and GROUPdefines which Unix group owns the device node.
        Note: The rule syntax may vary slightly depending on your environment. Consult the udev documentation for your system as needed. For an overview of rule syntax, see this guide to writing udev rules.
     2. Now execute:
        chmod a+r /etc/udev/rules.d/51-android.rules

When plugged in over USB, can verify that your device is connected by executing adb devices from your SDKplatform-tools/ directory. If connected, you'll see the device name listed as a "device."

If using Eclipse, run or debug your application as usual. You will be presented with a Device Chooser dialog that lists the available emulator(s) and connected device(s). Select the device upon which you want to install and run the application.

If using the Android Debug Bridge (adb), you can issue commands with the -d flag to target your connected device.

USB Vendor IDs

This table provides a reference to the vendor IDs needed in order to add USB device support on Linux. The USB Vendor ID is the value given to the ATTR{idVendor} property in the rules file, as described above.

Company	USB Vendor ID
Acer	0502
ASUS	0b05
Dell	413c
Foxconn	0489
Fujitsu	04c5
Fujitsu Toshiba	04c5
Garmin-Asus	091e
Google	18d1
Hisense	109b
HTC	0bb4
Huawei	12d1
K-Touch	24e3
KT Tech	2116
Kyocera	0482
Lenovo	17ef
LG	1004
Motorola	22b8
NEC	0409
Nook	2080
Nvidia	0955
OTGV	2257
Pantech	10a9
Pegatron	1d4d
Philips	0471
PMC-Sierra	04da
Qualcomm	05c6
SK Telesys	1f53
Samsung	04e8
Sharp	04dd
Sony	054c
Sony Ericsson	0fce
Teleepoch	2340
Toshiba	0930
ZTE	19d2

My set of commands were -

# sudo nano /etc/udev/rules.d/51-android.rules

Inside file: SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", MODE="0666", GROUP="robin"

# sudo chmod a+r /etc/udev/rules.d/51-android.rules

Verified by  -

# adb devices

Android IO Schedulers

Taken from - http://www.vincentkong.com/wiki/-/wiki/Main/Android+IO+Schedulers

I/O Schedulers #

Anticipatory #

Based on two facts

1. Disk seeks are really slow.
2. Write operations can happen whenever, but there is always some process waiting for read operation.

So anticipatory prioritize read operations over write. It anticipates synchronous read operations.

Advantages

• Read requests from processes are never starved.
• As good as noop for read-performance on flash drives.

Disadvantages

• 'Guess works' might not be always reliable.
• Reduced write-performance on high performance disks.

BFQ #

Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

Advantages

• Believed to be very good for usb data transfer rate.
• Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
• Considered an accurate i/o scheduler.
• Achieves about 30% more throughput than CFQ on most workloads.

Disadvantages

• Not the best scheduler for benchmarking.
• Higher budget assigned to a process can affect interactivity and increased latency.

CFQ #

Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Advantages

• Considered to deliver a balanced i/o performance.
• Easiest to tune.
• Excels on multiprocessor systems.
• Best database system performance after deadline.

Disadvantages

• Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
• Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.

Deadline #

Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

Advantages

• Nearly a real time scheduler.
• Excels in reducing latency of any given single I/O.
• Best scheduler for database access and queries.
• Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
• Like noop, a good scheduler for solid state/flash drives.

Disadvantages

• When system is overloaded, set of processes that may miss deadline is largely unpredictable.

Noop #

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Advantages

• Serves I/O requests with least number of cpu cycles. (Battery friendly?)
• Best for flash drives since there is no seeking penalty.
• Good throughput on db systems.

Disadvantages

• Reduction in number of cpu cycles used is proportional to drop in performance.

SIO #

Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Advantages

• Simple, so reliable.
• Minimized starvation of requests.

Disadvantages

• Slow random-read speeds on flash drives, compared to other schedulers.
• Sequential-read speeds on flash drives also not so good.

V(R) #

Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.

Advantages

• May be best for benchmarking because at the peak of it's 'form' VR performs best.

Disadvantages

• Performance fluctuation results in below-average performance at times.
• Least reliable/most unstable.

References #

• http://forum.xda-developers.com/showpost.php?p=22134559&postcount=4

Android CPU Scaling Governors

Taken from - http://www.vincentkong.com/wiki/-/wiki/Main/Android+CPU+Scaling+Governors

Governors #

CPU governors control exactly how the CPU scales between your "max" and "min" set frequencies. Most kernels have "ondemand" and "performance". The availability

• brazilianwax - Similar to smartassv2 with more aggressive ramping, so more performance, less battery.
• conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
• intellidemand - Based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery (browsing mode).
• interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels. The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
• interactivex - This is an Interactive governor with a wake profile. More battery friendly than interactive.
• lazy - Basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. Try to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
• lagfree - Similar to ondemand, but the main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. If there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current.
• lionheart - Lionheart is a conservative-based governor. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
• lionheartx - Based on Lionheart, but has a few changes on the tunables and features a suspend profile based on smartass governor.
• luzactive - Based on interactive and smartass. On the old version when workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency. For the new version, three more user configurable parameters: inc_cpu_load,pump_up_step, pump_down_step. Can set the threshold at which governor decides to scale up/down and the number of frequency steps to be skipped while polling up and down.

When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less thaninc_cpu_load, governor scales CPU down pump_down_step steps down. Example:

inc_cpu_load=70
pump_up_step=2
pump_down_step=1

If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800. If current frequency=1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.

• ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
• ondemandx - An ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions.
• performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
• powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
• savagedzen - Based on smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
• smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
• smartassv2 - The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike smartass), so the entire frequency range is available for the governor to use during screen-on and screen-off state. This governor is a balance between performance and battery.
• userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.

Notes:

• Stay away from using 100mhz during screen-off or screen-on states for three reasons:
• It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online.
• 200 mhz can finish same task faster compared 100 mhz and thus hit deep idle soon.
• 200 mhz is the 'sweet spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy to run (Eg: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
• Best way to improve battery life is to limit scaling max freq to 800 or 1000 mhz. Sgs2 can do majority of the task with 1000 or 800 as the max. OCing to 1600mhz draws considerably more power than stock 1200mhz or even 1400mhz. Try scaling between 200 and 1000 mhz for a day and feel the difference.

References #

• http://www.setcpu.com/#7
• http://forum.xda-developers.com/showpost.php?p=19846276&postcount=1