[READ BEFORE ASKING]CoMMON ANDROID TERMS, VERSIONS AND CAF*[FOR EVERYONE] - Galaxy Ace S5830 General

(*CAF - Custom Aftermarket Firmware.)
This thread is courtesy of Diablo67 in the Android General forum..obviously not many go there and read and then ask questions to which answers already exist..so please..new and old users..go through this ASAP
Apps2SD:A method of storing applications and cache on the device's microSD card.
ADB:Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
•A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
•A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
•A daemon, which runs as a background process on each emulator or device instance.
Android:A Linux-based operating system for mobile devices such as HTC EVO.Versions are alphabetically codenamed after snacks: Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, Jelly Donut.
AMOLED:Active Matrix Organic Light Emitting Diode. Basically, a very colorful, bright, display found in some smartphones.
APK:Android application package file. Each Android application is compiled and packaged in a single file that includes all of the application's code (.dex files), resources, assets, and manifest file. The application package file can have any name but must use the .apk extension. For example: myExampleAppname.apk. For convenience, an application package file is often referred to as an ".apk".
Alpha:The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test the software using white box techniques. Additional validation is then performed using black box or gray box techniques, by another testing team. Moving to black box testing inside the organization is known as alpha release.[1]
Alpha software can be unstable and could cause crashes or data loss. The exception to this is when the alpha is available publicly (such as a pre-order bonus), in which developers normally push for stability so that their testers can test properly. External availability of alpha software is uncommon in proprietary software. However, open source software, in particular, often have publicly available alpha versions, often distributed as the raw source code of the software.
The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be a feature complete.
Boot Animation:Boot animation is a term for a graphical representation of the boot process of the operating system.
Boot animation can be a simple visualisation of the scrolling boot messages in the console, but it can also present graphics or some combinations of both.
Unlike splash screens, boot screen or boot animation is not necessarily designed for marketing purposes, but can be to enhance the experience of the user as eye candy, or provide the user with messages (with an added advantage of color coding facility) to diagnose the state of the system.
Bootloader:This small program's only job is to load other data and programs which are then executed from RAM.Often, multiple-stage boot loaders are used, during which several programs of increasing complexity load one after the other in a process of chain loading.
Bootloop:When your system recycles over and over without entering the main OS.
Beta: is the software development phase following alpha. It generally begins when the software is feature complete. Software in the beta phase will generally have many more bugs in it than completed software, as well as speed/performance issues. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it.
The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software, willing to test the software without charge, often receiving the final software free of charge or for a reduced price.
Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as a preview, prototype, technical preview (TP), or early access.
Some software is kept in perpetual beta—where new features and functionality is continually added to the software without establishing a firm "final" release.
CPU:It stands for Central Processing Unit and handles all the complex mathematical formulas necessary to do everyday things like surfing the Internet.
Custom:Independent developers who like to customize their devices beyond the standard options provided often tend to release the fruits of their labor for the rest to enjoy, in form of custom ROMs.
Cache:A component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache miss), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the greater the number of requests that can be served from the cache, the faster the overall system performance becomes.
CDMA:Mobile phone standards called cdmaOne, CDMA2000 (the 3G evolution of cdmaOne) and WCDMA (the 3G standard used by GSM carriers), which are often referred to as simply CDMA, and use CDMA as an underlying channel access method.
CIQ:Carrier IQ. A piece of preinstalled software that runs with elevated access in the background of portable devices by default and records everything. Potentially can be exploited to steal information.
Dual Core:A dual core processor is a central processing unit (CPU) that has two separate cores on the same die, each with its own cache. It essentially is two microprocessors in one. This type of CPU is widely available from many manufacturers. Other types of multi-core processors also have been developed, including quad-core processors with four cores each, hexa-core processors with six, octa-core processors with eight and many-core processors with an even larger number of cores.
Dalvik:The Android platform's virtual machine. The Dalvik VM is an interpreter-only virtual machine that executes files in the Dalvik Executable (.dex) format, a format that is optimized for efficient storage and memory-mappable execution.
Dalvik Cache:Writable cache that contains the optimized bytecode of all apk files (apps) on your Android device. Having the information in it's own cache makes applications load faster and perform better.
EXT2:The ext2 or second extended filesystem is a file system for the Linux kernel. It was initially designed by Rémy Card as a replacement for the extended file system (ext).
ext2 was the default filesystem in several Linux distributions, including Debian and Red Hat Linux, until supplanted more recently by ext3, which is almost completely compatible with ext2 and is a journaling file system. ext2 is still the filesystem of choice for flash-based storage media (such as SD cards, and USB flash drives) since its lack of a journal minimizes the number of writes and flash devices have only a limited number of write cycles. Recent kernels, however, support a journal-less mode of ext4, which would offer the same benefit along with a number of ext4-specific benefits.
EXT3:Third extended filesystem, is a journaled file system that is commonly used by the Linux kernel. It is the default file system for many popular Linux distributions, including Debian. Stephen Tweedie first revealed that he was working on extending ext2 in Journaling the Linux ext2fs Filesystem in a 1998 paper and later in a February 1999 kernel mailing list posting, and the filesystem was merged with the mainline Linux kernel in November 2001 from 2.4.15 onward.Its main advantage over ext2 is journaling, which improves reliability and eliminates the need to check the file system after an unclean shutdown. Its successor is ext4.
EXT4:It was born as a series of backward compatible extensions to ext3, many of them originally developed by Cluster File Systems for the Lustre file system between 2003 and 2006, meant to extend storage limits and add other performance improvements.However, other Linux kernel developers opposed accepting extensions to ext3 for stability reasons,and proposed to fork the source code of ext3, rename it as ext4, and do all the development there, without affecting the current ext3 users. This proposal was accepted, and on 28 June 2006, Theodore Ts'o, the ext3 maintainer, announced the new plan of development for ext4.
FC/FC's:Short for "force close," meaning an app that has crashed.
Fastboot:A diagnostic protocol used primarily to modify the flash filesystem in Android smartphones from another computer over a USB connection. It is part of the Android Debug Bridge library.
Utilizing the Fastboot protocol requires that the device be started in a boot loader or Second Program Loader mode in which only the most basic hardware initialization is performed. After enabling the protocol on the device itself it will accept any command sent to it over USB via a command line. Some of most commonly used fastboot commands include:
•flash - Overwrites a partition in flash with a binary image stored on the host computer.
•erase - Erases a partition in flash.
•reboot - Reboots the device into the either the main operating system or the system recovery partition.
•devices - Displays a list of all devices (with Serial #) connected to the host computer.
Flashing:The ROM memory used in smartphones and tablets etc. is often same as flash memory found in SD cards and USB flash drives, simply optimized for better speed and performance while running the operating system.
Hotspot:A spot that offers Internet access over a wireless local area network through the use of a router connected to a link to an Internet service provider. Hotspots typically use Wi-Fi technology.You can connect wifi campatible devices to it.
HDMI:High-Definition Multimedia Interface) is a compact audio/video interface for transmitting encrypted uncompressed digital data.It is a digital alternative to consumer analog standards, such as radio frequency (RF) coaxial cable, composite video, S-Video, SCART, component video, D-Terminal, or VGA (also called D-sub or DE-15F). HDMI connects digital audio/video sources (such as set-top boxes, DVD players, HD DVD players, Blu-ray Disc players, AVCHD camcorders, personal computers (PCs), video game consoles (such as the PlayStation 3 and Xbox 360), AV receivers, tablet computers, and mobile phones) to compatible digital audio devices, computer monitors, video projectors, and digital televisions.
Kang:Someone writes a code,someone else modifies the code to make their own release,its concidered a kang release.
Kernel:A kernel is a layer of code that allows the OS and applications to interface with your phone's hardware. The degree in which you can access your phone's hardware features depends on the quality of code in the kernel. The homebrew (rooting) community for HTC has made several kernel code improvements that give us additional features from our hardware that the stock kernel does not. When you flash a custom ROM, you automatically get a kernel. But you can also flash a standalone kernel ROM on top of the existing one, effectively overwriting it. These days, the difference in custom kernels is less about new features and more about alternate configurations. Choosing a custom kernel is basically choosing one that works best with your ROM.
Launcher:Collectively, the part of the Android user interface on home screens that lets you launch apps, make phone calls, etc. Is built in to Android, or can be purchased in the Android Market.
LCD Densityixel density is a measurement of the resolution of devices in various contexts; typically computer displays, image scanners, and digital camera image sensors.
First of all you need to understand that the Android User Interface uses something called a "display independent pixel" or a "dip" (yes, it's confusing because the density settings are in "dots per inch" or "dpi" which are considered the same as "ppi" or "pixels per inch" as well).
The default LCD Density setting on Android is 160 dpi. As far as the operating system is concerned 1 dip @ 160 dpi = 1 screen pixel. It doesn't mean that's actually true, but you've gotta start somewhere. In my opinion it would have been a lot nicer if they'd chosen 100 dpi because then it would be an easy percentage thing, but they didn't so we're stuck with this formula.
Mod:The act of modifying a piece of hardware or software or anything else for that matter, to perform a function not originally conceived or intended by the designer.
Nandroid:To backup the current running rom.
Nightly:A build that is performed at the end of each day of development. If you use a continuous integration server, it will generally be configured to build the code and run the unit tests on every check in. At the end of each day you may want to run more extensive tests, regression test and integration tests for example, which take too long to run on each check in and these would be triggered after the nightly build. If you have a full continuously delivery pipeline the nightly build may also be used to deploy the built code to environments for user testing.
Open GL:An open source 3D graphics library used in many devices, including Android devices.
Open & Closed Beta: Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test and are invitation only, while open betas are from a larger group to the general public and anyone interested. The testers report any bugs that they find, and sometimes suggest additional features they think should be available in the final version.
Overclock:To increase the speed of your CPU.
Partition:The phone's internal memory (not the SD card) is solid-state (flash) memory, AKA NAND. It can be partitioned much like a normal hard drive can be partitioned. The bootloader exists in its own partition. Recovery is another partition; radio, system, cache, etc are all partitions.
Here are the standard partitions on an Android phone:
/misc - not sure what this is for.
/boot - bootloader, kernel
/recovery - holds the recovery program (either clockworkmod or RA recovery for a rooted Evo)
/system - operating system goes here: Android, Sense, boot animation, Sprint crapware, busybox, etc
/cache - cached data from OS usage
/data - user applications, data, settings, etc.
Recovery Mode:A small separate operating mode you can boot your device into, used for device administration. Two popular custom recovery modes are Amon Ra and Clockwork.
Rom/Firmware:Read-Only Memory and technically speaking, it refers to the internal storage of a device, which is supposed to contain the operating system instructions that needn’t be modified at all during the device’s normal operation.
Recovery Mode:A small separate operating mode you can boot your device into, used for device administration. Two popular custom recovery modes are Amon Ra and Clockwork.
Rom/Firmware:Read-Only Memory and technically speaking, it refers to the internal storage of a device, which is supposed to contain the operating system instructions that needn’t be modified at all during the device’s normal operation.
Ram: (Random Access Memory) A group of memory chips, typically of the dynamic RAM (DRAM) type, which function as the computer's primary workspace. When personal computers first came on the market in the late 1970s, 64KB (64 kilobytes) of RAM was the upper limit. Today, 64MB (64 megabytes) of SDRAM is entry level for a desktop computer, a thousand times as much (see SDRAM).
The "random" in RAM means that the contents of each byte of storage in the chip can be directly accessed without regard to the bytes before or after it. This is also true of other types of memory chips, including ROMs and PROMs. However, unlike ROMs and PROMs, RAM chips require power to maintain their content, which is why you must save your data onto disk before you turn the computer off. To learn about the types of RAM chips and how to upgrade your memory, see memory module. To learn how memory is used to process data, see computer or memory. See also dynamic RAM and static RAM.
Recovery:RecoverySystem contains methods for interacting with the Android recovery system (the separate partition that can be used to install system updates,wipe user data,etc).
Root:The first level of a folder.
Rooting:A process allowing users of mobile phones, tablet PCs, and other devices running the Android operating system to attain privileged control (known as "root access") within Android's subsystem. Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices, resulting in the ability to alter or replace system applications and settings, run specialized apps that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user. Rooting is analogous to jailbreaking devices running the Apple iOS operating system or the Sony PlayStation 3. On Android, rooting can also facilitate the complete removal and replacement of the device's operating system.
SBC: (the ability to charge your battery beyond the default safe limit). The concept is similar to overclocking a processor: you're overriding the safety limits established to achieve additional performance. The benefit here is that you may gain more use of your battery per charge. The drawback is that you can damage the battery and significantly reduce its longevity. Some kernels claim they are using a safe technique to prevent battery damage. Just be aware of the potential risks.
Sideloading:It means installing applications without using the official Android Market.
Splash Screen:A splash screen is an image that appears while android is loading.Splash screens cover the entire screen or simply a rectangle near the center of the screen. The splash screens of operating systems and some applications that expect to be run full-screen usually cover the entire screen.
Superuser/SU:On many computer operating systems, the superuser is a special user account used for system administration. Depending on the operating system, the actual name of this account might be: root, administrator or supervisor.
Normal work on such a system is done using ordinary user accounts, and because these do not have the ability to make system-wide changes any viruses and other malware - or simple user errors - do not have the ability to adversly affect a whole system. In organizations, administrative privileges are often reserved for authorized experienced individuals.
Script:The Scripting Layer for Android (abridged as SL4A, and previously named Android Scripting Environment or ASE) is a library that allows the creation and running of scripts written in various scripting languages directly on Android devices. SL4A is designed for developers and is still alpha quality software.
These scripts have access to many of the APIs available to normal Java Android applications, but with a simplified interface. Scripts can be run interactively in a terminal, in the background, or via Locale.
SDK: (SDK or "devkit") is typically a set of software development tools that allows for the creation of applications for a certain software package, software framework, hardware platform, computer system, video game console, operating system, or similar platform.
Stock:This is the operating system in its default form, without any modifications made to it except for any device-specific support required to run it on the particular device.
Tethering:Means sharing the Internet connection of an Internet-capable mobile phone with other devices. This sharing can be offered over a wireless LAN (Wi-Fi), Bluetooth, or by physical connection using a cable. In the case of tethering over wireless LAN, the feature may be branded as a mobile hotspot.The Internet-connected mobile phone acts as a portable router when providing tethering services to others.
Underclock:To reduce the speed of your CPU.
Undervolt:Undervolting means taking some of the voltage from the CPU which in return gives a longer battery life and lower temperature during intensive use of the CPU.
USB:Stands for Universal Serial Bus. Is a method of connecting devices to a computer. Most smartphones now use microUSB cables to charge and sync.
Updater Script:When Android devices install updates via 'update.zip' files using recovery mode they have to perform a wide range of functions on files and permissions. Instead of using a minimal shell such as {b,d,c}sh the Android designers decided to create a small functional language that can be extended by device manufacturers if necessary. Since the Android "Donut" release (v1.6) the scripting language is called Edify and is defined primarily in the bootable/recovery/{edify,edifyscripting,updater} directories of the Android source-code tree.
Click to expand...
Click to collapse

Nice work

BELOW IS THE DETAILED LIST OF ALL ANDROID VERSIONS AND DETAILS.
1.0:Android 1.0, the first commercial version of the software, was released on 23 September 2008.The first Android device, the HTC Dream (G1), incorporated the following Android 1.0 features:
•Android Market application download and updates through the Market app
•Web browser to show, zoom and pan full HTML and XHTML web pages – multiple pages show as windows ("cards")
•Camera support – however this version lacked the option to change the camera's resolution, white balance, quality, etc.
•Folders allowing the grouping of a number of app icons into a single folder icon on the Home screen.
•Access to web email servers, supporting POP3, IMAP4, and SMTP.
•Gmail synchronization with the Gmail app
•Google Contacts synchronization with the People app
•Google Calendar synchronization with the Calendar app
•Google Maps with Latitude and Street View to view maps and satellite imagery, as well as find local business and obtain driving directions using GPS
•Google Sync, allowing management of over-the-air synchronization of Gmail, People, and Calendar
•Google Search, allowing users to search the Internet and phone apps, contacts, calendar, etc
•Google Talk instant messaging
•Instant messaging, text messaging, and MMS
•Media Player, enabling management, importing, and playback of media files – however, this version lacked video and stereo Bluetooth support
•Notifications appear in the Status bar, with options to set ringtone, LED or vibration alerts
•Voice Dialer allows dialing and placing of phone calls without typing a name or number
•Wallpaper allows the user to set the background image or photo behind the Home screen icons and widgets
•YouTube video player
•Other apps include: Alarm Clock, Calculator, Dialer (Phone), Home screen (launcher), Pictures (Gallery), and Settings.
•Wi-Fi and Bluetooth support
1.1:On 9 February 2009, the Android 1.1 update was released, initially for the T-Mobile G1 only. The update resolved bugs, changed the API and added a number of other features:
•Details and reviews available when a user searches for businesses on Maps
•Longer in-call screen timeout default when using the speakerphone, plus ability to show/hide dialpad
•Ability to save attachments in messages
•Support added for marquee in system layouts
Click to expand...
Click to collapse
FrOM HERE ON, GOOGLE DECIDED TO NAME THEIR VERSIONS IN ALPHABETICAL ORDER, STARTING WITH C, AS 2 VERSIONS HAD ALREADY BEEN RELEASED.
Cupcake:On 30 April 2009, the Android 1.5 update, dubbed Cupcake, was released, based on Linux kernel 2.6.27.The update included several new features and UI amendments:
•Support for third-party virtual keyboards with text prediction and user dictionary for custom words
•Support for Widgets - miniature application views that can be embedded in other applications (such as the Home screen) and receive periodic updates
•Video recording and playback in MPEG-4 and 3GP formats
•Auto-pairing and stereo support for Bluetooth added (A2DP and AVRCP profiles)
•Copy and paste features added to web browser
•User pictures shown for Favorites in Contacts
•Specific date/time stamp shown for events in call log, and one-touch access to a contact card from call log event
•Animated screen transitions
•Ability to upload videos to YouTube
•Ability to upload photos to Picasa
Donut:On 15 September 2009, the Android 1.6 SDK – dubbed Donut – was released, based on Linux kernel 2.6.29.Included in the update were numerous new features:
•Voice and text entry search enhanced to include bookmark history, contacts, and the web
•Ability for developers to include their content in search results
•Multi-lingual speech synthesis engine to allow any Android application to "speak" a string of text
•Easier searching and ability to view app screenshots in Android Market
•Gallery, camera and camcorder more fully integrated, with faster camera access
•Ability for users to select multiple photos for deletion
•Updated technology support for CDMA/EVDO, 802.1x, VPNs, and a text-to-speech engine
•Support for WVGA screen resolutions
•Speed improvements in searching and camera applications
•Expanded Gesture framework and new GestureBuilder development tool
Eclair:On 26 October 2009, the Android 2.0 SDK – codenamed Eclair – was released, based on Linux kernel 2.6.29.Changes included:
•Expanded Account sync, allowing users to add multiple accounts to a device for email- and contact-synchronization
•Exchange email support, with combined inbox to browse email from multiple accounts in one page
•Bluetooth 2.1 support
•Ability to tap a Contacts photo and select to call, SMS, or email the person
•Ability to search all saved SMS and MMS messages, with delete oldest messages in a conversation automatically deleted when a defined limit is reached
•Numerous new camera features, including flash support, digital zoom, scene mode, white balance, color effect and macro focus
•Improved typing speed on virtual keyboard, with smarter dictionary that learns from word usage and includes contact names as suggestions
•Refreshed browser UI with bookmark thumbnails, double-tap zoom and support for HTML5
•Calendar agenda view enhanced, showing attending status for each invitee, and ability to invite new guests to events
•Optimized hardware speed and revamped UI
•Support for more screen sizes and resolutions, with better contrast ratio
•Improved Google Maps 3.1.2
•MotionEvent class enhanced to track multi-touch events
•Addition of live wallpapers, allowing the animation of home-screen background images to show movement
2.0.1:The Android 2.0.1 SDK was released on 3 December 2009.It was a minor platform release deployable to Android-powered handsets, including minor API changes, bug fixes and framework behavioral changes
2.1:The 2.1 SDK was released on 12 January 2010.It was a minor platform release deployable to Android-powered handsets, including minor amendments to the API and bug fixes.
Froyo:On 20 May 2010, the Android 2.2 (Froyo) SDK was released, based on Linux kernel 2.6.32.Its features included:
•Speed, memory, and performance optimizations
•Additional application speed improvements, implemented through JIT compilation
•Integration of Chrome's V8 JavaScript engine into the Browser application
•Support for the Android Cloud to Device Messaging (C2DM) service, enabling push notifications
•Improved Microsoft Exchange support, including security policies, auto-discovery, GAL look-up, calendar synchronization and remote wipe
•Improved application launcher with shortcuts to Phone and Browser applications
•USB tethering and Wi-Fi hotspot functionality
•Added an option to disable data access over mobile network
•Updated Market application with batch and automatic update features
•Quick switching between multiple keyboard languages and their dictionaries
•Voice dialing and contact sharing over Bluetooth
•Support for Bluetooth-enabled car and desk docks
•Support for numeric and alphanumeric passwords
•Support for file upload fields in the Browser application
•Support for installing applications to the expandable memory
•Adobe Flash support
•Support for extra-high-PPI screens (320 ppi), such as 4" 720p
•Gallery allows users to view picture stacks using a zoom gesture
2.2.1:The Android 2.2.1 update was released on 18 January 2011, and included a number of bug fixes, security updates, and performance improvements.
2.2.2:The Android 2.2.2 update was released on 22 January 2011, and fixed minor bugs, including SMS routing issues that affected the Nexus One.
2.2.3:The Android 2.2.3 update was released on 21 November 2011, and consisted of two security patches.
Gingerbread:On 6 December 2010, the Android 2.3 (Gingerbread) SDK was released, based on Linux kernel 2.6.35.Changes included:
•Updated user interface design with increased simplicity and speed
•Support for extra-large screen sizes and resolutions (WXGA and higher)
•Native support for SIP VoIP internet telephony
•Faster, more intuitive text input in virtual keyboard, with improved accuracy,better suggested text and voice input mode
•Enhanced copy/paste functionality, allowing users to select a word by press-hold, copy, and paste
•Support for Near Field Communication (NFC), allowing the user to read an NFC tag embedded in a poster, sticker, or advertisement
•New audio effects such as reverb, equalization, headphone virtualization, and bass boost
•New Download Manager, giving users easy access to any file downloaded from the browser, email, or another application
•Support for multiple cameras on the device, including a front-facing camera, if available
•Support for WebM/VP8 video playback, and AAC audio encoding
•Improved power management with a more active role in managing apps that are keeping the device awake for too long
•Enhanced support for native code development
•Switched from YAFFS to ext4 on newer devices
•Audio, graphical, and input enhancements for game developers
•Concurrent garbage collection for increased performance
•Native support for more sensors (such as gyroscopes and barometers)
2.2.3:Released on 9 February 2011, Android 2.3.3 included several improvements and API fixes
2.3.4:Version 2.3.4 introduced support for voice or video chat using Google Talk.
2.3.5:Released on 25 July 2011, Android 2.3.5 included a number of system enhancements:
•Improved network performance for the Nexus S 4G, among other fixes and improvements
•Fixed Bluetooth bug on Samsung Galaxy S
•Improved Gmail application
•Shadow animations for list scrolling
•Camera software enhancements
•Improved battery efficiency
2.3.6:Released on 2 September 2011, this version fixed a voice search bug. The 2.3.6 update had the side-effect of impairing the Wi-Fi hotspot functionality of many Canadian Nexus S phones. Google acknowledged this problem and fixed it in late September.
2.3.7:Android 2.3.7 introduced Google Wallet support for the Nexus S 4G.
Honeycomb:On 22 February 2011, the Android 3.0 (Honeycomb) SDK – the first tablet-only Android update – was released, based on Linux kernel 2.6.36.The first device featuring this version, the Motorola Xoom tablet, was released on 24 February 2011.Changes included:
•Optimized tablet support with a new virtual and “holographic” user interface
•Added System Bar, featuring quick access to notifications, status, and soft navigation buttons, available at the bottom of the screen
•Added Action Bar, giving access to contextual options, navigation, widgets, or other types of content at the top of the screen
•Simplified multitasking – tapping Recent Apps in the System Bar allows users to see snapshots of the tasks underway and quickly jump from one app to another
•Redesigned keyboard, making typing fast, efficient and accurate on larger screen sizes
•Simplified, more intuitive copy/paste interface
•Multiple browser tabs replacing browser windows, plus form auto-fill and a new “incognito” mode allowing anonymous browsing
•Quick access to camera exposure, focus, flash, zoom, front-facing camera, time-lapse, and more
•Ability to view albums and other collections in full-screen mode in Gallery, with easy access to thumbnails for other photos
•New two-pane Contacts UI and Fast Scroll to let users easily organize and locate contacts
•New two-pane Email UI to make viewing and organizing messages more efficient, allowing users to select one or more messages
•Support for video chat using Google Talk
•Hardware acceleration
•Support for multi-core processors
•Ability to encrypt all user data
3.1:The 3.1 SDK was released on 10 May 2011.Changes included:
•UI refinements
•Connectivity for USB accessories
•Expanded Recent Apps list
•Resizable Home screen widgets
•Support for external keyboards and pointing devices
•Support for joysticks and gamepads
•Support for FLAC audio playback
•High-performance Wi-Fi lock, maintaining high-performance Wi-Fi connections when device screen is off
•Support for HTTP proxy for each connected Wi-Fi access point
3.2:The 3.2 SDK was released on 15 July 2011,first appearing on Huawei's MediaPad tablet.Changes included:
•Improved hardware support, including optimizations for a wider range of tablets
•Increased ability of apps to access files on the SD card, e.g. for synchronization
•Compatibility display mode for apps that have not been optimized for tablet screen resolutions
•New display support functions, giving developers more control over display appearance on different Android devices
3.2.1:The Android 3.2.1 update was released on 20 September 2011, and included a number of amendments:
•Bug fixes and minor security, stability and Wi-Fi improvements
•Update to Android Market with automatic updates and easier-to-read Terms and Condition text
•Update to Google Books
•Improved Adobe Flash support in browser
•Improved Chinese handwriting prediction
3.2.2:The 3.2.2 update was released on 30 August 2011, and included bug fixes and other minor improvements for the Motorola Xoom 4G.
Ice Cream Sandwhich:Android 4.0 – codenamed Ice Cream Sandwich, and based on Linux kernel 3.0.1– was previewed at the May 2011 Google I/O event,and officially launched at the Galaxy Nexus and Ice Cream Sandwich release event on 19 October 2011.
•Enhanced speed and performance
•Virtual buttons in the UI, in place of capacitive or physical buttons
•Separation of widgets in a new tab, listed in a similar manner to apps
•Easier-to-create folders, with a drag-and-drop style
•A customizable launcher
•Improved visual voicemail with the ability to speed up or slow down voicemail messages
•Pinch-to-zoom functionality in the calendar
•Offline search, a two-line preview, and new action bar at the bottom of the Gmail app
•Ability to swipe left or right to switch between Gmail conversations
•Integrated screenshot capture (accomplished by holding down the Power and Volume-Down buttons)
•Improved error correction on the keyboard
•Ability to access apps directly from lock screen (similar to HTC Sense 3.x)
•Improved copy and paste functionality
•Better voice integration and continuous, real-time speech to text dictation
•Face Unlock, a feature that allows users to unlock handsets using facial recognition software
•New tabbed web browser, allowing up to 16 tabs
•Automatic syncing of browser with users' Chrome bookmarks
•A new typeface family for the UI, Roboto
•Data Usage section in settings that lets users set warnings when they approach a certain usage limit, and disable data use when the limit is exceeded
•Ability to shut down apps that are using data in the background
•Improved camera app with zero shutter lag, time lapse settings, panorama mode, and the ability to zoom while recording
•Built-in photo editor
•New gallery layout, organized by location and person
•Refreshed "People" app with social network integration, status updates and hi-res images
•Android Beam, a near-field communication feature allowing the rapid short-range exchange of web bookmarks, contact info, directions, YouTube videos and other data
•Hardware acceleration of the UI
•Resizeable widgets – already part of Android 3.1 for tablets, but new for cellphones
•Wi-Fi Direct
•1080p video recording for stock Android devices
4.0.2:The Android 4.0.2 update was released on 28 November 2011,and fixed minor bugs on the Verizon Galaxy Nexus,the US launch of which was later delayed until December 2011.
4.0.3:The Android 4.0.3 update was first released on 16 December 2011.It included a number of bug fixes and optimizations, and offered improvements to graphics, databases, spell-checking and Bluetooth functionality,along with new APIs for developers,including a social stream API in the Contacts provider. Other features included Calendar provider enhancements, new camera apps enhancing video stabilization and QVGA resolution, and accessibility refinements such as improved content access for screen readers.
Jelly Bean:The report also mentions some interesting features that originally planned in the presence of ice Cream Sandwich is likely to be postponed and will be displayed on the jelly bean.
Reportedly,this is because these features are not ready until it came time to release the ice cream sandwiches.Google itself has not confirmed anything regarding this information.
Click to expand...
Click to collapse

Different Custom After Market Firmwares.
BeLOW ARE THE DIFFERENT CUSTOM AFTER MARKET FIRMWARES.
MIUI
(pronounced "Me You I", a play on the common abbreviation of the words user interface as UI),developed by Xiaomi Tech, is an aftermarket firmware for cell phones based on the open-source Android operating system. It features a heavily-modified user interface that does away with the Android app drawer and has drawn comparisons with Apple's iOS.It includes additional functionality not found in stock Android, including toggles on the notification pull-down, new music, gallery, and camera apps, and an altered phone dialer that displays matching contacts as a user enters a number.
MIUI is based on Android 2.3.7 and CyanogenMod 7.1 sources, and was initially developed in the Chinese language by Chinese startup Xiaomi.Xiaomi added a number of apps to enhance the basic framework; those include MITalk (a Blackberry Messenger clone),MINotes,MIBackup,MIMusic,and MIGallery.MIUI is made up of two parts, MI and UI, where UI stands for User Interface and MI, as stated by Xiaomi CEO Lei Jun, stands for Mobile Internet and Mission Impossible.
The modified operating system has been criticized for being similar to iOS.Due to the fact that MIUI is developed in China, some features that are not relevant to the Chinese market, such as WiMax support, are unavailable on MIUI, and without access to the source code, it is not possible for 3rd parties to easily add this support.
AOSP
The Android Open Source Project (AOSP) is led by Google, and is tasked with the maintenance and development of Android.According to the project "The goal of the Android Open Source Project is to create a successful real-world product that improves the mobile experience for end users."AOSP also maintains the Android Compatibility Program, defining an "Android compatible" device "as one that can run any application written by third-party developers using the Android SDK and NDK", to prevent incompatible Android implementations.The compatibility program is also optional and free of charge, with the Compatibility Test Suite also free and open-source.
CYANOGENMOD
CyanogenMod is an open source replacement firmware based on the Android mobile operating system for smart phones and tablet computers. It offers features and options not found in the official firmware distributed by vendors of these devices.
Features supported by CyanogenMod include native theming support (also called the "T-Mobile Theme Engine"), Free Lossless Audio Codec (FLAC) support, a large Access Point Name list, an OpenVPN client, a reboot menu, support for Wi-Fi, Bluetooth, and USB tethering, CPU overclocking and performance enhancements, soft buttons and other "tablet tweaks", toggles in the notification pull-down (such as Wi-Fi, Bluetooth and GPS), app permissions management, as well as other interface enhancements. CyanogenMod is also stated to increase performance and reliability compared with official firmware releases.
CyanogenMod is developed as free and open source software based on the official releases of Android by Google, with added original and third-party code.
Click to expand...
Click to collapse

Thank You. Now I know what CAF means.

Android_Sheriff said:
Thank You. Now I know what CAF means.
Click to expand...
Click to collapse
code aurora forum
http://forum.xda-developers.com/sitesearch.php?q=code aurora forum

Thanks!
Now, I know what is "kanging" means, this thread is very useful...

Related

Sprint Launches Open Software Platform

FYI
http://biz.yahoo.com/bw/081209/20081209005354.html?.v=1
Sprint Launches Open Software Platform at Eighth Annual Application Developer Conference to Help Millions More Developers Create Products for Sprint Customers
The Sprint platform is an open, standards-based mobile Java ecosystem that extends desktop computing and Web 2.0 capabilities to devices operating on the Sprint Mobile Broadband Network. To get started, developers can access the full suite of Sprint Titan development resources at http://developer.sprint.com. It is the first of several open software platforms that Sprint will make available to developers.
The platform supports existing MIDP Java ME applications and adds the more capable CDC/Foundation Java Virtual Machine and OSGi framework for new high-capability applications. Support for the Eclipse embedded Rich Client (eRCP) application model means the platform can run generically written rich GUI applications across a broad range of devices and desktop computers. Support for the Widget application model provides Web developers the ability to develop rich Web applications that take full advantage of the device’s functionality. This allows developers to easily move Eclipse-based or Web applications from the desktop to Sprint devices. The platform also includes APIs to give developers access to Sprint-specific device features, such as location, messaging and multimedia, which can be useful in a variety of business- and consumer-oriented applications, such as field service or unified messaging.
As part of today’s launch, the platform is available with its own set of developer tools that plug in to Eclipse IDE and support both mobile and non-mobile application development and deployment. The toolset leverages existing server or desktop frameworks and provides on-device debugging and profiling, along with device emulation.
For enterprise customers, the open platform leverages the same JAVA application development framework that many customers already use for desktops and servers. This means applications can be easily extended to Sprint wireless devices with little resource training or additional investment beyond what is already in place today. In addition to extending enterprise applications to the mobile environment, the platform enables device management functionality so account administrators can remotely manage their devices and applications.
I hope I get to see more great apps on my Mogul!
Did you see this in the release notes?
"When installed, Sprint Titan uses roughly 10 MB of Program memory on your device. An additional 4MB may be required for the MIDP stack which is started when it is used for the first time. Using a lot of applications on top of both stacks may lead to vastly more required Program memory as the applications load resources. It is hard to determine the memory used by one single application since it can use a wide variety of available APIs and resources. You may experience low memory availability using Titan along
with other Windows Mobile applications on devices with less or equal to 48 MB of program memory (almost half of which is already used by the Windows Mobile OS and its standard services at device startup)."
No way I'm installing it.
I don't see why someone wouldn't just develop native win32 apps for windows mobile devices. Can't we already run java apps with jeodek?

Android insights: HW Acceleration, performance, Lags

Hi @all,
yesterday i posted a nice article about how HW Acceleration is done since honeycomb (and the difference before).
I think its a good idea to post here nice and interesting articles - this can help the devs here but the users to why
sometimes its simply impossible to code things or fix things.
Please dont spam this thread, even its in general section - let users read interesting things instead of pages full of ****
"The Reason Android is Laggy"
Dianne starts off her post with a surprising revelation:
“Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering.
This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no
trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen.”
Hun? How can this be the case? Anybody who’s used a Nexus S knows it slows down in all but the simplest of ListViews.
And forget any semblance of decent performance if a background task is occurring, like installing an app or updating the
UI from disk. On the other hand, iOS is 100% smooth even when installing apps. But we know Dianne isn’t lying about the
potential CPU performance, so what’s going on?
The Root Cause
It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering
occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering
occurring on the main thread with normal priority.
This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari.
Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around.
All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is
intercepting all events and rendering the UI at real-time priority.
If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML,
and do an ‘ok’ job at both. On Android, this a case where an efficient dual core processor really helps, which is why the Galaxy
S II is famous for its smoothness.
On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until
all rendering is finished. Android tries to do both at the same priority, so the frame rate suffers. Once you notice this happening,
you’ll see it everywhere on an Android phone. Why is scrolling in the Movies app slow? Because movie cover thumbnails are
dynamically added to the movie list as you scroll down, while on iOS they are lazily added after all scrolling stops.
Other Reasons
The fundamental reason Android is laggy is UI rendering threading and priority, but it’s not the only reason. First, hardware
acceleration, despite Dianna’s reservations, does help. My Nexus S has never been snappier since upgrading to ICS. Hardware
acceleration makes a huge difference in apps like the home screen and Android market. Offloading rendering to the GPU also
increases battery life, because GPUs are fixed-function hardware, so they operate at a lower power envelope.
Second, contrary to what I claimed earlier, garbage collection is still a problem, even with the work on concurrent GC in Dalvik.
For example, if you’ve ever used the photo gallery app in Honeycomb or ICS you may wonder why the frame rate is low. It turns
out the frame rate is capped at 30 FPS because without the cap, swiping through photos proceeds at 60 FPS most of the time,
but occasionally a GC pause causes a noticeable “hiccup”. Capping the frame rate at 30 fixes the hiccup problem at the expense
of buttery smooth animations at all times.
Third, there are the hardware problems that Dianne discussed. The Tegra 2, despite Nvidia’s grandiose marketing claims, is hurt
by low memory bandwidth and no NEON instruction set support (NEON instructions are the ARM equivalent of Intel’s SSE, which
allow for faster matrix math on CPUs). Honeycomb tablets would be better off with a different GPU, even if it was theoretically
less powerful in some respects than the Tegra 2. For example, the Samsung Hummingbird in the Nexus S or Apple A4. It’s telling
that the fastest released Honeycomb tablet, the Galaxy Tab 7.7, is running the Exynos CPU from the Galaxy S II.
Fourth, Android has a ways to go toward more efficient UI compositing. On iOS, each UI view is rendered separately and stored
in memory, so many animations only require the GPU to recomposite UI views. GPUs are extremely good at this. Unfortunately, on
Android, the UI hierarchy is flattened before rendering, so animations require every animating section of the screen to be redrawn.
Fifth, the Dalvik VM is not as mature as a desktop class JVM. Java is notorious for terrible GUI performance on desktop. However,
many of the issues don’t carry over to the Dalvik implementation. Swing was terrible because it was a cross platform layer on top
of native APIs. It is interesting to note that Windows Phone 7’s core UI is built in native code, even though the original plan was to
base it entirely on Silverlight. Microsoft ultimately decided that to get the kind of UI performance required, the code would have to
be native. It’s easy to see the difference between native and bytecode on Windows Phone 7, because third party apps are written
in Silverlight and have inferior performance (NoDo and Mango have alleviated this problem and the Silverlight UIs are generally very
smooth now).
Thankfully, each of the five issues listed above is solvable without radical changes to Android. Hardware acceleration will be on all
Android phones running ICS, Dalvik continues to improve GC efficiency, the Tegra 2 is finally obsolete, there are existing workarounds
for the UI compositing problems, and Dalvik becomes a faster VM with every release. I recently asked +Jason Kincaid of +TechCrunch
if his Galaxy Nexus was smooth, and he had this to say:
“In general I've found ICS on the Galaxy Nexus to be quite smooth. There are occasional stutters — the one place where I can
consistently get jitters on the Galaxy Nexus is when I hit the multitasking button, where it often will pause for a quarter second.
That said, I find that the iPhone 4S also jitters more than I had expected, especially when I go to access the systemwide search
(where you swipe left from the home screen).”
So there you go, the Android lag problem is mostly solved, right? Not so fast.
Going Forward
Android UI will never be completely smooth because of the design constraints I discussed at the beginning:
- UI rendering occurs on the main thread of an app
- UI rendering has normal priority
Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these
two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year
old iPhone. So why did the Android team design the rendering framework like this?
Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry.
The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device.
When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI
framework.
This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they
were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and
started from scratch. Android is the only mobile OS left that existed pre-iPhone.
So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:
“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the
biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing,
possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to
this also.”
Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:
- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed
However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely
unacceptable. It should be priority #1 for the Android team.
When the topic of Android comes up with both technical and nontechnical friends, I hear over and over that Android is laggy and slow.
The reality is that Android can open apps and render web pages as fast or faster than iOS, but perception is everything. Fixing the UI lag
will go a long way to repairing Android’s image.
Beyond the perception issue, lag is a violation of one of Google’s core philosophies. Google believes that things should be fast. That’s a driving
philosophy behind Google Search, Gmail, and Chrome. It’s why Google created SPDY to improve on HTTP. It’s why Google builds tools to help
websites optimize their site. It’s why Google runs it’s own CDN. It’s why Google Maps is rendered in WebGL. It’s why buffering on Youtube is
something most of us remember, but rarely see anymore.
But perhaps the most salient reason why UI lag in Android is unacceptable comes from the field of Human-Computer Interaction (HCI). Modern
touch screens imply an affordance language of 1 to 1 mapping between your finger and animations on the screen. This is why the iOS over-scroll
(elastic band) effect is so cool, fun, and intuitive. And this is why the touch screens on Virgin America Flights are so frustrating: they are incredibly
laggy, unresponsive, and imprecise.
A laggy UI breaks the core affordance language of a touch screen. The device no longer feels natural. It loses the magic. The user is pulled out of
their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get “lost” in an iPad, but I cringe when a
Xoom stutters between home screens. The 200 million users of Android deserve better.
And I know they will have it eventually. The Android team is one of the most dedicated and talented development teams in the world. With stars like
+Dianne Hackborn and +Romain Guy around, the Android rendering framework is in good hands.
I hope this post has reduced confusion surrounding Android lag. With some luck, Android 5.0 will bring the buttery-smooth Android we’ve all dreamed
about since we first held an HTC G1. In the mean time, I’ll be in Redmond working my butt off trying to get a beautiful and smooth mobile OS some
of the recognition it deserves.
Click to expand...
Click to collapse
How do Android Apps work- Java, its compilation and role of DalvikVM
OK, here goes mine..
was researching around about the role of java in android and I found this piece of info..
it explains the way android apps work and stuff..
Visit here for the full article..
What is Java?
Android applications are developed using the Java language. As of now, that’s really your only option for native applications. Java is a very popular programming language developed by Sun Microsystems (now owned by Oracle). Developed long after C and C++, Java incorporates many of the powerful features of those powerful languages while addressing some of their drawbacks. Still, programming languages are only as powerful as their libraries. These libraries exist to help developers build applications.
Some of the Java’s important core features are:
It’s easy to learn and understand
It’s designed to be platform-independent and secure, using
virtual machines
It’s object-oriented
Android relies heavily on these Java fundamentals. The Android SDK includes many standard Java libraries (data structure libraries, math libraries, graphics libraries, networking libraries and everything else you could want) as well as special Android libraries that will help you develop awesome Android applications.
Why is Platform Independence Important?
With many programming languages, you need to use a compiler to reduce your code down into machine language that the device can understand. While this is well and good, different devices use different machine languages. This means that you might need to compile your applications for each different device or machine language—in other words, your code isn’t very portable. This is not the case with Java. The Java compilers convert your code from human readable Java source files to something called “bytecode” in the Java world. These are interpreted by a Java Virtual Machine, which operates much like a physical CPU might operate on machine code, to actually execute the compiled code. Although it might seem like this is inefficient, much effort has been put into making this process very fast and efficient. These efforts have paid off in that Java performance in generally second only to C/C++ in common language performance comparisons.
Android applications run in a special virtual machine called the Dalvik VM. While the details of this VM are unimportant to the average developer, it can be helpful to think of the Dalvik VM as a bubble in which your Android application runs, allowing you to not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the latest toaster running Android. You don’t care so long as the device is Dalvik VM friendly—and that’s the device manufacturer’s job to implement, not yours.
Why is Java Secure?
Let’s take this bubble idea a bit further. Because Java applications run within the bubble that is a virtual machine, they are isolated from the underlying device hardware. Therefore, a virtual machine can encapsulate, contain, and manage code execution in a safe manner compared to languages that operate in machine code directly. The Android platform takes things a step further. Each Android application runs on the (Linux-based) operating system using a different user account and in its own instance of the Dalvik VM. Android applications are closely monitored by the operating system and shut down if they don’t play nice (e.g. use too much processing power, become unresponsive, waste resources, etc.). Therefore, it’s important to develop applications that are stable and responsive. Applications can communicate with one another using well-defined protocols.
Compiling Your Code
Like many languages, Java is still a compiled language even though it doesn’t compile all the way down to machine code. This means you, the developer, need to compile your Android projects and package them up to deploy onto devices. The Eclipse development environment (used with the Android Development plug-in) makes this pretty painless. In Eclipse, automatic compilation is often turned on by default. This means that every time you save a project file, Eclipse recompiles the changes for your application package. You immediately see compile errors. Eclipse also interprets Java as you type, providing handy code coloring and formatting as well as showing many types of errors as you go. Often, you can click on the error and have Eclipse automatically fix a typo, or add an import statement, or provide a method stub for you, saving lots of typing.
You can still manually compile your code if you so desire. Within Eclipse, you’ll find the Build settings under the project menu. If you have “Build Automatically” turned on, you can still choose the “Clean…” option that will allow you to do full rebuild of all files. If “Build Automatically” is turned off, “Build All” and “Build Project” menu options are enabled. “Build All” means to build all of the projects in the workspace. You can have many projects in an Eclipse workspace.
The build process, for regular Java projects, results in a file with the extension of JAR – Java ARchive. Android applications take JAR files and package them for deployment on devices as Android PacKage files with an extension .apk. These formats not only include your compiled Java code, but also any other resources, such as strings, images, or sound files, that your application requires to run as well as the Application Manifest file, AndroidManifest.xml. The Android Manifest file is a file required by all Android applications, which you use to define configuration details about your app.
Click to expand...
Click to collapse
And here goes another article, by an Ex-Intern Andrew Munn who worked on the android project..
i just post the link here, its a huge article...
Follow up to “Android graphics true facts”, or The Reason Android is Laggy
Click to expand...
Click to collapse
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
D3oDex3D_Ayush717 said:
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
Click to expand...
Click to collapse
exactly ! android is 100 times better and powerfull than ios ! if in an iphone ui rendering didnt happen didicatedly, it would be 100 times more laggy than android. one other thing that shows that ios does concentrate completly on ui when scrolling- swipe left right through homscreens in speed (even with all apps closed) - ull see that the dots below which indicate which screen ur on , doesnt change at all untill uve stopped scrolling and then it moves directly to the current screen indicator!
---------- Post added at 03:16 PM ---------- Previous post was at 03:09 PM ----------
btw this here is a contradicting article to what andy you posted ! here ! :
Dianne Hackborn - 00:38 (edited) - Public
A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints about how Android works.
These new topics have been more about some fundamental design decisions in Android, and why they are wrong. I’d like to help people better understand (and judge) these discussions by giving some real background on why Android’s UI was designed the way it is and how it actually works.
One issue that has been raised is that Android doesn’t use thread priorities to reduce how much background work interrupts the user interface. This is outright wrong. It actually uses a number of priorities, which you can even find defined right here http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_AUDIO in the SDK.
The most important of these are the background and default priorities. User interface threads normally run at the default priority; background threads run in the background priority. Application processes that are in the background have all of their threads forced to the background priority.
Android’s background priority is actually pretty interesting. It uses a Linux facility called cgroups to put all background threads into a special scheduling group which, all together, can’t use more than 10% of the CPU. That is, if you have 10 processes in the background all trying to run at the same time, when combined they can't take away more than 10% of the time needed by foreground threads. This is enough to allow background threads to make some forward progress, without having enough of an impact on the foreground threads to be generally visible to the user.
(You may have noticed that a “foreground” priority is also defined. This is not used in current Android; it was in the original implementation, but we found that the Linux scheduler does not give enough preference to threads based on pure priority, so switched to cgroups in Android 1.6.)
I have also seen a number of claims that the basic Android design is fundamentally flawed and archaic because it doesn’t use a rendering thread like iOS. There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave.
Android had a number of very different original design goals than iOS did. A key goal of Android was to provide an open application platform, using application sandboxes to create a much more secure environment that doesn’t rely on a central authority to verify that applications do what they claim. To achieve this, it uses Linux process isolation and user IDs to prevent each application from being able to access the system or other application in ways that are not controlled and secure.
This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.
An important part of achieving this security is having a way for (EDIT: It has been pointed out to me that iOS does in fact use multiple windows and multiple GL contexts. Lesson to me, just don't talk about anything I haven't directly verified. That still doesn't change things for Android, though, where as I mention later we simply did not have hardware and drivers that could do multiple GL contexts until fairly recently.)
individual UI elements to share the screen in a secure way. This is why there are windows on Android. The status bar and its notification shade are windows owned and drawn by the system. These are separate from the application’s window, so the application can not touch anything about the status bar, such as to scrape the text of SMS messages as they are displayed there. Likewise the soft keyboard is a separate window, owned by a separate application, and it and the application can only interact with each other through a well defined and controlled interface. (This is also why Android can safely support third party input methods.)
Another objective of Android was to allow close collaboration between applications, so that for example it is easy to implement a share API that launches a part of another application integrated with the original application’s flow. As part of this, Android applications traditionally are split into pieces (called “Activities”) that handle a single specific part of the UI of the application. For example, the contacts lists is one activity, the details of a contact is another, and editing a contact is a third. Moving between those parts of the contacts UI means switching between these activities, and each of these activities is its own separate window.
Now we can see something interesting: in almost all of the places in the original Android UI where you see animations, you are actually seeing windows animate. Launching Contacts is an animation of the home screen window and the contacts list window. Tapping on a contact to see its details is an animation of the contacts list window and the contacts details window. Displaying the soft keyboard is an animation of the keyboard window. Showing the dialog where you pick an app to share with is an animation of a window displaying that dialog.
When you see a window on screen, what you are seeing is actually something called a “surface”. This is a separate piece of shared memory that the window draws its UI in, and is composited with the other windows to the screen by a separate system service (in a separate thread, running at a higher than normal priority) called the “surface flinger.” Does this sound familiar? In fact this is very much like what iOS is doing with its views being composited by a separate thread, just at a less fine-grained but significantly more secure level. (And this window composition has been hardware accelerated in Android from the beginning.)
The other main interesting interaction in the UI is tracking your finger -- scrolling and flinging a list, swiping a gallery, etc. These interactions involve updating the contents inside of a window, so require re-rendering that window for each movement. However, being able to do this rendering off the main thread probably doesn’t gain you much. These are not simple “move this part of the UI from X to Y, and maybe tell me when you are done” animations -- each movement is based on events received about the finger on the screen, which need to be processed by the application on its main thread.
That said, being able to avoid redrawing all of the contents of the parts of the UI that are moving can help performance. And this is also a technique that Android has employed since before 1.0; UI elements like a ListView that want to scroll their content can call http://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean) to have that content rendered into a cache so that only the bitmap needs to be drawn as it moves.
Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger. This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.
So, all those things considered, in Android 1.0 having each view drawn into a texture and those textures composited to the window in another thread is just not that much of a gain, with a lot of cost. The cost is also in engineering time -- our time was better spent working on other things like a layout-based view hierarchy (to provide flexibility in adjusting for different screen sizes) and “remote views” for notifications and widgets, which have significantly benefited the platform as it develops.
In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.
I hope this helps people better understand how Android works. And just to be clear again from my last point -- I am not writing this to make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic.
There are of course many things that can be improved in Android today, just as there are many things that have been improved since 1.0. As other more pressing issues are addressed, and hardware capabilities improve and change, we continue to push the platform forward and make it better.
One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists: “Getting it up to sixty is more difficult—you may have to simplify the cell's view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews out of the cell altogether and draw everything by hand.”
I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS.
D3oDex3D_Ayush717 said:
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
Click to expand...
Click to collapse
Ehhhh I still think 3GS is better than optimus one
That's a lot of bull**** in even more words...
Kidding
But I don't understand anything of it, I'll leave it to the real devs (A)
Luck dev'ing
ok, here some basic informations on how long it take and why before a developer can
release a complete OS:
http://developer.sonyericsson.com/w...from-source-code-release-to-software-upgrade/
About Accelerated Android Rendering:
It's pretty interesting although these guys aren't talking about Ice Cream Sandwich (they're talking about Honeycomb that introduced hardware accelerated 2D rendering)
http://www.youtube.com/watch?v=v9S5EO7CLjo
I could be way off base here, but is there anything useful that could be extracted from qualcomm's adreno sdk?
https://developer.qualcomm.com/
terratrix said:
Ehhhh I still think 3GS is better than optimus one
Click to expand...
Click to collapse
I am not comparing 3Gs and O1, am talking abt. difference between AndroidOS and iOS............
Sent from my LG Optimus One P500 using XDA App
This week, google started a nice topic on the android developer page "Best practices to develop android applications".
Reading some articles is recommended for developers who want to save some battery and/or network traffic, want to spped
up listviews, save ram and other good things:
look here:
Improving Layout Performance
Optimizing Battery Life
Sharing content between applications
i hope, this can someone help to understand what we can do to make things nice.

[ Q ] why does Google release updates every year? ?

*Moderator(s) I m sorry if this doesn't belong to this section ..please move it if u want ( and inform me please)
Guys I was just wondering why Google releases updates every year ...it doesn't bring any notable new features sometimes ( like froyo to gb = nothing new) sometimes some phones take a whole year to get the update and in the meantime a new update is announced
And then we have our manufacturers who refuse to update our phones( if u r looking at my signature and want to tell me that I should buy a high end phone lets talk about what happened to SGS 1 first ) and make the whole update sick
I think Google should convince the manufacturers to update all devices and Google itself should annonce less updates( less quality updates >>>> more quantity updates)
Or can someone explain Google 's strategy to me???? It sure doesn't make sense to me
Kind of agree with what you have to say.
In my opinion many people have low end devices, which don't really get the latest os updates anyway, thanks to the phone manufacturers. So you'll have a large chunk of the user base using the older versions. Which in turn results in a large amount of applications targeting the older versions too.
The_R said:
Kind of agree with what you have to say.
In my opinion many people have low end devices, which don't really get the latest os updates anyway, thanks to the phone manufacturers. So you'll have a large chunk of the user base using the older versions. Which in turn results in a large amount of applications targeting the older versions too.
Click to expand...
Click to collapse
+1 ...I just can't see why Google makes the fuss about updates ??? I mean "update " by its very definition means improving I.e. older phones getting newer os but android phones hardly get more than 2 updates! !!! Even if the hardware supports the new software! !!!
What do you mean no changes between Froyo and GB? From Wikipedia here are some:
v2.3
On 6 December 2010, the Android 2.3 (Gingerbread) SDK was released, based on Linux kernel 2.6.35. Changes included:
Updated user interface design with increased simplicity and speed
Support for extra-large screen sizes and resolutions (WXGA and higher)
Native support for SIP VoIP internet telephony
Faster, more intuitive text input in virtual keyboard, with improved accuracy, better suggested text and voice input mode
Enhanced copy/paste functionality, allowing users to select a word by press-hold, copy, and paste
Support for Near Field Communication (NFC), allowing the user to read an NFC tag embedded in a poster, sticker, or advertisement
New audio effects such as reverb, equalization, headphone virtualization, and bass boost
New Download Manager, giving users easy access to any file downloaded from the browser, email, or another application
Support for multiple cameras on the device, including a front-facing camera, if available
Support for WebM/VP8 video playback, and AAC audio encoding
Improved power management with a more active role in managing apps that are keeping the device awake for too long
Enhanced support for native code development
Switched from YAFFS to ext4 on newer devices
Audio, graphical, and input enhancements for game developers
Concurrent garbage collection for increased performance
Native support for more sensors (such as gyroscopes and barometers)
Click to expand...
Click to collapse
A lot of it is new hardware support to keep up with technology. The new audio effects it talks about make it possible for system wide EQ apps without root like Equalizer, before GB IIRC this was not possible. They've also made multitasking better so that task killers shouldn't be needed.
Their update strategy is to debut the new OS on a Nexus device and then release the source so others can use it. Personally I would like to see Google let developers in earlier in development so they can get drivers and upgrades done quicker. This is how Microsoft does things and is why OEMs can have the new OS ready on hardware on its debut day. But Google's strategy is quite a bit different.
spunker88 said:
What do you mean no changes between Froyo and GB? From Wikipedia here are some:
A lot of it is new hardware support to keep up with technology. The new audio effects it talks about make it possible for system wide EQ apps without root like Equalizer, before GB IIRC this was not possible. They've also made multitasking better so that task killers shouldn't be needed.
Their update strategy is to debut the new OS on a Nexus device and then release the source so others can use it. Personally I would like to see Google let developers in earlier in development so they can get drivers and upgrades done quicker. This is how Microsoft does things and is why OEMs can have the new OS ready on hardware on its debut day. But Google's strategy is quite a bit different.
Click to expand...
Click to collapse
Even I was thinking about your last point u know, when the update gets announced it should be released simultaneously ......waiting a whole year ( or 5-6months) sucks
That's why there's great community(s) like xda forums and projects like cyanogenmod. Linux is open. Android is based on Linux. Android isn't AS opem.
The developers are here to help remedy some of that.

[Q] Context Simulation: Decision Help

Hello together,
I`m writing currently my master thesis with the topic "Context Simulator For Mobile Business Application". The goal is, to test how an Android application reacts during changing context conditions: How reacts an application, if the battery is almost empty? How reacts an application, if internet connection breaks down during data transmission? How reacts an application, if a SD-Card is available/not available? ...
I want to simulate all of these factors on the PC and send the data to my android device. Some more examples:
- Simulating sensor data for accelerometer, gyroscope, ...
- GPS
- Camera and microphone (if an application requests a camera image, it should receive a image from my simulator)
- Fake connection for Wi-Fi, HDSPA, EDGE
- Fake time, time zone and date
- Simulate a specific battery level
- Fake calendar entries
------------------ My approaches ------------------
No 1:
Extend an existing custom rom with my features => Some calls should not transfer to OS (example: GPS) but to my simulator on PC. Also send data (example: battery level) to android OS. For example to pretend a low battery level.
No 2:
Write my own sandbox application (I haven`t found information to this topic so far). In this sandbox application, I`m going to start my application to test. So it is possible, to fetch all request from this System under test and I can decide if I want to transfer them to Android OS or to my simulator.
No 3:
Develop my own library, which will be included from my system under test. This library extends some android classes (e.g. Activity, Location Manager, Sensor Manager). My extensions classes will transmit the request to my simulator instead to the OS.
I`m afraid, I only have limited functionalities when I`m using this approach.
No 4:
Take sensor simulator from open intents as basic and extend it as good as possible.
-------- About Me --------
I only have few experience in Android development, but a lot experience in Java development. I know, I should read now a lot about custom roms, ... Unfortunately this thesis should be finish at the end of march.
------- What I want from you -------
Advice. I hope you understand my problem. Which is the best way to realize this project? I would like to have as much functionalities as possible. My prototype doesn`t need to support all context factors, but I should consider all factors in my system design.
I wanted to attached two graphics, but unfortunately I`m not allowed to. These are two possibilities and I`m not sure, which one is better (and also, if they are possible):
http ://s7.directupload.net/images/131212/bnpuo8gh.png
http ://s7.directupload.net/images/131212/e7u8dv4r.png
Thanks a lot,
Michael

Request for paid work on sources code modification of current AOSP /M200

We are a company based in France and we provide sources code for its modifications to allow us having open platform for smart glasses to behaves as a standalone platform to allow customers using their own application and to push Google Play app on the menu
Detail description of the problem:
We have an embedded android system 4.3 applied for android glasses, with a solution of Ingenic M200.
The system works with all camera, sensors and display
However, the system is limited. It is modified for the wearable devices (Camera glasses), using cards UI, scroll or click control uniquely by a touch pad, menu uncompleted
It disconnects automatically when we install an application, even we can push the apk by ‘adb push’ it doesn’t support well because of lack of gesture of touch, card input instead of a keyboard standard.
The menu and setting are not completed, only have configuration of wifi,Bluetooth and Gps. We need to have access to all setting features. This Menu is an application and need to be standard as any platform of phone or tablet
We would like to find a cooperative help us to modify it. We have in hands the sources code that we’ll provide for modification.
Please contact us at the following email. Our request is urgent:
Email: [email protected]

Categories

Resources