We destroy myths about Android optimization methods ... - Android General

{
"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"
}
Wandering through the forums and various websites dedicated to Android, we are constantly confronted with tips on how to increase the performance of the smartphone. Some recommend to include swap, others - add special value to build.prop, and others - to change variables of the Linux kernel. Such recipes in different ways you can find a huge amount of that on the XDA and 4PDA. But do they actually work
Tenacity with which some seemingly competent smartphone users are trying to push their ideas public optimum adjustment Android and the underlying Linux kernel. And the right to it was limited to a slight tuning virtual memory management subsystem, or the inclusion of experimental options. No, we usually offer a very long use scripts that change literally every variable core, remount filesystems with different odd options, including the swap, activate various system daemons and perform billions of different operations.
No, well, you can, of course, assume that the Linux kernel, Android and proprietary firmware for smartphones develop illiterate idiots, whose work must be radically alter, but in practice some reason it turns out that the most famous tuning tools, published on XDA, - it nothing but a hodgepodge of disparate huge number of recommendations, it is not clear who invented and no one knows why. The absurdity of the situation reaches that these instruments can be found rows copied unchanged from the scripts to increase Linux-server performance under heavy loads (I'm not kidding, look at the contents of the famous script ThunderBolt!).
In general, the situation is more complicated than. All advise all, no one suggests anything, and those who understand something, sitting and drinking tea and laughing over what's happening.
Swap
Let's start with the swap - the most absurd ideas of all that you can think of for use in smartphones. Its purpose is to create and connect the paging file, thereby manage to free storage space in memory. The idea itself is certainly sensible, but only if it is a server, which rests on the interactivity of nowhere. Using your phone regularly used pagefile will lead to lags arising from slips past the cache - just imagine what will happen if an application tries to display one of their icons, and it will be in the swap, which will have to re-load the disc, after freeing up space by placing data swap another application. Horror.
Some users can be argued that in fact after the swap no problems, but for this we must thank the mechanism lowmemorykiller, which regularly kills very swollen and have not used the application. Thanks to him, the device with 1GB of memory can never reach the necessary performance data in a swap. He is the reason why, in contrast to the Linux-desktop on the Android swap is not needed.
Verdict: A very stupid idea, the implementation of which is fraught with serious lags.
zRAM
The idea is so right that even Google recommends zRAM for KitKat-based devices in the event that the amount of RAM is less than 512 MB. Only snag is that the method only works for modern cost devices based on multi-core processors from the budget any MTK and 512 MB of RAM. In this case, the encryption stream can be taken to separate the kernel and do not care about performance.
On older devices with a single core, and which recommend the use of this technology, we again get the lags, and in fairly large quantities. The same, incidentally, applies to technology KSM (Kernel Same Page Merging), which allows you to combine identical memory pages, thus freeing space. It also recommended that Google, but on older devaysakh leads to an even greater lags, which makes sense, given the constantly active core thread that runs continuously from memory in search of duplicate pages.
Verdict: it depends on the device, in most cases, the system slows down.
Seeder
At the time this application has done a lot of noise and gave rise to many analogues. The network has a huge number of reports of alleged phenomenal growth performance of the smartphone after installation. Homegrown custom firmware collectors have begun to include him in their assembly, and the author was declared a savior. And all this despite the fact that Seeder not doing anything dirty hacks, but just corrected a stupid bug Android.
The bug consisted in the fact that some high-level components of the Android runtime actively used the file /dev/random to get entropy. In some moments buffer /dev/random devastated, and the system is blocked until it is filling the required amount of data. And as he filled that have been reported from various sensors, buttons and sensors of the smartphone, the time for this procedure took so much time to notice that lag.
To solve this problem the author Seeder took Linux-demon rngd, compiled it for Android inastroil so that he took random data from a much faster (but also much more predictable) /dev/urandom, and every second merges them into /dev/random, without allowing the latter exhausted. As a result - the system never experienced a lack of entropy and work quietly.
This bug was closed back in Google Android 3.0, and it would seem, we do not need to think about Seeder. But the fact that the application has since actively developed and even today, is recommended by many "experts" for the application. Moreover, the application has several analogues (eg, sEFix), and many of the creators of the scripts/tools to accelerate still include this functionality in their creations. Sometimes it is the same rngd, sometimes - the demon haveged, sometimes just symlink /dev/urandom on /dev/random.
Everyone who tried it, excitedly shouting about the effectiveness of the solution, however, according to Ricardo Cerqueira from the company Cyanogen, in newer versions of Android /dev/random is used in all three components: libcrypto (encryption SSL-connections, generating SSH keys and etc.), wpa_supplicant/hostapd (to generate the WEP/WPA-keys) and several libraries for generating random ID to create ext2/3/4 filesystems.
Application Efficiency in today's Android, in his opinion, is not connected with the completion of the pool /dev/random, and that rngd constantly awakens the device and causes it to increase the frequency of the processor, which has a positive effect on performance and negative on the battery.
Verdict: The placebo effect.
Odex
Stock firmware smartphones always odex. This means that along with the standard package for Android apps in APK format directory /system/app/ and /system/priv-app/ (since KitKat) are also of the same name files with the extension odex. They contain so-called optimized bytecode applications already passed through the validator and optimizer virtual machine and recorded in a separate file (this is done using dexopt utility).
Meaning odex files to offload virtual machine and thus speed up the launch of the application (runoff). On the other hand, ODEX files to prevent modifications to make to the firmware, create problems with the update, and for this reason many custom ROMs (including CyanogenMod) distributed without them. Return (or rather, generate) files odex a variety of ways, including using simple tools/scripts like Odexer Tool. Using them is easy, and many of the "experts" are advised to do so.
The only problem is that this is purely a placebo. Not finding odex-files in the directory/system, the system itself will create them the next loaded and placed in the directory /system/dalvik-cache/. This is what she does when loading a new firmware on the screen the message "Busy ... Optimizing Applications." In relation to applications from the convenience store is also, incidentally, works. But at the stage of installation of the software.
Verdict: The placebo effect.
Lowmemorykiller tweaks
The implementation of multitasking in Android is very different from other mobile operating systems and is based on the classical model. Applications can work quietly in the background, in the system there are no restrictions on the number, the functionality of the transition to a background execution is not curtailed. All as on the desktop, except for one detail: the system has every right to kill any background application in the case of lack of memory, or (since KitKat) excessive greed application resources.
This mechanism, called lowmemorykiller, was coined to, retaining features of a full-fledged multi-tasking OS, Android could live normally in a limited amount of memory and lack of swap-partition. The user can easily launch any application and quickly switch between them, and the system will take care of the long-unused application completion and to always remain free memory in the device.
In the early days of Android purpose of this mechanism for many users it was unclear why have become popular so-called task-killer - apps that from time to time to wake up and have completed all background applications. Profits in this case, it was considered a large amount of free RAM, which was perceived as a plus, though no advantages in this, of course, was not. But there were many disadvantages in the form of a longer switch between applications, increased battery consumption and problems c awakening in the morning the owner (Service also kills).
Over time, multitasking principles of understanding has come, and from task-killers gradually abandoned. However, they were quickly replaced by another trend - tuning of lowmemorykiller mechanism (for example, by MinFreeManager applications). The main idea of ​​the method is to lift the boundaries of filling the RAM at which the system will start to kill background apps. A sort of the way ", and us and you", which allows you to free up some memory by regular means, without disturbing ideas Android multitasking.
But what it ultimately leads? For example, the standard value memory is full of borders - a 4, 8, 12, 24, 32 and 40 Mb, that is when the free storage space of 40 MB will be killed by one of the cached applications (loaded in memory, but is not running, is this optimization Android ), with 32 - Content Provider, has no customers, 24 - one of the seldom-used back-end application, then go to the expense of service processes application (for example, the music player service), visible on the app screen and the current running application. The difference between the last two is that the "current" - this application, which is currently dealing the user, and the "visible" - is that, for example, has a notification in the status bar or display on top of the screen any information.
In general, all this means that the smartphone will always be available 40 MB of memory, which is enough to accommodate another application, and then start LKM flow and begin cleanup. All OK, everyone is happy. The system uses the maximum memory. Now imagine what would happen if the user take advantage of advice homebrew "expert", and raise these values ​​so that the latter would be, well, let's say, 100 MB (usually raised only the last three values). In this case, it happens one simple thing: the user will lose 100 - 40 = 60 MB of memory. Instead of using this space to store back-end applications, it is useful, as it reduces the time to switch to them, and the charge of the battery, the system will keep it free is not clear why.
It is fair to say that the LKM tuning can be useful for devices with very very little memory (less than 512) and Android 4.X on board, or to temporarily increase thresholds. Some developers tweaks directly recommend the use of "aggressive" setting only if you run heavy software like hi-end games, and all the rest of the time to stay on the standard. This really makes sense.
Verdict: better not to touch.
I/O tweaks
The scripts that are published on the forums, you can often find tweaks I/O subsystem. For example, in the same script ThunderBolt! has the following lines:
Code:
echo 0 > $i/queue/rotational;
echo 1024 > $i/queue/nr_requests;
The first gives the I/O scheduler to understand that he is dealing with a solid state drive, the second increases the maximum size of the queue IO 128 to 1024 ($i variable in commands contains a path to the tree of block device in /sys, eg /sys/block/mmcblk0/, the script runs on them in the loop). Hereinafter you can find the following line relating to the CFQ scheduler:
Code:
echo 1 > $i/queue/iosched/back_seek_penalty;
echo 1 > $i/queue/iosched/low_latency;
echo 1 > $i/queue/iosched/slice_idle;
This is followed by a few more lines belonging to other planners (by the way, pay attention to a whole extra semicolon at the end of instruction). What all of these lines is not so? The first two commands are pointless for two reasons:
1. Schedulers I / O in a modern Linux kernel itself able to understand what type of storage medium they deal.
2. Such a long input-output queue (1024) completely useless on a smartphone. Moreover, it is meaningless, even on the desktop and is used on heavy duty servers (of tuning recommendations which it, apparently, and got into the script).
The last three are meaningless for the simple reason that for a smartphone, where there is virtually no separation applications prioritized in the input-output and there is no mechanical drive, the best planner - is the noop, that is simple the FIFO-queue - who first turned to memory, he also got access. And this scheduler is not any special settings. Therefore, all these multi-screen lists commands better replaced by a simple cycle:
Code:
for i in /sys/block/mmc*; do
echo noop > $i/queue/scheduler
echo 0 > $i/queue/iostats
done
In addition to enabling noop scheduler for all drives it off the accumulation of statistics I/O, which should also have a positive impact on the performance (although this is only a drop in the sea, which will be completely invisible).
Another tweak that can often be found in the scripts tuning performance - this increase readahead values ​​for memory cards up to 2 MB. readahead mechanism for early reading data from the media even before the application requests access to these data. If the kernel sees that someone long enough to read the data from the media, it is trying to figure out what data will be needed in the future application and pre-loads them into RAM, thereby enabling to reduce the time of their return.
It sounds cool, but, as practice shows, readahead algorithm is very often wrong, which leads to unnecessary operations of input-output and consumption of RAM. High values ​​readahead (1-8 MB) are recommended for use in RAID-arrays, whereas on the desktop or smartphone is better to leave everything as is, that is 128 KB.
Verdict: in addition to noop, do not need anything.
Tweaks virtual memory management system
In addition to the subsystem I/O, it is also common to do tuning virtual memory management subsystem. Often, change affects only two kernel variables: vm.dirty_background_ratio and vm.dirty_ratio, which allow you to adjust the size of the buffer for storing the so-called dirty data, ie the data that has been written to disk application, but more are still in memory and waiting until they are written to disk.
Typical values ​​of these variables in the desktop Linux-distributions and Android are as follows:
Code:
* vm.dirty_background_ratio = 10
* vm.dirty_ratio = 20
This means that when the "dirty" data buffer size in 10% of the total amount of RAM wake pdflush nuclear flow and starts to write data to disk. If the operation of recording data on the disk will be too intense and even though the job pdflush, the buffer will continue to grow, then when it reaches 20% of the amount of RAM the system switches all the subsequent write operation in synchronous mode (without pre-buffer) and the work of writing to disk application will be blocked until such time as the data is written to disk (in the terminology of Android is called a lag).
It is important to understand that even if the buffer size is not reached 10%, the system anyway pdflush starts the flow after 30 seconds. What we are given this knowledge? In fact, anything that we could use for their own purposes. The combination of 10/20% is quite reasonable, for example, on your smartphone with 1 GB of RAM is about 100/200 MB of memory, which is more than enough in terms of rare bursts records that speed is often below the speed record in system NAND-memory, or SD-card (when installing software or copying files from a computer). But the creators of scripts optimization with this, of course, disagree.
For example, in Xplix script can find something like this (in the original, they are much longer because of the checks on the amount of RAM and use BusyBox):
Code:
sysctl -w vm.dirty_background_ratio=50
sysctl -w vm.dirty_ratio=90
These commands apply to devices with 1 GB of memory, that is, set limits on "dirty" buffer equal to (approximately) 500/900 MB. These high values ​​are absolutely meaningless for the smartphone, as only work under constant intense recording on the disc, that is, besides for heavy server. In a situation with a smartphone they are no better than the standard. By the way, in the script ThunderBolt! used much more reasonable (and close to the standard) values, but I doubt that by their application the user will notice at least some difference:
Code:
if [ "$mem" -lt 524288 ];then
sysctl -w vm.dirty_background_ratio=15;
sysctl -w vm.dirty_ratio=30;
elif [ "$mem" -lt 1049776 ];then
sysctl -w vm.dirty_background_ratio=10;
sysctl -w vm.dirty_ratio=20;
else
sysctl -w vm.dirty_background_ratio=5;
sysctl -w vm.dirty_ratio=10;
fi;
The first two commands are run on smartphones with 512 MB of RAM, the second - with 1 GB, and others - with more than 1 GB. But in fact there is only one reason to change the default settings - a device with a very slow internal memory or memory card. In this case it is reasonable to spread the values ​​of the variables, that is, to make something like this:
Code:
sysctl -w vm.dirty_background_ratio=10
sysctl -w vm.dirty_ratio=60
Then, when a surge system write operations, without having to record data on the disc, up to the last will not switch to synchronous mode, which will allow applications to reduce lag when recording.
Verdict: better not to touch.
P.S.
There are numerous and smaller optimizations, including the "tuning" of the network stack, changing the variables of the Linux kernel and Android (build.prop), but 90% of them have no effect on the real performance of the device, while the remaining 10% or improve some aspects of behavior devices at the expense of others, or so insignificant increase productivity, you do not even notice it. From what really works, we can note the following:
****Acceleration. The small acceleration to improve performance and andervolting - save a little battery.
****Database Optimization. I seriously doubt that this will give a noticeable increase in speed, but the theory tells us that the work should be.
****Zipalign. Ironically, despite the built-in Android SDK feature content alignment within the APK-file in the store you can find a lot of software is not transmitted through zipalign.
****Disable unnecessary system services, removing unused system and seldom-used third-party applications.
****Custom kernel with optimizations for a specific device (again, not all nuclei are equally good).
****Already described I/O scheduler noop.
****Saturation algorithm TCP westwood +. There is evidence that he is in wireless networks more efficiently used in the default Android Cubic. Available in custom kernels.
Useless settings build.prop
LaraCraft304 from XDA Developers forum has conducted a study and found that an impressive number of /system/build.prop settings that are recommended for use "experts" do not exist in the source AOSP and CyanogenMod. Here's the list:
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-bytecode
debug.performance.tuning
video.accelerate.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
ersist.sys.shutdown.mode
ro.HOME_APP_ADJ
To be continued...

thanks man!
this helped me understand some things

"No, well, you can, of course, assume that the Linux kernel, Android and proprietary firmware for smartphones develop illiterate idiots, whose work must be radically alter"
this made me lol

This...
Was...
AWESOME!
Pure information furthermore useful bits and pieces. Sorry for the necro but I just felt plain wrong to tap a button to say thanks. I really felt like I'd be the minimum to write thanks personally. Thank you very much for this post.

I swear to you windowsmgr.max_events_per_sec works flawlessly, the higher number, the more content will be able to load on launcher without lag. I used to test it on my J7 pro android 8.0

I subscribe the OP's statements that we are constantly are searching for optimization(s) of our Android device. I used all kind of Android devices, like Sony, Oppo, etc for many years with varying satisfaction, also regarding Android updates. I know that what I'm going to say now, is very sensitive in the Android community, but nevertheless I will post it. After having used Fitbit as my fitness trackers/smartwatches, I noticed the release of the Apple iWatch 6 and I was stunned about the capabilities of this watch versus all other smarwatches. Alas I needed also an iPhone to get it up and running. Let me be clear, I never was an Apple fan due to it's too strict policy and the fact that you were not able to make your own homescreen. But, since the release of iOS 14 this all changed, so I decided to get over my Apple resistance and bought the Apple 12 Pro Max. Using this now for a few months, this is the best upgrade I ever made. Everything runs smooth, fast, lot's of space, smooth connection with the iWatch, etc etc. I designed my own home display even on an Apple device (see attachment). Looks exactly the same as the home display I had on all of my former Android devices. Hope this information is in some way helpfull for you all. Kindest regards kuzibri
P.S. If you've got interested in more information about the Apple 12, see my threads in the Apple fora of XDA:
1. https://forum.xda-developers.com/t/q-a-template-for-the-apple-iphone-12-pro-max.4322579/
2. https://forum.xda-developers.com/t/ask-away-thread-for-all-apple-iphones.4323471/

Related

HTC Performance - Fact Or Fiction The True Story...

Ok, I've seen numerous questions about the app called HTC Performance & have disassembled the executable. While my knowledge of these thing is by no means great, I have found some very interesting functions.
Maybe someone with more reverse engineering & code experience can take a look, but with IDA Pro there are some very interesting functions & strings.
Some of the calls & code are deprecated & no longer used in WM6 + but some of them are.
It is possible, especially for evB equiped roms, that this prgram acts like a server of sorts for some programs & processes. But being as it is initiated with Smartphone only functions I doubt it.
some of the more interesting functions in the HTC Performance app are:
SHInitExtraControls Which appears to be for Smartphone only
GetSystemMetrics WM6 Pro valid - Gets System Width & Heigth in pixels. Posible uses include program optimization based on the appropriate pixel returns
CreateMutexW - coredll - used to connect to core via net cf for obtaining device info- Usually eVB related apps use to call coredll info
memmove = takes more memory than memcpy but may be used to ensure unicode strings not used on odd memory addresses, this could increase speed on apps that incorrectly do this.
InterlockedCompareExchange, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd, and InterlockedIncrement = functions provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. The threads of different processes can use this mechanism if the variable is in shared memory.
InterlockedCompareExchange = function performs an atomic comparison of the Destination value with the Comperand value. If the Destination value is equal to the Comperand value, the Exchange value is stored in the address specified by Destination. Otherwise, no operation is performed
YAXPAX = can speed up access of written C++ Code
ReleaseMutex = Mutex functions are used to release shared functions
EnumWindows = (..) to execute a task. EnumWindows (..) enumerates through all existing windows (visible or not) and provides a handle to all of the currently open top-level windows. Each time a window is located, the function calls the delegate (named IECallBack) which in turn calls the EnumWindowCallBack (..) function and passes the window handle to it. Not sure howthis is used though.
LoadAcceleratorsW = ??? Appears to be old CE function. Deprecated???
realloc = String Optimization
malloc = RAM Allocation
GetDeviceCaps = gets dev info, can be used to the optimize redraw based on device constraints already known
LocalReAlloc = This function changes the size or the attributes of a specified local memory object. The size can increase or decrease.
EnterCriticalSection = The threads of a single process can use a critical section object for mutual-exclusion synchronization. The process is responsible for allocating the memory used by a critical section object, which it can do by declaring a variable of type CRITICAL_SECTION. can grant exclusive access to memory
ReleaseDC = This function releases a device context (DC), freeing it for use by other applications. The effect of ReleaseDC depends on the type of device context.
Again, I am not a programmer, I know a few things, & am pretty competent with the lower operations of firmware, but the rest of the CE code is not my cup of tea. There are many more functions in HTC Performance. These are only a few functions found after a brief 20 minute peak.
But maybe, maybe, some of the function calls can help us to understand if this app can be moddified to properly function on the Kaiser.
It is possible that on some evB enabled apps, that maybe some of the HTC Performance app are retained & possibly function, that is pure speculation though, & again I doubt it.
Any CE code experts out there wanna take a look? I have, & based on what I've seen, I'll have to say FICTION!
Info
Hi,
Since I haven't really had time to see whats new and all I haven't the foggiest idea what HTC Performance is/what it is supposed to do.
But I can tell you that the functions you listed are not special in any way. Most of them would appear in every application that displays anything on the screen. For instance getting system metrics is required for any application displaying scroll bars, etc. All the interlocked and critical section stuff is just thread synchronization.
But that's OK, the use of windows APIs really doesn't mean much, other than the application runs on Windows...its the non-API stuff that defines an application. If the application you're looking at writes changes to registry keys, etc. you may want to look into that as those would be the lasting changes to the device.
Cheers,
Why is there concurrency related stuff in there? Surely that should all be handled by the operating system, rather than a running application? (That said, most of my concurrency knowledge is either theoretical or based at a high level, so I could be wrong here).
High Performance Cab
You can also check this thread...
http://forum.xda-developers.com/showthread.php?t=366792
Quentin- said:
Hi,
Since I haven't really had time to see whats new and all I haven't the foggiest idea what HTC Performance is/what it is supposed to do.
But I can tell you that the functions you listed are not special in any way. Most of them would appear in every application that displays anything on the screen. For instance getting system metrics is required for any application displaying scroll bars, etc. All the interlocked and critical section stuff is just thread synchronization.
But that's OK, the use of windows APIs really doesn't mean much, other than the application runs on Windows...its the non-API stuff that defines an application. If the application you're looking at writes changes to registry keys, etc. you may want to look into that as those would be the lasting changes to the device.
Cheers,
Click to expand...
Click to collapse
No, registry would not necesarily be the place to look. For this application the registry will only report whether or not the App is running or not. It is supposed to be a speed optimization application. My thought were that it could possibly be acting as a server of sorts, handling some thread optimization & resource allocation. Correct though, most of those API's are importing device info, beyond that, I am lost as to how it handles it, if it does at all. That said, there are many things that don't show up in the registry & many things can't be altered via the registry b'c they are set or handled before initialization or loading of the registry, possibly thru the OAL. Even tougher to say in a two chip device with as little known info as the msm7xxx processors. If anyone with real coding knowledge could take a look at the executable & see just what it's doing with the info, that would be great.
dperren said:
Why is there concurrency related stuff in there? Surely that should all be handled by the operating system, rather than a running application? (That said, most of my concurrency knowledge is either theoretical or based at a high level, so I could be wrong here).
Click to expand...
Click to collapse
That is indeed the center of my question & also what leads me to question how the app functions. Is it playing a role in thread priority optimization, & possibly redraw based on the polls, or is it just a partially gutted application miising a ton of registry data that never worked?

[GUIDE]Complete guide for Galaxy 3 I5800/I5801

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.

KSM, does it really improves performance ?

Well sadly i don't have an answer for that question yet...
I'm trying to think of a way to put KSM to the test on my android device.
As far as i understand it is possible that the kernel actually causes high CPU usage trying to map and unmap memory pages over and over again.
This issue is known for linux and other virtual machines so it is possible that the Same effect will be on the android vm
Testings that i found are not relevant to android.
For example:
The result is a dramatic decrease in memory usage in virtualization environments. In a virtualization server, Red Hat found that thanks to KSM, KVM can run as many as 52 Windows XP VMs with 1 GB of RAM each on a server with just 16 GB of RAM. Because KSM works transparently to userspace apps, it can be adopted very easily, and provides huge memory savings for free to current production systems. It was originally developed for use with KVM, but it can be also used with any other virtualization system - or even in non virtualization workloads, for example applications that for some reason have several processes using lots of memory that could be shared.
Click to expand...
Click to collapse
http://kernelnewbies.org/Linux_2_6_32
What i would really want to know is what would happen if each of these VMs Would run a different application/game/audio/graphics software at the same time ? or what if the same vm will run many different apps ? and also to compare cpu usage with and without KSM
Guess i'll need a tool for that. something like 'iostat' but for memory diagnostic and another tool to see a per process CPU usage but 'top' is not good enough for that.
Any way, the best test should present clear results with precised data.
I'll keep looking for legit way to put it to the test.
If you can think of a way to test KSM with android, please let me know.
This is a technique that relates mostly to processes like virtualisation. For example, when you load 5 windows XP VMs, you'll have a good 10 - 20 services that are practically the same in memory in each VM. Instead of each service using 10mb (ie, 10mb x 5 = 50mb), you only need say 15 or 20mb using KSM. If you use different applications, it is very unlikely that anything would be saved FOR THAT APPLICATION. However, the main elements of a Windows XP System would still be there (drivers, explorer, firewall, logon, search and so on). Means little in one setup, but when you have several VMs it is shown to be a huge advantage. As we know a simple XP install can use 500mb of RAM actively, and this is fairly uniform across instals.
With android, i don't know if there are specific RAM savings to be had. Don't know enough about the inner workings and the sandbox android puts its apps in or how apps interact with system services. Sadly, i can't think of a good way to test it out either, but i'll be keeping an eye on this topic for someone (much) more knowledgeable to come along.
Harbb said:
Sadly, i can't think of a good way to test it out either, but i'll be keeping an eye on this topic for someone (much) more knowledgeable to come along.
Click to expand...
Click to collapse
Enter bedalus, stands there with a vacant expression on his face. Harbb looks disappointed.
kernels ; battery ; ROM ; gov/sched
That entire paragraph was dedicated to you bedalus, we both know that.
Lol
I hope someone can answer this though.
kernels ; battery ; ROM ; gov/sched
Wait for someone............
Sent from my Nexus S using xda premium
KSM does not improve performance on Android just like that - all enabling KSM does, is enable SUPPORT for the Feature but Applications would have to make use of the feature, which they don't.
You can easily verify this like that :
echo 1 > /sys/kernel/mm/ksm/run
<wait and/or run the Applications of your choice>
cat /sys/kernel/mm/ksm/pages_sharing
IF the above shows a value > 0 then you are making use of KSM else it's just available, without anyone using the feature.
Here's an interesting Article that gives a little more insight :
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
By the way, the same is true for ZCACHE. If you really want to make better use of your Memory (RAM) then using ZRAM as a Swapdevice does work (and may often make sense, too).
That all said : There appear to be efforts to make use of KSM http://forum.xda-developers.com/showthread.php?t=1464758 - so things may well change ...
any update on this...?

Android terms and definitions

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

[DEV][APP] waut.ch! - Calibration for Android - version 145

Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this educational gaming metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or find the 8!
waut.ch! does one hope to receive from this?
Well, increasing degrees and amounts of a certain "Je ne sais quoi" or responsiveness from the user interface for a start. Better battery life perhaps. Better quality of life, maybe.
And waut.ch! can only perhaps be described as "A qualified quantification of the placebo effect"
waut.ch! might benefit from this?
In the Android device space:
Designers
Users
Manufacturers
Recyclers
Developers
Compilers
Support personnel
OEMs
The Friendly Neighborhood Nerd/Technician.
“Make the most of yourself....for waut.ch! is all there is of you.” - Ralph Waldo Emerson ( paraphrase )
All along the waut.ch! tower - Bob Dylan
waut.ch! - Sometimes used in some colloquium as "watch!", keen upon reducing the TDP of mobile devices to 1.0 watt!
ARM variants of Android only Donut 1.6+
Please uninstall either Seeder or CrossBreeder prior to using this.
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-t3549967 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
Reboot at convenience liberally or sparingly to reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Havged source code:
https://github.com/Openand-I/haveged
Adhoc Payment URL to support development efforts : https://paypal.me/openand/10
Frappe ( "free-paid" ) same-version to support development efforts : http://waut.ch
Custom haveged source code as used in this piece of software: https://github.com/Openand-I/haveged
=====
Version Name: 59a6333e-9ed9-43f8-8dad-51ed46c17e28
cb.sh: cache pressure - 500
cb_io.sh: read_ahead - 0
cb_io.sh: nr_requests - 0
$ md5sum *.apk
661c30b02b2321300624af98feaa5bad *145-waut.ch.apk
661c30b02b2321300624af98feaa5bad *oi.apk
$ sha256sum *.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *145-waut.ch.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://forum.xda-developers.com/devdb/project/?id=19218#downloads
https://forum.xda-developers.com/android/general/app-waut-ch-calibration-android-version-t3858365
https://github.com/openand-inc/waut.ch/raw/cb0c60025f86a4fdc4778506e97ee80eb1c00b45/oi.apk
https://github.com/openand-inc/waut.ch/raw/master/145-waut.ch.apk
-------------------------
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Note: Please note that the haveged binary in the APK is a static binary and works on both PIE and non-PIE environments. It is also UPX compressed. UPX for Android didn't compile. So UPX for linux was used to compress the executable file. It is an elegant solution as both on disk and in memory space(?) is reduced by 70% per executable. One is welcome to decompress the file using 'upx -d'.
Full source code is provided on Github and build scripts are attached here and on Github.
There is no license required to both install the app or distribute it, both within the developer ROM community or in commercial form. Adhoc payment URL to support development - https://www.paypal.me/openand/10
Again do note that the license to use the APP and source code is free worldwide and irrevocable in full or partial form. All other open source components simply inherit their license. But under no circumstances is any use thereof legally binding or relevant.
--------
Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or get lucky for that matter!
-----
ARM variants of Android only Donut 1.6+ ( should even be compatible with the latest ARM Android 9+ )
Please uninstall either Seeder or CrossBreeder prior to using this. And other "mods" or "tweaks".
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-version-t3858365 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
The app will amongst other maintenance tasks tune sqlite databases regularly and reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Payment URL: https://paypal.me/openand/10
XDAevDB Information
waut.ch!, App for all devices (see above for details)
Contributors
idcrisis
Source Code:
[url]https://github.com/Openand-I/haveged[/URL]
[url]https://github.com/openand-inc/waut.ch[/URL]
[url]https://forum.xda-developers.com/devdb/project/?id=19218#downloads[/URL]
Previous Version Information - 144
305bd30f-0c8a-40d8-baf5-330c68f62d51
Status: Stable
Created 2017-01-01
Last Updated 2020-08-18
$ md5sum *.apk
8ea8e8c132a584767a12e394f7975654 *144-waut.ch.apk
8ea8e8c132a584767a12e394f7975654 *oi.apk
$ sha256sum *.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *144-waut.ch.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://github.com/openand-inc/waut.ch/raw/master/144-waut.ch.apk
https://github.com/openand-inc/waut.ch/raw/f699d3763507ec1f91d82b9ce25c53036b460a9e/oi.apk
-----
Version notes:
haveged: static non upx binary used
cb.sh: lock fixes
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Please support development, simply use https://paypal.me/openand/10 or the payment URL.
Or you can simply buy the "frappe" ( free-paid ) version of the app: http://waut.ch
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Issues:
- superuser - Please disable mount namespace separation in the superuser app ( for optional but recommended mount options ). Also please revisit the app entry inside the superuser app to ensure the waut.ch service can run on boot unattended. One can see the logs on another day to ensure that the scheduler ran correctly in the night.
- Non root users - User Interface can help in clearing the random device. Please try and obtain root to avail of most features
- Some Samsung users - One is also requested to raise a ticket with Samsung who may be running old PE detection rules that flag any compressed EXE.
- x64 users - Reports are that the binaries run on 64 bit as they are static! Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Intel users - User Interface can help in clearing the random device. Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Maintenance scheduler VACCUUMS and INDEXES "ALL" SQLITE databases. Some folks may not like that. But given that they're no WAL mode anyway, it's a bottleneck worth removing safely.
- There is a concerned effort to state that 32-bit ARM Android Go/One < 1 GB RAM devices are all that's required for long term functioning. Higher no issues.
- Please try and use a heap size of 96MB. Attempts have been made to set heap size dynamic but ideally this should be done in the build.
- Please clear cache or factory reset upon issues to gain at least another year of MTTR ( Mean Time To Recovery ) for each device.
Thank you!
License
License concerns:
haveged - inherited - https://github.com/Openand-I/haveged
busybox - inherited - https://github.com/openand-inc/busybox
- Busybox simple extract, possibly edit the .config file in 'vi' and type 'make'
The requisite tools are installed using:
apt-get install gcc-arm-linux-gnueabi
apt-get install libncurses5-dev
apt-get install gawk
The following is a step in another direction as the 'make' command works perfectly after extraction, but this is provided for posterity:
wget http://busybox.net/downloads/busybox-1.24.1.tar.bz2
tar -xjf busybox-1.24.1.tar.bz2
cd busybox-1.24.1/
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
At the menu, you can configure BusyBox options. Once configured, you can build BusyBox:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
sqlite3 - inherited - https://github.com/openand-inc/sqlite
waut.ch - 'none', non legally binding, and non legally relevant on a worldwide scale and irrevocable ( derived works are allowed to add their own licenses as long as the import ( meaning ) of the phrase "non legally binding and non legally relevant" is implied throughout ( not required to include text at all )) and does not reflect upon future updates of this software in any manner adversely.
He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk
qWantUS said:
He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk
Click to expand...
Click to collapse
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.
idcrisis said:
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.
Click to expand...
Click to collapse
Very comprehensive explanation indeed! I am no expert in Linux, only an average user [emoji6]
I was not aware of so many obstacles using dnasmasq, but aware of it's unreliability while using it for blocking stuff in pfsense. But I must say, I had similar experience with unbound, however, probably due to the lack of linux knowledge.
The way I understand is that host blocking is no longer viable due to scales of blocking required today. But sadly there is no alternative for that on android. I have been trying another tool, called sharkmasq but developer sadly abandoned it, while it seems very unfinished and unreliable. I also understand the reasons behind leaving netfiltering out of your development, just, in desperation, I search for the hope [emoji3]
P. S.
Thank you very much for your reply and for your time putting it together. Nevertheless I will look forward to further developments of this new exciting project!
Sent from my LG-D855 using Tapatalk
Uhm, my device seems more responsive even when I use a very low CPU frequency, but is it normal that the app doesn't ask for root permission even if I'm fully rooted? I'm using a Nexus 5 running Nougat. Thank you
Inviato dal mio Nexus 5 con Tapatalk 2
Hi, yes, part of the design criteria. Without root, the metric is interesting. With root, it will automatically start the background processes including the daily cleanups.
Best way to know that the background processes are running is to install Seeder ( but whatever you do don't start it! . Entropy should show around 4096.
Still in the testing phase, does it worth excluding the app from "android optimisation list"? I also use "power nap", not sure will that cause any side effects...
Sent from my LG-D855 using Tapatalk
Let us know If Seeder has RNGD off and still reports ~ 4096 entropy then all is hunky dory.
The new update asked me for root permission, all right here now
Have been busy lately with life, but had occasionally played with phone. So my findings so far: I use this app on my old galaxy tab 2 3g on slim6. Seeder shows entropy being filled in no time at all. Can't really say much about performance, but it seems that it behaves a little smoother. I also use it on my daily LG G3 on stock MM rom with custom kernel, but seeder is reporting very low entropy, if seeded is left on for 1 minute, I can see that entropy never goes above 900? Goes up slowly but then gets used, and then very slowly goes up again and gets used.
Sent from my LG-D855 using Tapatalk
Reboot once after first install kicks in the animation changes. And good luck
New version uploaded with haveged updates. Build scripts also added.
Feedback solicited about the compiler flags etc. Basically the idea is that the ARM v5 binaries should work for all past and future versions of 32-bit Android without modification.
UPX binary could only be compiled for x86 linux.
To answer question, second device, not running, may need to check su logs
Also backend binaries are 32 bit, may not work on 64 bit. GUI's ok.
I am very confused about the frontend of this app that looks like some number game that I really don't understand . Also, I don't understand the description very well. Finding the 8??? Reboot when animation kicks in? What animation?? Nothing seems to happen. I just see a still of a beach with a red number
But something DID happen though, so I am in business. I will keep you curious for a moment, while firstly giving you a good reason for a hard laugh:
I am trying to revive an LG L3 E400! Yep, that's right . Just for fun and educion. In fact I already succeeded quite a bit. I flashed JellyCast V7rev1, used some stuff from V6 SuperCharger (not entropy thingie coz I already intended to use CrossBreeder for that) and 3 scripts from Fly-On Mod. I came here via the CrossBreeder thread (of course). I have already tried CrossBreeder 7.2.13 (I followed advise from @f3tus here, he advised to use that older version). Entropy went up (so it worked) but I did not experience much performance improvement. I did experience more "not responding" issues though. So I reverted to the pre-CrossBreeder backup. And then came your app.....
So that's a very short summary of the many, many, many hours I spent last 2 weeks on this ancient minimalistic but very adorable phone. Now... back to this Waut.ch! app. Presuming that it had done something, I checked the entropy level after first reboot: still a jumpy number between 150 and 200 or so. Despite the fact that the service shows up as running. Then, a lot more playing with the "game" without understanding what I was doing. Just hoping for some wonder. Some message.... just...... something! But nothing. Just a beach with a red number. And a clock. And a questionmark. Or exclamation mark. Pffffff.. So.... let's reboot again. Then eat a sandwich and drink (more) coffee. Then check entropy again. And there it is! Steady at 4089! At first I thought his app was failing because the number didn't change anymore. Just steady. With the old CrossBreeder 7.2.13 I got 4096 a lot but it was a very jumpy number, going even below 1000 a lot. Well, some time passed while writing this post so let's check again: Wow, right now it says 4091 (99%)! One hour later: 4092! (It had spontaneous reboots inbetween).
I am testing it now for a few hours and have these problems:
"Not responding" issues (same as old CrossBreeder).
Spontaneous reboots (3 already). One of them failing to boot at all (stuck at JellyCast logo).
Two times, after a reboot, GPS was disabled. Not consistently though.
No noticable performance gain.
By the way, I am testing like real world usage. Just opening, using and closing apps. I use the same apps all the time so that gives a very good feeling about performance. More meaningful than benchmarks to me. My goal is to make this phone suitable for normal daily usage.
Your app is using a combination of serveral mods, right? I would like to be able to enable / disable each one separately. How can I do that? For example, I have a gut feeling that my "not responding" issues (and reboots?) do not come from the entropy mod but perhaps from governor tweaks or something else. Any chance that you will add enable buttons in the app? Or supply seperate scripts?
Update: I DO have performance gain! Not consitently though. Apps sometimes starting faster than ever. Also still the aforementioned quirks. Last hours no more auto-reboots. Entropy reaching 4096 now, just a little bit wobbly. There seems to be a lot of potential.
The stutter was an issue with the last version.
Do try the latest one and let us know.
Also better if you install the Play store also so the updates are automatic.
Version name is changed GUID if comparing. Better than comparing version numbers.
GUI is non functional, just a visual representation of haptic feedback and actual randomness spread.
It's like drawing points in the whites of a poached egg. If you can see a pattern, you'll be rich in the stock market
Today I removed the app. The biggest problem is random reboots for me. As said, it has potential because sometimes apps started faster than ever on my ancient LG L3. But not consistently. So maybe I 'll try again later.
Sorry for my first post, probably tl;dr. I will repeat my most important question: can you provide us with separate scripts? I mean: I would like to test the entropy thing without the other tweaks as you described in the OP.
Dude!
You're probably using an old version. We'll never know. Will we? Will we now?
There's a small trick that borders on superstition. The famous random device block gremlin tends to disappear if you run the GUI in scribble mode. Basically what may be happening is the block is hit and then the stupid kernel makes whatever decision it makes. Usually at the cost of usability in favour of some stupid religious Linux fervour. Someone should report that to LINUX.
Or another entropy generator, haveged or RNGD or Seeder may be running. Which is a big no! Best to run it on stock ROMS or full custom ROMs ( please ask the developer if they're running any variant of above and to recommend coexistence or better variant of any subcomponents or piece of code. ). In other words, open source!
Also, the separate scripts are in the /bin directory on the phone itself. May require bash and ADB skills.
And full source on XDA and GitHub.
I'll construe this as a possible request to also post the shell scripts from GitHub into the XDA project as separate attachments. Which I can do. In due course
Cheers.
Well, I took it from Play Store. Is that an old version?

Categories

Resources