The Complete Guide For Galaxy 3 i5800/i5801
Index:
1) Android Basics
2) Galaxy 3 Features
3) Hardware
4) ROM Basics, Tutorials
5) Kernel Basics
6) Tools/Imp Download Links
7) Complete List of ROMs,Kernels for G3
8) FAQ
9) EPIC Fail Ideas for G3
Android Basics
1) Android Basics
Introduction:
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. Google Inc. purchased the initial developer of the software, Android Inc., in 2005. Android's mobile operating system is based on the Linux kernel. Google and other members of the Open Handset Alliance collaborated on Android's development and release. The Android Open Source Project (AOSP) is tasked with the maintenance and further development of Android. The Android operating system is currently the world's best-selling Smartphone platform.
Android has a large community of developers writing applications ("apps") that extend the functionality of the devices. There are currently over 200,000 apps available for Android. Android Market is the online app store run by Google, though apps can also be downloaded from third-party sites. Developers write primarily in the Java language, controlling the device via Google-developed Java libraries.
The unveiling of the Android distribution on 5 November 2007 was announced with the founding of the Open Handset Alliance, a consortium of 80 hardware, software, and telecom companies devoted to advancing open standards for mobile devices. Google released most of the Android code under the Apache License, a free software and open source license.
The Android open-source software stack consists of Java applications running on a Java-based, object-oriented application framework on top of Java core libraries running on a Dalvik virtual machine featuring JIT compilation. Libraries written in C include the surface manager, OpenCore media framework, SQLite relational database management system, OpenGL ES 2.0 3D graphics API, WebKit layout engine, SGL graphics engine, SSL, and Bionic libc. The Android operating system, including the Linux kernel, consists of roughly 12 million lines of code including 3 million lines of XML, 2.8 million lines of C, 2.1 million lines of Java, and 1.75 million lines of C++.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Version history
2.1 Eclair
Changelog:
Sync: Expanded Account sync. Multiple accounts can be added to a device for email and contact synchronization
Email: Exchange support, Combined inbox to browse email from multiple accounts in one page.
Bluetooth: 2.1 support
Contacts: Tap a contact photo and select to call, SMS, or email the person.
Messaging: Search all saved SMS and MMS messages. Auto delete oldest messages in a conversation when a defined limit is reached.
Camera: Flash support, Digital zoom, Scene mode, White balance, Color effect, Macro focus
Virtual keyboard: Improved typing speed, smarter dictionary learns from word usage and includes contact names as suggestions.
Browser: Refreshed UI, Bookmark thumbnails, Double-tap zoom, Support for HTML5
Calendar: Agenda view enhanced, Attending status for each invitee, Invite new guests to events.
System: Optimized hardware speed, Revamped UI
Display: Support for more screen sizes and resolutions, Better contrast ratio
Maps: Improved Google Maps 3.1.2
MotionEvent class enhanced to track multi-touch events
Live Wallpapers: Home screen background images can be animated to show movement
2.2 Froyo
Changelog:
System: Speed, memory, and performance optimizations
Additional application speed improvements courtesy of JIT implementation
Integration of Chrome's V8 JavaScript engine into the Browser application
Improved Microsoft Exchange support (security policies, auto-discovery, GAL look-up, calendar synchronization, 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 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 DPI screens (320 dpi), such as 4" 720p
2.3 Gingerbread
Changelog:
System: Updated user interface design for simplicity and speed
Display: Support for extra-large screen sizes and resolutions (WXGA and higher)
Internet calling: Native support for SIP VoIP telephony
Virtual Keyboard: Faster, more intuitive text input, improved accuracy, better suggested text. Voice input mode
Copy/Paste: Enhanced. Select a word by press-hold, copy, and paste.
Near Field Communication lets the user read an NFC tag embedded in a poster, sticker, or advertisement.
New audio effects such as reverb, equalization, headphone virtualization, and bass boost
System: Improved power management with a more active role in managing apps that are keeping the device awake for too long.
Download Manager gives the user easy access to any file downloaded from the browser, email, or another application.
Camera: Access multiple cameras on the device, including a front-facing camera, if available.
Media: Support for WebM/VP8 video playback, and AAC audio encoding
System: Enhanced support for native code development
Audio, graphical, and input enhancements for game developers
Concurrent garbage collection for increased performance
Native support for more sensors (such as gyroscopes and barometers)
Switched from YAFFS to ext4 on newer devices
Android Architecture
FEATURES OF ANDROID
Handset layouts The platform is adaptable to larger, VGA, 2D graphics library, 3D graphics library based on OpenGL ES 2.0 specifications, and traditional smartphone layouts.
Storage SQLite, a lightweight relational database, is used for data storage purposes
Connectivity Android supports connectivity technologies including GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi (no connections through Proxy server and no Ad hoc wireless network), LTE, NFC and WiMAX.
Messaging SMS and MMS are available forms of messaging, including threaded text messaging and now Android Cloud To Device Messaging Framework(C2DM) is also a part of Android Push Messaging service.
Multiple Language Support Multiple languages are available on Android. The number of languages more than doubled for the platform 2.3 Gingerbread. Android lacks font rendering of several languages even after official announcements[citation needed] of added support (e.g. Hindi).
Web browser The web browser available in Android is based on the open-source WebKit layout engine, coupled with Chrome's V8 JavaScript engine. The browser scores a 93/100 on the Acid3 Test.
Java support While most Android applications are written in Java, there is no Java Virtual Machine in the platform and Java byte code is not executed. Java classes are compiled into Dalvik executables and run on the Dalvik virtual machine. Dalvik is a specialized virtual machine designed specifically for Android and optimized for battery-powered mobile devices with limited memory and CPU. J2ME support can be provided via third-party applications.
Media support Android supports the following audio/video/still media formats: WebM, H.263, H.264 (in 3GP or MP4 container), MPEG-4 SP, AMR, AMR-WB (in 3GP container), AAC, HE-AAC (in MP4 or 3GP container), MP3, MIDI, Ogg Vorbis, FLAC, WAV, JPEG, PNG, GIF (though earlier versions do not support animated GIFs, BMP.
Streaming media support RTP/RTSP streaming (3GPP PSS, ISMA), HTML progressive download (HTML5 <video> tag). Adobe Flash Streaming (RTMP) and HTTP Dynamic Streaming are supported by the Flash plugin. Apple HTTP Live Streaming is supported by RealPlayer for Mobile, and by the operating system in Android 3.0 (Honeycomb). Microsoft Smooth Streaming is planned to be supported through the awaited port of Silverlight plugin to Android.
Additional hardware support Android can use video/still cameras, touchscreens, GPS, accelerometers, gyroscopes, magnetometers, dedicated gaming controls, proximity and pressure sensors, thermometers, accelerated 2D bit blits (with hardware orientation, scaling, pixel format conversion) and accelerated 3D graphics.
Multi-touch Android has native support for multi-touch which was initially made available in handsets such as the HTC Hero. The feature was originally disabled at the kernel level (possibly to avoid infringing Apple's patents on touch-screen technology at the time). Google has since released an update for the Nexus One and the Motorola Droid which enables multi-touch natively.
Bluetooth Supports A2DP, AVRCP, sending files (OPP), accessing the phone book (PBAP), voice dialing and sending contacts between phones. Keyboard, mouse and joystick (HID) support is available through manufacturer customizations and third-party applications. Full HID support is planned for Android 3.0 (Honeycomb).
Video calling Android does not provide native video calling support, but some handsets have a customized version of the operating system that support it, either via the UMTS network (like the Samsung Galaxy S) or over IP. Video calling through Google Talk is available in Android 2.3.4 and later.
Multitasking Multitasking of applications is available.
Voice based features Google search through voice has been available since initial release. Voice actions for calling, texting, navigation, etc. are supported on Android 2.2 onwards.
Tethering Android supports tethering, which allows a phone to be used as a wireless/wired hotspot. Prior to Android 2.2 this was supported by third-party applications or manufacturer customizations.
Screen Capture Android does not currently support screenshot capture. This is supported by manufacturer and third-party customizations.
2) Galaxy 3 Features
General
2G Network GSM 850 / 900 / 1800 / 1900
3G Network HSDPA 900 / 2100
Announced 2010, June
Status Available. Released 2010, July
SIZE
I5801
Dimensions 113.5 x 55 x 12.6 mm
Weight 113 g
I5800
Dimensions 113.5 x 55 x 12.9 mm
Weight 109 g
DISPLAY
Type TFT capacitive touchscreen, 16M colors
Size 240 x 400 pixels, 3.2 inches
Features - Touch Wiz 3.0
- Accelerometer sensor for UI auto-rotate
- Proximity sensor for auto turn-off
- Multi-touch input method
SOUND
Alert types Vibration; MP3, WAV ringtones
Loudspeaker Yes
3.5mm jack Yes
- DNSe (Digital Natural Sound Engine)
MEMORY
Phonebook Practically unlimited entries and fields, Photocall
Call records Practically unlimited
Internal 512MB ROM, 256MB RAM
Card slot microSD, up to 32GB
DATA
GPRS Class 10 (4+1/3+2 slots), 32 - 48 kbps
EDGE Class 10, 236.8 kbps
3G HSDPA, 3.6 Mbps
WLAN Wi-Fi 802.11 b/g/n, Wi-Fi hotspot (Android 2.2)
Bluetooth Yes, v3.0 with A2DP
Infrared port No
USB Yes, v2.0 microUSB
CAMERA
Primary 3.15 MP, 2048x1536 pixels, autofocus
Features Geo-tagging, face and smile detection
Video Yes, [email protected]
Secondary No
SOFTWARE
OS Android OS, v2.1 (Eclair), upgradable to v2.2
CPU Samsung S5P6442 667 MHz processor
Messaging SMS(threaded view), MMS, Email, Push Mail, IM
Browser HTML
Radio Stereo FM radio with RDS
Games
Colors Black, White
GPS Yes, with A-GPS support
Java Yes, via Java MIDP emulator
- Orange Application Shop
- Orange Maps, Orange TV, Orange Push Email
- Contact Back & Restore, Orange Photo
- Digital compass
- MP4/DivX/XviD/WMV/H.264/H.263 player
- MP3/WAV/eAAC+ player
- Organizer
- Document editor(Word, Excel, PowerPoint, PDF)
- Google Search, Maps, Gmail, YouTube, Calendar, Google Talk integration
- Voice memo
- Predictive text input
BATTERY
Type Standard battery, Li-Ion 1500 mAh
Stand-by Up to 620 h (2G) / Up to 480 h (3G)
Talk time Up to 15 h 30 min (2G) / Up to 7 h 15 min (3G)
3) Hardware
Processor: Samsung S5P6442 (It is modified version of S5P6440)
General Description
SAMSUNG's S5P6440, AKA "Vega-L", is the first member of the "Vega" Series, which is our newest family of Application Processors. Each Application Processor in the Vega Series will maintain a high level of compatibility with each other in order to allow for PND Makers to design their entire line-up of products on a single SoC platform.
The S5P6440 will be Samsung's first AP designed solely for PND's with a strong emphasis on high performance while maintaining cost competitiveness.
In terms of performance, the S5P6440 is run by a powerful ARM1176 processor running at 533MHz, 667MHz with a 64-bit AXI bus.
Additionally, the S5P6440 features both 2D Graphics HW and OpenVG HW, thus providing exceptional graphics acceleration for mainstream PND products. We have also focused heavily on providing optimum IP's and interfaces in order to reduce the Bill-of-Materials of the system as a whole. As an example, the S5P6440 features upgraded NAND Error Correction HW to be able to support next generation MLC NAND Flash devices. The S5P6440 also supports serial LCD protocols via the MIPI DSI standard, which allows for lower cost, lower EMI and simpler integration.
Block Diagram
Features
ARM1176JZF-S 533MHz, 667MHz, 16KB/16KB L1 Cache with Java acceleration Engine
Memory Subsystem
- NAND Flash Interface with x8 data bus, with 1/4/8/12/16-bit hardware ECC circuit and 4KB page mode
- Mobile DDR Interface with x16 or x32 data bus (up to 333Mbps/pin)
- DDR2 Interface with x16 or x32 data bus (up to 333Mbps/pin)
2D Graphics Accelerator with BitBlit and Rotation
Vector Graphics Accelerator with dedicated Anti-Aliasing HW
1/2/4/8 bpp Palletized or 8/16/24bpp Non-Palletized Color-TFT support up to 800x480
Serial LCD I/F support with MIPI DSI
- Two data lanes and one clock lane
4 channel UART: 1 channel muxed with IrDA SIR/FIR
1 channel I2S
2 channel I2C interface support
3 channel MMC/SDHC/SDIO (or 1 ch HS-MMC & 1 ch SD/MMC/SDIO)
On-chip USB 2.0 OTG controller and PHY transceiver supporting high speed
Real time clock, 3 PLL's, timer with PWM and watch dog timer
8 channel DMA controller
12 channel 12-bit ADC (Touch screen interface)
2 channel SPI: 1ch muxed with TSI (transport stream interface)
Configurable GPIOs
Technical Documents:
The Only Technical Document that we have currently is the User Manual of S3C6410 RISC Processor. It is not exactly same as S5P6442 but can be used as a reference.
Download S3C6410 User Manual
TouchScreen: ATMEL mXT224(AT42QT602240)
General Desciption
A 224-node highly configurable touchscreen controller that is part of the Atmel maXTouch product platform. An optimal and scalable architecture enables smart processing of a capacitive touch image to accurately regenerate and report the user’s interaction with the touchscreen. Multi-touch performance identifies and individually tracks touches and allows a range of built-in gestures to be reported to the host processor. The IC provides position data of 12-bit x 12-bit resolution, as well as information on the size and angle of touch. Position data is reported at >250Hz, providing fast and smooth finger tracking, making it suitable for use with demanding applications such as handwriting recognition. Due to the high signal-to-noise ratio (SNR) of up to 80:1, the device works well with fingertip touch and can also be used with a conductive stylus. It is designed to work in demanding, rapidly changing environments. Only the touchscreen area is touch-sensitive, allowing design freedom to place the chip on the main board or adjacent to the sensor. The device is ideally suited to mobile phone-sized touchscreens and can also be used on screens of up to 7", supporting single-touch or two-touch with a larger finger separation.
Technical Documents
mXT224 Datasheet
TFT LCD PANEL: Samsung S6D04D1
General Description
S6D04D1 is a single-chip display driver IC for a TFT-LCD panel. Integrated on this chip are source drivers with built-in
memory, gate drivers and power sources. S6D04D1 can support a TFT-LCD panel up to a resolution of 240-RGB x 432-
dot graphics with 16M-color. S6D04D1 also supports various types of peripheral interface such as 80-series MCU
interface (8-/9-/16-/18-/24-bits data), 3-wire 9bit / 4-wire 8bit serial interface, and MDDI(Mobile Display Digital Interface)
S6D04D1 supports various types of RGB interface (24-/18-/16-/8-/6-bits data).
The Integrated on-chip functions that are described in this document include:
- Power saving: It reduces the overall power consumed in a TFT-LCD panel module.
- Internal GRAM:
- Internal DC/DC voltage converter
- MIE (Mobile Image Enhancement) functions
S6D04D1 features several power saving functions to reduce the overall power consumed in a TFT-LCD panel module:
S6D04D1 operates at low voltage and has internal GRAMs that can store 240-RGB x 432-dot 16M-color image data. In
addition, it has an internal DC/DC voltage converter that generates various voltages needed for driving the TFT-LCD
panel by using breeder resistors and the voltage followers.
Features
A single-chip TFT-LCD Controller/gate driver/source driver with built-in Graphic RAM
Supported Display panel resolution: 240*R/G/B (H) * 432 (V) , 240*R/G/B (H) * 400 (V) & 240*R/G/B (H) * 320 (V)
Integrated 2,488,320bit of graphic RAM (GRAM)
-GRAM configuration: 240 x 432 x 24-bits = 2,488,320bits
Supported Interfaces
-3-wire 9-bit data, 4-wire 8-bit data serial interface (for RGB parallel Interface)
-8-/9-/16-/18-/24- bit interface with 80-Series MCU (so called 80-Series)
-VSYNC I/F
-MDDI(Mobile Display Digital Interface)
Outputs
-Common electrode output
-Gate outputs
-Source outputs
Color Display mode
-Full color mode (Idle mode off): 16M / 260k / 65k colors
-Reduced color mode (Idle mode on): 8-colors (3-bit binary mode)
Color modes on the display host interface
-16-bits/Pixel: RGB= (565) using the 1,843k bit frame memory
-18-bits/Pixel: RGB= (666) using the 1,843k bit frame memory
-24-bits/Pixel: RGB= (888) using the 1,843k bit frame memory
Display features
-Partial display mode
Driving scheme: line inversion & frame inversion
MIE (Mobile Image Enhancement) functions
-Adaptive luminance/contrast enhancement function.
-Reduce the power consumption of backlight.
SE ( Sharpness Enhancement) functions
On-chip functions
-Voltage Boosters
-Adjustable VCOM voltage source generator
-An oscillator for display clock generation & Timing generation
-Factory default value (Contrast, Module ID, Module version, etc) can be stored inside IC
-MTP (Multi-time Programmable) Memory
-MTP initialization & program voltages are generated automatically from the built-in power circuit.
-Each 8-bits product ID1, ID2, ID3
-6-bits VCM Offset adjustment
-Each 5-bits for VML, GVD Offset adjustment
-1 bit for MTP writing protection
Voltage Supplies
-2.3V – 3.3V for VCI, supply voltage for Analog blocks
-1.65V – 3.3V for VDD3, Supply voltage for I/O
Output voltage levels
-2.5V to 5.0V for GVDD, Source output voltage
-AVDD, Power supply for driver circuit (Note 1)
-Maximum 6.0V for VCOM, Common electrode output voltage
-11.25V to 16.50V for VGH, Positive Gate output voltage (Note 2, Note 3)
--13.75V to - 6.75V for VGL, Negative Gate output voltage (Note 2)
CMOS compatible inputs
COG package
Operating temperature range: -40℃ to +85℃
Technical Documents
S6D04D1 Datasheet
4) ROM Basics, Tutorials
STOCK ROM
A stock ROM is the version of the phone's operating system that comes with your phone when you buy it.
Samsung letter code
AW-Hungary AZ-France BD-Cyprus, Greece BY-Greece CB-Poland CE-Benelux CP-Denmark, Finland, Norway, Sweden DB-Vietnam DC-Thailand DD-India DT-Australia DX-Indonesia, Malaysia, Philippines, Singapore, Vietnam DZ-Malaysia, Singapore JA-South Africa JC-Algeria, Morocco, Nigeria, South Africa, Tunisia JP-Arabic JR-Arabic JV-Algeria, Egypt, Iran, Iraq, Kuwait, Morocco, Nigeria, Oman, Pakistan, Saudi Arabia,South Africa, Syria, Tunisia, Turkey JW-West Africa JX-Algeria, Egypt, Iran, Iraq, Kuwait, Morocco, Nigeria, Oman, Pakistan, Saudi Arabia,South Africa, Syria, Tunisia, Turkey KA-Turkey ME-France MK-Serbia MS-France, Germany, Italy, Netherlands, Portugal, Spain, Turkey, UK MT-Switserland MY-Italy NH-Latvia PO-France PU-Russia UB-Brazil XA-Austria, France, Germany, Italy, Netherlands, Switzerland, United Kingdom XB-Denmark, Norway, Sweden XC-Portugal, Spain XD-Croatia, Czech, Hungary, Slovakia XE-Bulgaria, Estonia, Kazakhstan, Latvia, Lithuania, Russia, Ukraine XF-Bulgaria, Croatia, Romania XP-UK, France, Italy, Spain, Netherlands, Poland, Portuguese, Turkey XX-Austria, Belgium, France, Germany, Hungary, Italy, Spain, United Kingdom XW-Austria, Belgium, France, Germany, Hungary, Italy, Spain, United Kingdom ZC-China, Hong Kong ZH-Hong Kong ZS-China, Hong Kong ZT-Taiwan
Custom ROM
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way.
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, strip them of garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow.
Flashing
Flashing Process is basically, installing a new ROM/Kernel, Stock/Custom, via Odin.
Odin is a software used to flash ROM's to the phone in the Download Mode.
Odin used for Galaxy 3 is v4.252.
Steps to follow:
1) Install Samsung Kies
2) Connect phone to PC and let it detect and install drivers automatically.
3) Download Odin with ops file from here.
4) Extract them to some folder.
5) Run Odin as Administrator.
6) Odin will now open.
7) Put phone in download mode. (Vol Down + HOME + POWER)
8) Connect Phone to PC via USB and wait till Odin shows detected.
9) Select One Package.
10) Select .ops file and .tar file for flashing.
11) Press Start button.
12) Wait till the message box on odin shows the following message and phone reboots.
13) You have now successfully flashed new ROM / Kernel.
Rooting
Rooting is a process that allows users of cellphones and other devices running the Android operating system to attain privileged control (known as "root access") within Android's Linux subsystem, similar to jailbreaking on Apple devices running the iOS operating system, overcoming limitations that the carriers and manufacturers put on such phones.
Most retail devices running the Android operating system must be rooted in order to install custom versions of the Android system such as CyanogenMod. This is because in the stock configuration (unrooted), user-installed applications do not have direct access to the flash memory chip on the device and, thus, are not able to replace or modify the operating system itself. Rooting is also necessary for certain applications and widgets that require additional system and hardware rights such as for rebooting the phone, certain backup utilities, and other access to other hardware such as status LEDs. Rooting is also needed to disable or remove manufacturer-installed applications such as City ID. Rooting the phone typically also includes installing an application called Superuser that supervises which applications are granted root rights.
Steps to follow:
1) Download SuperOneClick - Download
2) Run SuperOneClick
3) Press on Root
4) It will show "Waiting for device"
5) Put your phone in USB Debugging Mode.
6) Connect to PC via USB Cable.
7) Press Yes, for the subsequent messages that follow
8) Done
Deodexing
WHAT IS AN ODEX FILE?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
THEN COMES DEODEX
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
In summary, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
HOW THIS WORKS
For the more geeky amongst us, Android OS uses a Java-based virtual machine for running applications, called the Dalvik Virtual Machine. A deodexed, or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
Now, when an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
ADVANTAGES & DISADVANTAGES
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
For a casual user, the main implication is in theming possibilities. Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Steps to follow:
1) Download xUltimate - Download
2) Run Main.exe
3) Press N to continue
4) Press Y to continue
5) You should get a complete menu
6) Connect phone to PC in USB Debugging Mode
7) Run Option 1
8) Run Option 2
9) Run Option 3
10) Run Option 4
11) You Will now have deodexed apps and framework files in done_app and done_frame folders.
12) Copy these folders where you have your adb setup.
13) Run the following Code
Code:
adb -d shell "mount -o remount,rw /dev/block/stl6 /system"
adb -d shell "stop"
adb -d shell "rm /system/app/*.apk"
adb -d shell "rm /system/app/*.odex"
adb -d shell "rm /system/framework/*.jar"
adb -d shell "rm /system/framework/*.odex"
adb -d push done_app /system/app/
adb -d push done_frame /system/framework/
adb reboot
14) Your phone should reboot successfully, and you now have a deodexed ROM.
Clean ROM
The following list of files you can delete to clean ROM
1) BuddiesNow
2) Dlna
3) DualClock
4) FlashSVGPlayer
5) HTMLViewer
6) InfoAlarm
7) InputEventApp
8) Layar-samsung
9) Maps
10) MobileTrackerEngineTwo
11) MobileTrackerUI
12) Protips
13) SamsungApps
14) SamsungWidget_CalendarClock
15) SamsungWidget_FeedAndUpdate
16) SamsungWidget_ProgramMonitor
17) SamsungWidget_StockClock
18) Street
19) UNAService
20) UnifiedInbox
21) VoiceRecorder
22) wipereceiver
23) WriteandGo
5) Kernel Basics
dhirend_6d said:
What Is a Kernel?
The UNIX kernel is the software that manages the user program's access to the systems hardware and software resources. These resources range from being granted CPU time, accessing memory, reading and writing to the disk drives, connecting to the network, and interacting with the terminal or GUI interface. The kernel makes this all possible by controlling and providing access to memory, processor, input/output devices, disk files, and special services to user programs.
Kernel Services
The basic UNIX kernel can be broken into four main subsystems:
Process Management
Memory Management
I/O Management
File Management
These subsystems should be viewed as separate entities that work in concert to provide services to a program that enable it to do meaningful work. These management subsystems make it possible for a user to access a database via a Web interface, print a report, or do something as complex as managing a 911 emergency system. At any moment in the system, numerous programs may request services from these subsystems. It is the kernel's responsibility to schedule work and, if the process is authorized, grant access to utilize these subsystems. In short, programs interact with the subsystems via software libraries and the systems call interface. We'll start by looking at how the UNIX kernel comes to life by way of the system initialization process.
System Initialization
System initialization (booting) is the first step toward bringing your system into an operational state. A number of machine-dependent and machine-independent steps are gone through before your system is ready to begin servicing users. At system startup, there is nothing running on the Central Processing Unit (CPU). The kernel is a complex program that must have its binary image loaded at a specific address from some type of storage device, usually a disk drive. The boot disk maintains a small restricted area called the boot sector that contains a boot program that loads and initializes the kernel. You'll find that this is a vendor specific procedure that reflects the architectural hardware differences between the various UNIX vendor platforms. When this step is completed, the CPU must jump to a specific memory address and start executing the code at that location. Once the kernel is loaded, it goes through its own hardware and software initialization.
Kernel Mode
The operating system, or kernel, runs in a privileged manner known as kernel mode. This mode of operation allows the kernel to run without being interfered with by other programs currently in the system. The microprocessor enforces this line of demarcation between user and kernel level mode. With the kernel operating in its own protected address space, it is guaranteed to maintain the integrity of its own data structures and that of other processes. (That's not to say that a privileged process could not inadvertently cause corruption within the kernel.) These data structures are used by the kernel to manage and control itself and any other programs that may be running in the system. If any of these data structures were allowed to be accidentally or intentionally altered, the system could quickly crash. Now that we have learned what a UNIX kernel is and how it is loaded into the system, we are ready to take a look at the four UNIX subsystems Process Management, Memory Management, Filesystem Management and I/O Management.
Process Management
The Process Management subsystem controls the creation, termination, accounting, and scheduling of processes. It also oversees process state transitions and the switching between privileged and nonprivileged modes of execution. The Process Management subsystem also facilitates and manages the complex task of the creation of child processes.
A simple definition of a process is that it is an executing program. It is an entity that requires system resources, and it has a finite lifetime. It has the capability to create other processes via the system call interface. In short, it is an electronic representation of a user's or programmer's desire to accomplish some useful piece of work. A process may appear to the user as if it is the only job running in the machine. This "sleight of hand" is only an illusion. At any one time a processor is only executing a single process.
Process Structure
A process has a definite structure (see Figure 19.1). The kernel views this string of bits as the process image. This binary image consists of both a user and system address space as well as registers that store the process's data during its execution. The user address space is also known as the user image. This is the code that is written by a programmer and compiled into an ".o " object file. An object file is a file that contains machine language code/data and is in a format that the linker program can use to then create an executable program.
Diagram of process areas.
The user address space consists of five separate areas: Text, Data, Bss, stack, and user area.
Text Segment The first area of a process is its text segment. This area contains the executable program code for the process. This area is shared by other processes that execute the program. It is therefore fixed and unchangeable and is usually swapped out to disk by the system when memory gets too tight.
Data Area The data area contains both the global and static variables used by the program. For example, a programmer may know in advance that a certain data variable needs to be set to a certain value. In the C programming language, it would look like:
Code:
int x = 15;
If you were to look at the data segment when the program was loaded, you would see that the variable x was an integer type with an initial value of 15.
Bss Area The bss area, like the data area, holds information for the programs variables. The difference is that the bss area maintains variables that will have their data values assigned to them during the programs execution. For example, a programmer may know that she needs variables to hold certain data that will be input by a user during the execution of the program.
Code:
int a,b,c; // a,b and c are variables that hold integer values.
char *ptr; // ptr is an unitialized character pointer.
The program code can also make calls to library routines like malloc to obtain a chunk of memory and assign it to a variable like the one declared above.
Stack Area The stack area maintains the process's local variables, parameters used in functions, and values returned by functions. For example, a program may contain code that calls another block of code (possibly written by someone else). The calling block of code passes data to the receiving block of code by way of the stack. The called block of code then process's the data and returns data back to the calling code. The stack plays an important role in allowing a process to work with temporary data.
User Area The user area maintains data that is used by the kernel while the process is running. The user area contains the real and effective user identifiers, real and effective group identifiers, current directory, and a list of open files. Sizes of the text, data, and stack areas, as well as pointers to process data structures, are maintained. Other areas that can be considered part of the process's address space are the heap, private shared libraries data, shared libraries, and shared memory. During initial startup and execution of the program, the kernel allocates the memory and creates the necessary structures to maintain these areas.
The user area is used by the kernel to manage the process. This area maintains the majority of the accounting information for a process. It is part of the process address space and is only used by the kernel while the process is executing(see Figure 19.2). When the process is not executing, its user area may be swapped out to disk by the Memory Manager. In most versions of UNIX, the user area is mapped to a fixed virtual memory address. Under HP-UX 10.X, this virtual address is 0x7FFE6000. When the kernel performs a context switch (starts executing a different process) to a new process, it will always map the process's physical address to this virtual address. Since the kernel already has a pointer fixed to this location in memory, it is a simple matter of referencing the current u pointer to be able to begin managing the newly switched in process. The file /usr/include/sys/user.h contains the user area's structure definition for your version of UNIX.
Diagram of kernel address space.
Process Table The process table is another important structure used by the kernel to manage the processes in the system. The process table is an array of process structures that the kernel uses to manage the execution of programs. Each table entry defines a process that the kernel has created. The process table is always resident in the computer's memory. This is because the kernel is repeatedly querying and updating this table as it switches processes in and out of the CPU. For those processes that are not currently executing, their process table structures are being updated by the kernel for scheduling purposes. The process structures for your system are defined in /usr/include/sys/proc.h.
Fork Process The kernel provides each process with the tools to duplicate itself for the purpose of creating a new process. This new entity is termed a child process. The fork() system call is invoked by an existing process (termed the parent process) and creates a replica of the parent process. While a process will have one parent, it can spawn many children. The new child process inherits certain attributes from its parent.
Process Run States
A process moves between several states during its lifetime, although a process can only be in one state at any one time. Certain events, such as system interrupts, blocking of resources, or software traps will cause a process to change its run state. The kernel maintains queues in memory that it uses to assign a process to based upon that process's state. It keeps track of the process by its user ID.
UNIX version System V Release 4 (SVR4) recognizes the following process run states:
Code:
- SIDLE This is the state right after a process has issued
a fork() system call. A process image has yet to be copied into memory.
- SRUN The process is ready to run and is waiting to be executed by the CPU.
- SONPROC The process is currently being executed by the CPU.
- SSLEEP The process is blocking on an event or resource.
- SZOMB The process has terminated and is waiting on
either its parent or the init process to allow it to completely exit.
- SXBRK The process is has been switched out so that another process can be executed.
- SSTOP The process is stopped.[/COLOR]
When a process first starts, the kernel allocates it a slot in the process table and places the process in the SIDL state. Once the process has the resources it needs to run, the kernel places it onto the run queue. The process is now in the SRUN state awaiting its turn in the CPU. Once its turn comes for the process to be switched into the CPU, the kernel will tag it as being in the SONPROC state. In this state, the process will execute in either user or kernel mode. User mode is where the process is executing nonprivileged code from the user's compiled program. Kernel mode is where kernel code is being executed from the kernel's privileged address space via a system call.
At some point the process is switched out of the CPU because it has either been signaled to do so (for instance, the user issues a stop signal--SSTOP state) or the process has exceeded its quota of allowable CPU time and the kernel needs the CPU to do some work for another process. The act of switching the focus of the CPU from one process to another is called a context switch. When this occurs, the process enters what is known as the SXBRK state. If the process still needs to run and is waiting for another system resource, such as disk services, it will enter the SSLEEP state until the resource is available and the kernel wakes the process up and places it on the SRUN queue. When the process has finally completed its work and is ready to terminate, it enters the SZOMB state. We have seen the fundamentals of what states a process can exist in and how it moves through them. Let's now learn how a kernel schedules a process to run.
Process Scheduler
Most modern versions of UNIX (for instance, SVR4 and Solaris 2.x) are classified as preemptive operating systems. They are capable of interrupting an executing a process and "freezing" it so that the CPU can service a different process. This obviously has the advantage of fairly allocating the system's resources to all the processes in the system. This is one goal of the many systems architects and programmers who design and write schedulers. The disadvantages are that not all processes are equal and that complex algorithms must be designed and implemented as kernel code in order to maintain the illusion that each user process is running as if it was the only job in the system. The kernel maintains this balance by placing processes in the various priority queues or run queues and apportioning its CPU time-slice based on its priority class (Real-Time versus Timeshare).
Memory Management
Random access memory (RAM) is a very critical component in any computer system. It's the one component that always seems to be in short supply on most systems. Unfortunately, most organizations' budgets don't allow for the purchase of all the memory that their technical staff feel is necessary to support all their projects. Luckily, UNIX allows us to execute all sorts of programs without, what appears at first glance to be, enough physical memory. This comes in very handy when the system is required to support a user community that needs to execute an organization's custom and commercial software to gain access to its data.
Memory chips are high-speed electronic devices that plug directly into your computer. Main memory is also called core memory by some technicians. Ever heard of a core dump? (Writing out main memory to a storage device for post-dump analysis.) Usually it is caused by a program or system crash or failure. An important aspect of memory chips is that they can store data at specific locations called addresses. This makes it quite convenient for another hardware device called the central processing unit (CPU) to access these locations to run your programs. The kernel uses a paging and segmentation arrangement to organize process memory. This is where the memory management subsystem plays a significant role. Memory management can be defined as the efficient managing and sharing of the system's memory resources by the kernel and user processes.
Memory management follows certain rules that manage both physical and virtual memory. Since we already have an idea of what a physical memory chip or card is, we will provide a definition of virtual memory. Virtual memory is where the addressable memory locations that a process can be mapped into are independent of the physical address space of the CPU. Generally speaking, a process can exceed the physical address space/size of main memory and still load and execute.
The systems administrator should be aware that just because she has a fixed amount of physical memory, she should not expect it all to be available to execute user programs. The kernel is always resident in main memory and depending upon the kernel's configuration (tunable-like kernel tables, daemons, device drivers loaded, and so on), the amount left over can be classified as available memory. It is important for the systems administrator to know how much available memory the system has to work with when supporting his environment. Most systems display memory statistics during boot time. If your kernel is larger than it needs to be to support your environment, consider reconfiguring a smaller kernel to free up resources.
We learned before that a process has a well-defined structure and has certain specific control data structures that the kernel uses to manage the process during its system lifetime. One of the more important data structures that the kernel uses is the virtual address space (vas in HP-UX and as in SVR4. For a more detailed description of the layout of these structures, look at the vas.h or as.h header files under /usr/include on your system.).
A virtual address space exists for each process and is used by the process to keep track of process logical segments or regions that point to specific segments of the process's text (code), data, u_area, user, and kernel stacks; shared memory; shared library; and memory mapped file segments. Per-process regions protect and maintain the number of pages mapped into the segments. Each segment has a virtual address space segment as well. Multiple programs can share the process's text segment. The data segment holds the process's initialized and uninitialized (BSS) data. These areas can change size as the program executes.
The u_area and kernel stack contain information used by the kernel, and are a fixed size. The user stack is contained in the u_area; however, its size will fluctuate during its execution. Memory mapped files allow programmers to bring files into memory and work with them while in memory. Obviously, there is a limit to the size of the file you can load into memory (check your system documentation). Shared memory segments are usually set up and used by a process to share data with other processes. For example, a programmer may want to be able to pass messages to other programs by writing to a shared memory segment and having the receiving programs attach to that specific shared memory segment and read the message. Shared libraries allow programs to link to commonly used code at runtime. Shared libraries reduce the amount of memory needed by executing programs because only one copy of the code is required to be in memory. Each program will access the code at that memory location when necessary.
When a programmer writes and compiles a program, the compiler generates the object file from the source code. The linker program (ld) links the object file with the appropriate libraries and, if necessary, other object files to generate the executable program. The executable program contains virtual addresses that are converted into physical memory addresses when the program is run. This address translation must occur prior to the program being loaded into memory so that the CPU can reference the actual code.
When the program starts to run, the kernel sets up its data structures (proc, virtual address space, per-process region) and begins to execute the process in user mode. Eventually, the process will access a page that's not in main memory (for instance, the pages in its working set are not in main memory). This is called a page fault. When this occurs, the kernel puts the process to sleep, switches from user mode to kernel mode, and attempts to load the page that the process was requesting to be loaded. The kernel searches for the page by locating the per-process region where the virtual address is located. It then goes to the segments (text, data, or other) per-process region to find the actual region that contains the information necessary to read in the page.
The kernel must now find a free page in which to load the process's requested page. If there are no free pages, the kernel must either page or swap out pages to make room for the new page request. Once there is some free space, the kernel pages in a block of pages from disk. This block contains the requested page plus additional pages that may be used by the process. Finally the kernel establishes the permissions and sets the protections for the newly loaded pages. The kernel wakes the process and switches back to user mode so the process can begin executing using the requested page. Pages are not brought into memory until the process requests them for execution. This is why the system is referred to as a demand paging system.
The memory management unit is a hardware component that handles the translation of virtual address spaces to physical memory addresses. The memory management unit also prevents a process from accessing another process's address space unless it is permitted to do so (protection fault). Memory is thus protected at the page level. The Translation Lookaside Buffer (TLB) is a hardware cache that maintains the most recently used virtual address space to physical address translations. It is controlled by the memory management unit to reduce the number of address translations that occur on the system.
Input and Output Management
The simplest definition of input/output is the control of data between hardware devices and software. A systems administrator is concerned with I/O at two separate levels. The first level is concerned with I/O between user address space and kernel address space; the second level is concerned with I/O between kernel address space and physical hardware devices. When data is written to disk, the first level of the I/O subsystem copies the data from user space to kernel space. Data is then passed from the kernel address space to the second level of the I/O subsystem. This is when the physical hardware device activates its own I/O subsystems, which determine the best location for the data on the available disks.
The OEM (Original Equipment Manufacture) UNIX configuration is satisfactory for many work environments, but does not take into consideration the network traffic or the behavior of specific applications on your system. Systems administrators find that they need to reconfigure the systems I/O to meet the expectations of the users and the demands of their applications. You should use the default configuration as a starting point and, as experience is gained with the demands on the system resources, tune the system to achieve peak I/O performance.
UNIX comes with a wide variety of tools that monitor system performance. Learning to use these tools will help you determine whether a performance problem is hardware or software related. Using these tools will help you determine whether a problem is poor user training, application tuning, system maintenance, or system configuration. sar, iostat, and monitor are some of your best basic I/O performance monitoring tools.
1) sar The sar command writes to standard output the contents of selected cumulative activity counters in the operating system. The following list is a breakdown of those activity counters that sar accumulates.
* File access
* Buffer usage
* system call activity
* Disk and tape input/output activity
* Free memory and swap space
* Kernel Memory Allocation (KMA)
* Interprocess communication
* Paging
* Queue Activity
* Central Processing Unit (CPU)
* Kernel tables
* Switching
* Terminal device activity
2) iostat Reports CPU statistics and input/output statistics for TTY devices, disks, and CD-ROMs.
3) monitor Like the sar command, but with a visual representation of the computer state.
RAM I/O
The memory subsystem comes into effect when the programs start requesting access to more physical RAM memory than is installed on your system. Once this point is reached, UNIX will start I/O processes called paging and swapping. This is when kernel procedures start moving pages of stored memory out to the paging or swap areas defined on your hard drives. (This procedure reflects how swap files work in Windows by Microsoft for a PC.) All UNIX systems use these procedures to free physical memory for reuse by other programs. The drawback to this is that once paging and swapping have started, system performance decreases rapidly. The system will continue using these techniques until demands for physical RAM drop to the amount that is installed on your system. There are only two physical states for memory performance on your system: Either you have enough RAM or you don't, and performance drops through the floor.
Memory performance problems are simple to diagnose; either you have enough memory or your system is thrashing. Computer systems start thrashing when more resources are dedicated to moving memory (paging and swapping) from RAM to the hard drives. Performance decreases as the CPUs and all subsystems become dedicated to trying to free physical RAM for themselves and other processes.
This summary doesn't do justice, however, to the complexity of memory management nor does it help you to deal with problems as they arise. To provide the background to understand these problems, we need to discuss virtual memory activity in more detail.
We have been discussing two memory processes: paging and swapping. These two processes help UNIX fulfill memory requirements for all processes. UNIX systems employ both paging and swapping to reduce I/O traffic and execute better control over the system's total aggregate memory. Keep in mind that paging and swapping are temporary measures; they cannot fix the underlying problem of low physical RAM memory.
Swapping moves entire idle processes to disk for reclamation of memory, and is a normal procedure for the UNIX operating system. When the idle process is called by the system again, it will copy the memory image from the disk swap area back into RAM.
On systems performing paging and swapping, swapping occurs in two separate situations. Swapping is often a part of normal housekeeping. Jobs that sleep for more that 20 seconds are considered idle and may be swapped out at any time. Swapping is also an emergency technique used to combat extreme memory shortages. Remember our definition of thrashing; this is when a system is in trouble. Some system administrators sum this up very well by calling it "desperation swapping."
Paging, on the other hand, moves individual pages (or pieces) of processes to disk and reclaims the freed memory, with most of the process remaining loaded in memory. Paging employs an algorithm to monitor usage of the pages, to leave recently accessed pages in physical memory, and to move idle pages into disk storage. This allows for optimum performance of I/O and reduces the amount of I/O traffic that swapping would normally require.
NOTE: Monitoring what the system is doing is easy with the ps command. ps is a "process status" command on all UNIX systems and typically shows many idle and swapped-out jobs. This command has a rich amount of options to show you what the computer is doing.
I/O performance management, like all administrative tasks, is a continual process. Generating performance statistics on a routine basis will assist in identifying and correcting potential problems before they have an impact on your system or, worst case, your users. UNIX offers basic system usage statistics packages that will assist you in automatically collecting and examining usage statistics.
You will find the load on the system will increase rapidly as new jobs are submitted and resources are not freed quickly enough. Performance drops as the disks become I/O bound trying to satisfy paging and swapping calls. Memory overload quickly forces a system to become I/O and CPU bound.
Filesystem Concept
Filesystem is the collection place on disk device(s) for files. Visualize the filesystem as consisting of a single node at the highest level (ROOT) and all other nodes descending from the root node in a tree-like fashion (see Figure 19.5) . The second meaning will be used for this discussion, and Hewlett Packard's High-performance Filesystem will be used for technical reference purposes.
Diagram of a Android' s hierarchical filesystem.
The superblock is the key to maintaining the filesystem. It's an 8 KB block of disk space that maintains the current status of the filesystem. Because of its importance, a copy is maintained in memory and at each cylinder group within the filesystem. The copy in main memory is updated as events transpire. The update daemon is the actual process that calls on the kernel to flush the cached superblocks, modified inodes, and cached data blocks to disk. The superblock maintains the following static and dynamic information about the
Click to expand...
Click to collapse
6) Tools/Imp Download Links
rickslick said:
Samsung USB drivers(no more kies) for 32bit and 64bit windows: Driver
Adb with ncessary dll : Click here
Flashing tools(odin+ops):click here
Click to expand...
Click to collapse
7) Complete List of ROMs,Kernels for G3
dhirend_6d said:
GINGERBREAD BASED ROMS : -
CYANOGENMOD 7 AND GINGERBREAD AOSP by Marcellusbe.
AOSP FROYO BASED ROMS : -
CYANOGENMOD 6.2 by Marcellusbe.
SAMSUNG FROYO BASED ROMS : -
1) G3MOD ROM by DharamG3 and G3Mod team.
2) KYRILLOS' ROM by Kyrillos13.
3) INDROID by Rudolf895, Arunmcops, Neeljinwala, Akash, Chirayu.
4) DUTCHMODS by Werker123.
5) DESTINY by Hodostamas.
6) KYORAROM by Hillbeast.
7) STYLOO' S AOSP STYLE ROM by Styloo.
8) LESTATIOUS ROM by The Dark Lestat.
9) GRIGORA ROM by RafayelG.
10) SUMEE ROM by Ash!sh.
11) STOCK DEODEXED ROOTED ROMS by DharamG3.
12) DHARAM' S ROM COLLECTION by DharamG3.
13) SAMSUNG STOCK FIRMWARES (WITHOUT BOOTLOADERS) by Kyrillos13.
14) IBREAD.NITESH by Niteshtak.
15) GREENMODS POX by Jazux, Akash, Pauri, s3th.g3ck0.
16) ATROM by Dpthakar.
17) SPEEDMOD ROM by Styloo and DharamG3.
18) RAFO' S ROM by RafayelG.
19) REAPER REVIVAL ROM by Jihaa.
20) APOCALYPSE by ARMVKDevs.
21) BURAK' S ROM by Burak721.
22) CYANOBROZZU MOD ROM by Superfancy97.
23) OUM ROM by Revant.
24) THE PEOPLE' S ROM by Shekhargreen.
25) GALACTIC BLUE ROM by Cdesai, Shubhamchamaria, Aarun.
26) PSYCHOTIK ROM by TotorLeTaureau
27) [KERNEL+ROM] APOLLO by Apollo5801
28) THE BLUE by Abhi0n0nakul.
KERNELS : -
KERNELS BY DHARAM AND TEAM G3MOD : -
1) G3Mod Kernels for Froyo.
2) G3Mod Kernels for CM 6.2.
All the kernels of G3Mod along with changelog and features can be found here.
KERNELS BY MARCELLUSBE : -
1) FuguMod 2.4 Beta 3 (JFS/REISERFS Supported), 800 Mhz Edition.
2) FuguMod 2.4 Beta 3 (JFS/REISERFS Supported), Standard Edition.
3) FuguMod 2.4 Beta 3, 800 MHz Edition.
4) FuguMod 2.4 Beta 3, Standard Edition.
5) FuguMod 2.2 Bleeding Edge Edition.
6) FuguMod 2.2 Standard Edition.
Link to all the above kernels here.
For features and changelog see here.
7) FuguMod Ultra.
KERNELS BY APOLLO5801 : -
Dual Boot kernel.
KERNELS BY GSAM101 : -
SAM' S KERNEL V0.1.
Click to expand...
Click to collapse
8) FAQ For G3
9) EPIC Fail Ideas for G3
hillbeast said:
Seeing nobody has posted any real epic fail ideas, I will post one: I saw a guy wanting to post iOS to our phone. Now I can understand an iOS skin, but why would we want an OS that can't even handle multitasking properly and replace the glory of Android with Steve Jobs' locked down nutjob OS?
Click to expand...
Click to collapse
Credits
1) Android Basics
http://www.wikipedia.org/
http://developer.android.com/index.html
2) Galaxy 3 Features
www.gsmarena.com
3) Hardware
http://www.samsung.com/
http://www.atmel.com
4) ROM Basics/Tutorails
Flashing - BraveBuddy
dharamg3 said:
Credits
rudolf895, jazux and sekhargreen for their tutorials and how-to's....
loads more too come...i will add as i add the context...
but thanks to all the developers doing the wonderful work for Galaxy 3
Click to expand...
Click to collapse
Damn this is going to be a long one because you reserved 10 posts good luck
jazux said:
Damn this is going to be a long one because you reserved 10 posts good luck
Click to expand...
Click to collapse
just wait and see..hoping to cover everything
dharamg3 said:
Credits
rudolf895, jazux and sekhargreen for their tutorials and how-to's....
loads more too come...i will add as i add the context...
but thanks to all the developers doing the wonderful work for Galaxy 3
Click to expand...
Click to collapse
Hi,
It is good to get all the stuff at one place.
Let me know if any help needed.
sekhargreen said:
Hi,
It is good to get all the stuff at one place.
Let me know if any help needed.
Click to expand...
Click to collapse
sure, you can give me links here on what all can be added...
you can call the topic: "the ultimate guide for the galaxy 3"
vonuzu said:
you can call the topic: "the ultimate guide for the galaxy 3"
Click to expand...
Click to collapse
let me start off...it will take time to make it the ultimate
Android Basics Added to start off...Much More To Come
NICE WORK! Im definetly going to mail the xda newswriter about this
done in week you are going to be in news, for sure
This subject topic will be the most significant added value to this forum:
For the new members (sometime old once) that are joining the G3 revolution (and this is happing here), there is a need to provide them the basics before they can dive into elements such as: Custom ROM's, Kernel's...etc.
Myself as a junior user and others will greatly appreciate this new introduced topic.
I'm making this "DICTIONARY" for android abbreviations & terminology and also about Moto G
use this if Moto G is your first android,if you are new at XDA or if you have any doubt
Thanks to @kloud_ and @appdroid for making other guides that i gonna merge and adapt with this one
Ctrl+F is your new best friend,use it
ANDROID REFERENCE LIST
ADK: Android Development Kit, What people use to develop anything for the Android such as APPs and ROM's
adb: Android Debug Bridge, a command-line debugging application included with the SDK. It provides tools to browse the device, copy tools on the device, & forward ports for debugging. If you are developing in Eclipse using the ADT Plugin, adb is integrated into your development environment.
Android Unveiled on 5 November 2007, Android is a mobile operating system running on the Linux kernel developed by Google.
AOSP: Android Open System Project, usually you will see this term when referring to a program or ROM. This will mean that the program or ROM was taken from Google & does not contain any modifications done by the phone Manufacturer or the phone service provider. This is Android the way Google intended.
ART - successor of Dalvik, a virtual machine (VM) that’s part of the Android OS. ART is faster than Dalvik and saves more energy
Baseband or Radio: In communications & signal processing, the baseband describes signals & systems whose range of the frequencies measured from close to 0 hertz to a cut-off frequency, a maximum bandwidth or highest signal frequency; it is sometimes used to describe frequencies starting close to zero
Binary - (sometimes called bin's) a group of executable files.
Bloatware:unnecessary features that are not used by end users and come with the phone (like Samsung touchwiz or other APPs) (luckly Moto G is almost a pure/stock android)
BootLoader: In literal terms, boot loader is code that is executed before any Operating System starts to run. The concept of boot loaders is universal to virtually all Operating systems that includes operating systems on your PC, laptop, Smartphone, & other such devices. Boot loaders basically package the instructions to boot operating system kernel & most of them also have their own debugging or modification environment. As the boot-loader kicks off before any piece of software on your device, it makes it extremely processor specific & every motherboard has its own bootloader.
Boot Loader(Unlocked): A locked or unlocked boot loader is what gives you access to “root.” “Root” is another big word in the Android community. If you “root” a device, it means you have “super user” access or “administrator” access to the operating system that runs on your phone. Root access of your Android device gives you the ability to flash ROMs. Alert:unlocking your Moto G boot-loader will void your warranty
Boot Loop: Simply means something is preventing the phone from completing it's boot cycle & is stuck between the boot animation & the unlock screen, creating a looped animation. This is often fixed by either reloading a NAndroid, or Reflashing a ROM from the xRecovery/ClockworkMod Recovery/Flashtool.
Brick or Bricked: Jargon for a completely unrecoverable device, (no more than a brick or paperweight)
Bug or Software Bug: An Error or flaw in software that produces a failure or unexpected/unwanted result. Typically created from incorrect code, this is why some ROMs are better & smoother running than others because developers have taken the time to input "perfect" code (read put in a lot of hours & hard work)
Busybox: A single multicall binary that packages the functionality of most widely used standard Unix tools, BusyBox provides a fairly complete environment for any small or embedded system.
CDMA/GSM - A type of network communication between phones and carriers. GSM phones normally are included with SIM Cards that authorize them onto the network. CDMA have this authorization built in and do not need a sim card.
COMPCACHE: (compressed caching) is, in short, virtual swap, setting aside a certain percentage (usually 25%) of your RAM as 'compressed' swap. Compcache compresses the data that would normally go to swap, then moves it back into RAM, and reverses the process when moving it out of the 'compressed' swap. However, this is a classic space-time tradeoff. You effectively get more RAM from the compression, but it is slower than 'normal' RAM due to the CPU time required to compress and decompress the swapped pages.
ClockworkMod - CWR - CWM: A recovery program that is often used to apply updates, ROMs, or create a back up or restore a backup file
Dalvik: An open source, register-based virtual machine (VM) that’s part of the Android OS. The Dalvik VM executes files in the Dalvik Executable (.dex) format & relies on the Linux kernel for additional functionality like threading & low-level memory management. The virtual machine is register-based, and it can run classes compiled by a Java language compiler that have been transformed into its native format using the included "dx" tool.
Dalvik Cache: A program cache area for the program Dalvik. Dalvik is a java based virtual machine that is the basis for running your programs (the ones that have the .apk extension). In order to make access times faster (because there's not JIT (just in time) compiler installed by default), the dalvik-cache is the result of dalvik doing a optimization of the running program. It's similar to the prefetch files in Windows.
DDMS: Dalvik Debug Monitor Service, a GUI debugging application included with the SDK. It provides screen capture, log dump, and process examination capabilities. If you are developing in Eclipse using the ADT Plugin, DDMS is integrated into your development environment.
Deep Sleep: A state when the CPU is off, display dark, device is waiting for external input.
De-odex: Apk files have respective odexes that devs use to supposedly save space. Deodexing means you convert it back to a .dex file & put it back inside the apk. This allows you to easily replace files (not having to worry about odexes), but the main point was to deodex services.jar so that you can change all text to different colors (such as the clock color to white) & to deodex services.jar, you need to deodex everything.
Dev. or Developer: An individual that creates, or alters a file in such a manner as to advance the program
Drawable: A compiled visual resource that can be used as a background, title, or other part of the screen. A drawable is typically loaded into another UI element, for example as a background image. A drawable is not able to receive events, but does assign various other properties such as "state" and scheduling, to enable subclasses such as animation objects or image libraries. Many drawable objects are loaded from drawable resource files — xml or bitmap files that describe the image. Drawable resources are compiled into subclasses of android.graphics.drawable. For more information about drawables and other resources.
Execute - To "run" or "start" a binary
Fastboot: Protocol used to update the flash file system in Android devices from a host over USB. It allows flashing of unsigned partition images.
Flash - Flashing : The process of applying a firmware image (or ROM) to a device. It generally entails a very specific order of steps. Failing to complete any one of these steps properly may result in soft/hard) bricking
Flash Memory: a program technology that can be electrically erased & reprogrammed
FOTA - "Firmware over the air" this normally refers to ROM's but can refer to radio firmware (see OTA)
Kernel: The main component of Android operating system.
It is a bridge between applications & the actual data processing done at the hardware level.
The kernel's responsibilities include managing the system's resources (the communication between hardware & software components).
[Usually as a basic component of an operating system, a kernel can provide the lowest-level abstraction layer for the resources
(especially processors & I/O devices) that application software must control to perform its function.
It typically makes these facilities available to application processes through inter-process communication mechanisms & system calls.
Operating system tasks are done differently by different kernels, depending on their design & implementation.]
Governor - A system embedded into the kernel to automatically change the current working CPU frequency depending on the workload. It would only go up to what it is overclocked (or underclocked) to, this is called the maximum frequency. It would not drop bellow the (just as easily configurable) minimum frequency.
Jelly Bean - JB - Android from 4.1 to 4.3
JDK - "Java Development Kit" an SDK for the java platform. It is needed to run the Android SDK.
JRE - "Java Runtime Environment" a collection of binarys and files to allow java software to execute.
KANG - The process of creating a code based of someone else's code.
Kit Kat - KK - Android 4.4 the newest android available (supported by Moto G)
Library's/Libs - a set of instructions for applications to use to function. A functioning camera lib would allow the camera to be used.
Logcat :A debugging tool built into Android devices that displays system logs as they occur. See Logcat.
Manifest File: An XML file that each application must define, to describe the application's package name, version, components (activities, intent filters, services), imported libraries, and describes the various activities, and so on. See The AndroidManifest.xml File for complete information.
Nine-patch / 9-patch / Ninepatch image
A re-sizeable bitmap resource that can be used for backgrounds or other images on the device.
Nandroid or Nandroid Backup: A file typically created in the custom recovery program, such as xRecovery, that is a carbon copy of whatever state your phone is in before a drastic change is made. The file then can be moved onto or off of the SD card for later use in case something should go wrong in the ROM or Update, or a Boot Loop occurs
OEM: Original Equipment Manufacturer, the people who actually put together electronic hardware. Also refers to any equipment original to the phone, or produced by the company for the phone
OpenGL ES: Android provides OpenGL ES libraries that you can use for fast, complex 3D images. It is harder to use than a Canvas object, but better for 3D objects. The android.opengl and javax.microedition.khronos.opengles packages expose OpenGL ES functionality.
Open-Source - (not to be confused with free) A piece of software that is free to edit, use, distribute and share with no charge.
OS: Operating system, I.E. Windows Vista, LINUX or MAC or Android
OTA: Over-the-Air; method T-Mobile, & some other phone companies, uses to update Android phones. The new versions of Android are developed by Google & then released to OEM's, Sony Ericsson in our case. The OEM then writes drivers that enable the new software to work on the phone's hardware. They also develop any specialized UI (user interface), like Timescape & Mediascape, or other software they want to include. Once this is complete, they turn it over to the cell phone company, (e.g.)Tmobile, who then have to do the final checks to make sure the update works, & then distributes it over there data network using their cell transmitters.
Overclocking (OC): Speeding up the CPU past the factory presets to achieve a faster & more responsive device (prolonged run can be injurious to your device, so be careful.)
RAM- Could be one of three meanings: 1. Memory for the CPU to process processes. 2. Random Access Memory, a place where information can be used, executed from, modified, or deleted
Recovery - Its a dedicated Android partition, that has Recovery console installed. This is invisible during normal operation of the android device.
ROM: Read Only Memory, a program used to make changes to anything from the look of the home screen to icons to custom boot animation
Root: Common word associated with giving a user "super user" access to their phones programming & other various aspects that would normally not be possible, also known as "Jailbroken" for iPhone's, "Administrator Rights" in Windows OS.
Shell or SSH: The shell is the layer of programming that understands & executes the commands a user enters. In some systems, the shell is called a command interpreter. A shell usually implies an interface with a command syntax (think of the DOS operating system & its "C:>" prompts & user commands such as "dir" & "edit"). secure shell or ssh is a network protocol that allows data to be exchanged using a secure channel between two networked devices
SQLite: An embedded relational database management system contained in a relatively small (~275 kB) C programming library. It is multitasking concerning reads. Writes can be done only one-at-a-time. It is a popular choice for local/client storage on web browsers. It has many bindings to programming languages. It is arguably the most widely used database engine, as it is used today by several widespread browsers, operating systems, embedded systems among others
Stock Android : Simply means an unaltered state, such as when you first purchase your phone fromVerizon/Your Service Provider or when you repair your phone using PC Companion or SE Update Service(SEUS)
SU: "Super user", or root permissions
Superuser: A program, which gives unlimited access privileges to perform any or all operations on the operating system.
SWAP: is, in short, virtual RAM. With swap, a small portion of the hard drive is set aside and used like RAM. The computer will attempt to keep as much information as possible in RAM until the RAM is full. At that point, the computer will begin moving inactive blocks of memory (called pages) to the hard disk, freeing up RAM for active processes. If one of the pages on the hard disk needs to be accessed again, it will be moved back into RAM, and a different inactive page in RAM will be moved onto the hard disk ('swapped'). The trade off is disks and SD cards are considerably slower than physical RAM, so when something needs to be swapped, there is a noticeable performance hit.
Unlike traditional swap, Android's Memory Manager kills inactive processes to free up memory. Android signals to the process, then the process will usually write out a small bit of specific information about its state (for example, Google Maps may write out the map view coordinates; Browser might write the URL of the page being viewed) and then the process exits. When you next access that application, it is restarted: the application is loaded from storage, and retrieves the state information that it saved when it last closed. In some applications, this makes it seem as if the application never closed at all. This is not much different from traditional swap, except that Android apps are specially programed to write out very specific information, making Android's Memory Manager more efficient that swap.
Theme: A set of icons, backgrounds & app trays that change the aesthetics of the overall look of the Android & its applications. It has a set of properties (text size, background color, and so on) bundled together to define various default display settings. Android provides a few standard themes, listed in R.style (starting with "Theme_").
TUN/TAP: Refers to a network TUNnel, operates within layer 3 packets, or ip packets. Packets sent by a system via a TUN/TAP device are delivered to a user-space program that attaches itself to the device. A user space program may also pass packets into a TUN/TAP device. In this case TUN/TAP device delivers (or "injects") these packets to the operating system's network stack thus emulating their reception from an external source.
Underclocking(UC): Slowing down the CPU mainly to limit battery usage
Undervolting(UV): Basically keeping the clock speed same (or overclocking it) & reduce the voltage at each cpu cycle.
xRecovery: A recovery program based on the ClockworkMod Recovery sources used to apply updates, ROMs, or create a back up or restore a backup file
Wipe - to clean your device memory,recommended before flashing
File Types:
.dex: Compiled Android application code file. Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
.sbf: Summation Briefcase File
.apk or APK's: An .apk file extension denotes an Android Package (APK) file, an .apk file can be opened & inspected using common archive tools. 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".
.tar: Similar to a zip file(derived from tape archive), a tar file archives multiple files into one file
.tgz: TGZ files (gnu-zipped .tar file) are commonly used as install packages for Slackware Linux.
######
Will add latter some MOTOROLA MOTO G especific terms here
######
If you doubt is not about general android,but about Moto G,
--Check this FAQ made by @matmutant
Frequently Asked Questions -Motorola Moto G
--Also check this Resource Guide made by @Perseus71
Welcome to your Motorola Moto G
#####
Help improving this topic,quote me and give your suggestion
thanks for a still unknown ADM for sticking this thread
if i helped you with this post,just hit the thanks button,
This thread looks nice and useful, but make sure not to duplicate things from my FAQ or @Perseus71 guide that would be useless and confusing
@matmutant
Yes sir, I'm taking this care and wanna make this thread useful
if you know any thread that i should include in this topic or have any tip,just let me know
My Thread has a list of terms similarly in the first post. But this list seems more specific to Moto G.
Either way there seems to be some terms that are missing here but are present in mine.
Would you be kind enough to merge the differences so I will link to yours and get rid of mine ?
@Perseus71 Just realized I missed some terms, thanks for noticing, will merge them and also include new terms such as "ART" "KK "JB" "google now"
That would be a nice idea, and then rename this thread to something like "Android related terms and abbreviations" because it's neither a FAQ, nor a Guide
72off said:
@Perseus71 Just realized I missed some terms, thanks for noticing, will merge them and also include new terms such as "ART" "KK "JB" "google now"
Click to expand...
Click to collapse
matmutant said:
That would be a nice idea, and then rename this thread to something like "Android related terms and abbreviations" because it's neither a FAQ, nor a Guide
Click to expand...
Click to collapse
+1 all round.
@72off please let me know when you are done.
@Perseus71 @matmutant
Updates on 15/01 = new terms added
Binary - (sometimes called bin's) a group of executable files.
CDMA/GSM - A type of network communication between phones and carriers. GSM phones normally are included with SIM Cards that authorize them onto the network. CDMA have this authorization built in and do not need a sim card.
Execute - To "run" or "start" a binary
FOTA - "Firmware over the air" this normally refers to ROM's but can refer to radio firmware (see OTA)
Governor - A system embedded into the kernel to automatically change the current working CPU frequency depending on the workload. It would only go up to what it is overclocked (or underclocked) to, this is called the maximum frequency. It would not drop bellow the (just as easily configurable) minimum frequency.
JDK - "Java Development Kit" an SDK for the java platform. It is needed to run the Android SDK.
JRE - "Java Runtime Environment" a collection of binarys and files to allow java software to execute.
KANG - The process of creating a code based of someone else's code.
Library's/Libs - a set of instructions for applications to use to function. A functioning camera lib would allow the camera to be used.
Open-Source - (not to be confused with free) A piece of software that is free to edit, use, distribute and share with no charge.
RAM - Could be one of three meanings: 1. Memory for the CPU to process processes. 2. Random Access Memory, a place where information can be used, executed from, modified, or deleted
Recovery - Its a dedicated Android partition, that has Recovery console installed. This is invisible during normal operation of the android device.
Wipe - to clean your device memory,recommended before flashing
Jelly Bean - JB - Android from 4.1 to 4.3
Kit Kat - KK - Android 4.4 the newest android available (supported by Moto G)
ART - successor of Dalvik, a virtual machine (VM) that’s part of the Android OS. ART is faster than Dalvik and saves more energy
Right now 18/01 ordering by alphabetic order [completed]
Reference Links
It might be nice to add in some reference links for many of the terms to the official android pages.
ART - http://source.android.com/devices/tech/dalvik/art.html
.DEX - http://source.android.com/devices/tech/dalvik/dex-format.html
Dalvaik - http://source.android.com/devices/tech/dalvik/index.html
ADB - http://developer.android.com/tools/help/adb.html
Logcat - http://developer.android.com/tools/help/logcat.html
Other suggestions
At the end of the Dalvaik section you might add a sentence that says "see ART".
Maybe a mention about XPosed framework since it is very prevalent now.
In the definition of ROM it might be nice to explain a ROM image.
This is something I cannot find: What exactly does AOSPA(+) mean? Alternative?
Kernel is alphabetically in the wrong position in the list.
Explanation for the term MOD / Modification.
Add cool Android KitKat and Jelly Bean history link http://www.android.com/kitkat/
:good: Thanks for the nice list.
OTG missing?
AS this thread is always under development,i'm glad for the suggestions to make this a better thread
DigitalSnow said:
It might be nice to add in some reference links for many of the terms to the official android pages.
ART - http://source.android.com/devices/tech/dalvik/art.html
.DEX - http://source.android.com/devices/tech/dalvik/dex-format.html
Dalvaik - http://source.android.com/devices/tech/dalvik/index.html
ADB - http://developer.android.com/tools/help/adb.html
Logcat - http://developer.android.com/tools/help/logcat.html
[ ^ Perfect]
Other suggestions
At the end of the Dalvaik section you might add a sentence that says "see ART" [good idea]
Maybe a mention about XPosed framewor http://cdn3.xda-developers.com/images/editor/color.gifk since it is very prevalent now. [will be done]
In the definition of ROM it might be nice toexplain a ROM image [ok]
This is something I cannot find: What exactly does AOSPA(+) mean? Alternative? [ I thinck so since it's mostly related do paranoid android rom]
Kernel is alphabetically in the wrong position in the list.[Yeah,kernel is drunk,gonna slap him on the face and move to his place]
Explanation for the term MOD / Modification.
Add cool Android KitKat and Jelly Bean history link http://www.android.com/kitkat/ [wrong link]
:good: Thanks for the nice list.
Click to expand...
Click to collapse
@Fedroid
OTG missing?
Click to expand...
Click to collapse
how could i forget? will be added. thanks
Nice info.I will add it into my bookmark. :good:
Great post thank you.
I suggest, the add of GPE definition : "Google Play Edition". Especially in the case of Moto G
Was not so obvious to me until I google it.
Another term that might be good to add is AWS since it is a unique factor between Moto G models.
AWS: Advanced Wireless Services in terms of the Moto G is the 3G UHF Frequency of 1700 MHz - 2100 MHz "T-Mobile"
Author: Apriorit (Research and Reverse Engineering Team)
Permanent link: www(dot)apriorit(dot)com/dev-blog/76-reversing-of-mobile-phones-insertions
Once we faced the need to investigate how Samsung cellular phones work; we required some information from them, which is not documented (and will never be, for sure). So this article is about interesting points our reverser had met while working with Samsung cellular phones firmware.
Reversing of Insertions for ARM-based Mobile Phones
I have managed to research insertions of all Samsung' generations, including CDMA (except for the smartphones only). In every Samsung phone the ARM-compatible processor with a set of ARM7TDMI commands is used. Insertions are built on the basis of three OS: RTCX, RTK, Nucleus, and compiled on different compilers. I have seen insertions compiled on ADS (SDT) and IAR.
On forums people call Samsung's generations in different way: somebody divides them into Gumi/Suvon (2 cities in Korea), others give code names - "Sysol", "Agere", "VLSI", "Conexant" and "Ancient". I have come to a conclusion that it's more correctly to divide them according to the phone processor.
Processor Models
OM6357 (aka Sysol) E100, E700, E720, E800, E820, S50x, X100, X460, X60x
M46 (aka Conexant) A100, A110, A200, A300, A400, M100, T208
SkyWorks (aka Conexant) C100, C108, C110, P510, P518
ONE-C (aka VLSI) R2XX, Nxxx, Txxx(except for T208)
Trident (aka Agere) Dxxx, Qxxx, Sxxx(except for S50x), Vxxx, C200, E105, E310, E400, E600, E710, E810, X105, X400, X42x, X450 etc.
MSMxxxx all CDMA
Hope, I haven't made any mistakes in this list. )
According to the list, insertions within the same generation are very similar and, to be honest, sometimes they are twins at all (with extremely slight changes). For example, in X100 there are obvious traces of E100/E700/X600 - why then there is a code for working with the second display, camera and IRDA, which it didn't have in a whole life?
Naturally, OS is the same for the whole generation:
OM6357 - RTK
M46 - RTCX OSE
SkyWorks - RTCX OSE
ONE-C - RTK
Trident - Nucleus
MSMxxxx - don't know exactly, it might be any OS from Qualcomm. It's just clear that they are collected to ADS/SDT.
If you are going to investigate the low level, then SDK from corresponding OS will be to the point. Another helpful thing is the symbolical information, which can be met in some insertions archives. Sometimes you can come across the insertions with .lst, .sym, .map, .out files, containing the information, extremely useful in researches. In particular, such files occur in almost all C100, S500 insertions. When talking about the other models, the situation is worse and you have to content yourself with symbols signatures, made for insertion of the same generation. For example, for M46 I have managed to find just one insertion with symbols and it was from A110. But signatures made from it perfectly lie down on A200, A300 etc.
Interpretation of the symbolical information
MAP format
.map files contain the information on modules included in the insertion and look like
Code:
Base Size Type RO? Name
0 20 CODE RO AAA_vectors from object file obj/isr.o
20 38e8 CODE RO C$$code from object file../../src/t9latin.o
3908 30 CODE RO C$$code from object file obj/mmi_date.o
3938 5a4 CODE RO C$$code from object file hw_slow.o
3edc 874 CODE RO C$$code from object file rtkgo.o
etc.
where
Base - displacement in an insertion file.
Size - length.
Type - region type.
RO? - region access type.
Name - original file name, part of which was included in the insertion
How all this can be interpreted? For example, this way: starting with displacement 20, there is a block of the code (CODE) 38e8 length - it's an access to Read Only block. The fact that block has CODE attribute is far from being means that the WHOLE area is filled with a code. Actually, it is a code plus data, just as if the block has DATA type it does not mean that it is necessary to make it all by data in IDA.
Without the names/symbols file this information can be used only for determination of insertion code size (i.e. to not get into the graphics). Therefore, we will better examine SYM format.
SYM Format
.sym files are the mines of information. They look like:
Code:
Symbol Table
AAA_vectors$$Base 000000
AAA_vectors$$Limit 000020
VectorMap$$Base 1006a3c
VectorMap$$Limit 1006a60
isr$$Base 12774c
isr$$Limit 127bb0
gl_MaskIT 1000078
Rtk_RegionCount 100564c
rtk_WorthItSched 10056a0
Rtk11_Schedule 11f5c8
etc.
It is a little bit easier here, because the name-address correspondence exists. But as for the addresses, there are some secrets - a set of names exists, containing $ sign and having the special status. Symbols with $$Base at the end indicate the beginning of virtual address space area, $$Limit indicates the end. I.e. here we have the information on segments. It is possible to make a memory map of these segments and see how the parts of binary code are being thrown to different addresses. Building memory map should be started with such symbols:
Code:
Image$$RO$$Base 000000
Image$$RO$$Limit 1afef4
Image$$RW$$Base 1000000
Image$$RW$$Limit 107dad4
Image$$ZI$$Base 1006a60
Image$$ZI$$Limit 107dad4
RO - Read Only, indicates code addresses.
RW - Read/Write i.e. it is RAM.
ZI - Zero Initialized. RAM, which is being stuffed with zero values when mobile phone is turned on.
Thus segments can be easily created on these addresses. Now we look further:
Code:
AAA_vectors$$Base 000000
AAA_vectors$$Limit 000020
C$$code$$Base 000020
C$$code$$Limit 127310
C$$code$$__call_via$$Base 127310
C$$code$$__call_via$$Limit 127320
Example$$Base 127320
Example$$Limit 127324
HAL_boot$$Base 127324
HAL_boot$$Limit 12735c
RtkCode$$Base 12735c
RtkCode$$Limit 127408
SysSupportCode$$Base 127408
SysSupportCode$$Limit 12744c
boot$$Base 12744c
boot$$Limit 127654
clib$$Base 127654
clib$$Limit 12774c
isr$$Base 12774c
isr$$Limit 127bb0
C$$constdata$$Base 127bb0
C$$constdata$$Limit 1afef4
C$$data$$Base 1000000
C$$data$$Limit 1005a38
Stacks$$Base 1005a38
Stacks$$Limit 1006a3c
VectorMap$$Base 1006a3c
VectorMap$$Limit 1006a60
C$$zidata$$Base 1006a60
C$$zidata$$Limit 107dad4
In this interesting way they go one after another. If you wish, it is possible to divide them into segments to corresponding addresses, but this is merely a logic division. Moreover, in .sym file these lines are scattered badly. And more sooner or later a question appears: why the code size is 1afef4, if length of insertion file is 1b6950? Where to put the rest 6a60 byte? We look again on the initial memory map:
Code:
Image$$RW$$Base 1000000
Image$$RW$$Limit 107dad4
Image$$ZI$$Base 1006a60
Image$$ZI$$Limit 107dad4
RAM ends on 107dad4 address, block 1006a60-107dad4 is zero initialized, hence there is a question: what does initialize the 1000000-1006a60 block, which size is exactly 6a60? Absolutely right, those odd bytes. If analyse the OS start code, then in the RAM initialization procedure you will find the same copying.
In the newer insertions there is a chance to come across the next inscriptions:
Code:
Load$$IRAM$$Base 639a74
Image$$IRAM$$Base 2010000
Image$$IRAM$$Length 0015a4
They should be understood this way: data of 15a4 length are being loaded from 639a74 file displacement to the 2010000 address.
We continue the analysis of symbols with the $ sign:
x$litpool$ - Literal Pool, pieces of the data from functions. At the end of many functions indexes, lines, constants are placed, and x$litpool$ specifies the beginning of such constants.
x$litpool_e$ - Literal Pool end.
$T is merely for debugger. Indicates the addresses where the PC register change take place. So, at these addresses transition commands BL/BEQ/B/BX etc. are placed.
$$- addresses where there is a change of ARM/THUMB state.
There are also C$$code symbols, but I haven't found what it is.
Other names without $ sign are the names for constants and functions. They can be freely used.
If the archive with an insertion contains both MAP and SYM, it is an ideal variant - when you set a name taken from SYM it is possible to check up whether it lays in the code area by using data from MAP. If yes, we may freely indicate it as code not being afraid, that code/data will be determined in IDA incorrectly.
LST Format
It's a real paradise for a reverser, in these files lays all at once. They consist of five parts:
Image Symbol Table - symbols... their meaning I have not understood yet
Local Symbols - everything is clear from the name
Global Symbols - .sym file analogue.
Memory Map of the image - memory map! All at once!
Image component sizes - .map file analogue
The information is so detailed, that even the processor mode for each function is specified.
OUT Format
Have met it only in the Nucleus-based insertions. Here can be tlink.out and tsymb.out files:
tsymb.out - ordinary SYM
think.out - MAP file to which almost useless linker information is added.
Now when we are armed with the symbolical information we can load the insertion in IDA.
What to do if there are no symbols at all
"When there is no toothbrush at hand..." Yes, we take IDA, emulating debuggerand brains in the hands. IDA is "must have". The emulating debugger for ARM, called Trace32, can be taken here.
First of all, we load the insertion in IDA to 0 address. I.e. the whole insertion is being loaded to default addresses. Then look what is on 0 address.
Code:
BOOT:00000000 B ResetHandler
BOOT:00000004 B loc_3B4
BOOT:00000008 B loc_410
BOOT:0000000C B loc_42C
BOOT:00000010 B loc_488
etc.
The code in any case begins with 0 address. In all Samsungs and, as I guess, not only in Samsungs an insertion begins with the interruption vectors. These are eight B commands in ARM state, i.e. 8 vectors. 0 address is a vector of null interruption or insertion start/restart. This zero interruption simply starts the mobile phone and thus handler leads to the system loader:
Code:
BOOT:00000048 ResetHandler; CODE XREF: BOOT:loc_0 _ j
BOOT:00000048 MRS R0,CPSR
BOOT:0000004C BIC R0,R0,#0x1F
BOOT:00000050 ORR R0,R0,#0x13
BOOT:00000054 ORR R0,R0,#0xC0
BOOT:00000058 MSR CPSR_cxsf,R0
BOOT:0000005C LDR R3,=(InitialHWConfig+1)
BOOT:00000060 MOV LR,PC
BOOT:00000064 BX R3
If the jump from zero address goes to the non-existent address it means that the rest part of the code is mapped to some other addresses. It's easy to determine to which exactly. For example, we have such beginning:
Code:
BOOT:00000000 B 0x4003CE
And there is no code on the 4003CE address. We look on 3CE displacement and see an ARM-code. It means the rest part of insertion is displaced on 0x400000. So we have to copy piece of insertion with interruption handlers, load them to zero address and then load an insertion from 400000 address. Now our code is in the right place. We go further. It is necessary to find out where are the RAM and area of input/output ports. The ports are usually either in the end (addresses from about e0000000 and higher) or in the beginning of the memory (up to 0x200000), depending on where the insertion is being loaded. There can be several RAM areas. First of all, we see ports initialization:
Code:
BOOT:00000588 MOV R1,#1
BOOT:0000058A LDR R0,=0xE0006000
BOOT:0000058C LSL R1,R1,#0x1B
BOOT:0000058E STR R1,[R0]
BOOT:00000590 STR R1,[R0,#0x10]
BOOT:00000592 STR R1,[R0,#0x20]
BOOT:00000594 LDR R1,=loc_20102
BOOT:00000596 LDR R0,=0xE0003040
BOOT:00000598 STR R1,[R0, #4]
BOOT:0000059A LDR R1,=0x20003
BOOT:0000059C STR R1,[R0, #8]
BOOT:0000059E LDR R0,=0xE0003000
BOOT:000005A0 MOV R1,#0xC
BOOT:000005A2 STR R1,[R0,#0x24]
I.e. since around E0000000 there is an area of input/output ports. Its size doesn't exceed the size of segment and therefore it's possible to create a segment of 0x10000 size. Now we go further. In any insertion there are RAM area which is initialized by zero values and the area which is filled by initial settings which are taken from an insertion. We are looking for copy cycles, so we need the debugger.
Here we see copying:
Code:
BOOT:000000D4 LDR R0,=0x63B018
BOOT:000000D8 LDR R1,=0x1000000
BOOT:000000DC LDR R3,=0x1045B38
BOOT:000000E0 CMP R1,R3
BOOT:000000E4 BEQ loc_F8
BOOT:000000E8
BOOT:000000E8 loc_E8; CODE XREF: BOOT:000000F4 _ j
BOOT:000000E8 CMP R1,R3
BOOT:000000EC LDRCC R2,[R0],#4
BOOT:000000F0 STRCC R2,[R1],#4
BOOT:000000F4 BCC loc_E8
The block is being copied from 63B018 address to 1000000 address of insertion. The length is 45B38.
This is the first RAM area. Now we look for the second one, whose zero initialization should be nearby:
Code:
BOOT:000000F8 LDR R1,=0x11ED9E4
BOOT:000000FC MOV R2,#0
BOOT:00000100 CMP R3,R1
BOOT:00000104
BOOT:00000104 loc_104; BOOT:00000108 _ j
BOOT:00000104
BOOT:00000104 STRCC R2,[R3],#4
BOOT:00000108 BCC loc_100
Indeed, there is a stuffing with zero values in the area from 1045B38 to 11ED9E4, so here we have the second part. If there are any areas, then there will certainly be zero or copy initialization. Other memory pieces can be found only analytically, but we have got the basis already.
The further research depends on the presence of symbols/signatures. If yes, then everything comes to looking for the necessary function in the names list. What to do if not? First of all, it is necessary to determine approximate code bounds and, if possible, to find functions in the code. The most primitive and effective way is to search for a push command with which 60 % of insertion code begins. Insertion code usually consists of Thumb code on 90 %, so we should look for B5 byte (push) and try to define it as the code in IDA. Insertion code usually takes less than 50 % of the whole size, the rest part is for graphics and language resources. Else I can say that very often at the end of the code there are copyrights lines, a kind of "Samsung corp. 199x-200x ARM ADS 1.2".
Some code has been revealed, around 20% were harmed by IDA itself, because it often can't cope with THUMB/ARM transition. And now we have to take anything left lying around loose, i.e. what had been left by programmers. And what they had left? Trace and Assert. And any trace and assert doesn't go without sprintf/printf. We have to find it. It's easy - we should just look for the "%s" line. We need that which obviously contains a pattern of the error message. With xref we find where this line is used and it will be exactly sprintf, followed by Trace or Assert. Now, with basing on the error messages, we can name the functions. I.e. walking with xref to the Trace/Assert function, we can find output of more than half of mistakes. Further functions naming is possible by searching the following words:
Code:
Bad
Fail
Incorrect
Invalid
Error
Memory
File
Null
No
Critical
Abnormal
etc.
This way we will find some more error output functions. Thus we will gradually gain the information, not being based on anything except for the insertion.