[KERNEL(Nougat)][ROM]Phasma Kernel/UBERSTOCK - Nexus 5X Original Android Development

This is the new refined home for DarkRoom Development. If you submit bug reports without a log, you may be prosecuted...or executed.
Disclaimer:
If your device fails to comply with your standards of what you consider functioning, I am not liable. This is provided free of charge and does not come with a warranty. Although, if you provide a log, I can provide some sort of assurance that I will look into your issue.
Links:
Social:
Twitter - http://twitter.com/DespairDev
G+ Community - https://plus.google.com/u/0/communities/117685307734094084120
Telegram - https://t.me/darkroomdev
Discord - https://discord.gg/BGTFutW
Downloads:
https://go.hunternott.com/darkroom
Source:
Github – https://github.com/matthewdalex/
Github – https://github.com/UBERROMS/
Credits:
faux123
franco
Google
flar2
imoseyon
Cl3Kener
neobuddy89
Star Wars
XDA:DevDB Information
[KERNEL(Nougat)][ROM]Phasma Kernel/UBERSTOCK, ROM for the LG Nexus 5X
Contributors
DespairFactor, Cl3Kener
Source Code: https://github.com/UBERROMS
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.10.x
Based On: AOSP
Version Information
Status: Testing
Created 2015-11-18
Last Updated 2017-12-28

Packet Schedulers/Congestion Avoidance Algorithms:
CDG vs. Cubic vs. Westwood:
CDG
CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm which reacts to both packet loss and inferred queuing delay. It attempts to operate as a delay-based algorithm where possible, but utilises heuristics to detect loss-based TCP cross traffic and will compete effectively as required. CDG is therefore incrementally deployable and suitable for use on shared networks. During delay-based operation, CDG uses a delay-gradient based probabilistic backoff mechanism, and will also try to infer non congestion related packet losses and avoid backing off when they occur. During loss-based operation, CDG essentially reverts to reno-like behaviour. CDG switches to loss-based operation when it detects that a configurable number of consecutive delay-based backoffs have had no measurable effect. It periodically attempts to return to delay-based operation, but will keep switching back to loss-based operation as required.
Cubic
CUBIC is an enhanced version of BIC: it simplifies the BIC window control and improves its TCP-friendliness and RTT-fairness. The window growth function of CUBIC is governed by a cubic function in terms of the elapsed time since the last loss event. Our experience indicates that the cubic function provides a good stability and scalability. Furthermore, the real-time nature of the protocol keeps the window growth rate independent of RTT, which keeps the protocol TCP friendly under both short and long RTT paths.
Westwood
TCP Westwood estimates the available bandwidth by counting and filtering the flow of returning ACKs and adaptively sets the cwnd and the sshtresh after congestion by taking into account the estimated bandwidth.TCP Westwood, is a sender-side-only modification to TCP New Reno that is intended to better handle large bandwidth-delay product paths (large pipes), with potential packet loss due to transmission or other errors (leaky pipes) and with dynamic load (dynamic pipes). TCP Westwood+ is an evolution of TCP Westwood, in fact it was soon discovered that the Westwood bandwidth estimation algorithm did not work well in the presence of reverse traffic due to ACK compression. Westwood+ is friendly towards TCP Reno and fairer than Reno in bandwidth allocation.
Packet Schedulers:
Why use a non default packet scheduler?
Packet schedulers are a portion of the kernel that queues network data on a specific interface and governs how they are transmitted and received including buffers. Below I will breakdown a couple of the packet schedulers included in this kernel.
fq_codel
FQ_Codel (Fair Queuing Controlled Delay) is queuing discipline that combines Fair Queuing with the CoDel AQM scheme. FQ_Codel uses a stochastic model to classify incoming packets into different flows and is used to provide a fair share of the bandwidth to all the flows using the queue. Each such flow is managed by the CoDel queuing discipline. Reordering within a flow is avoided since Codel internally uses a FIFO queue.
pfifo_fast
The FIFO algorithm forms the basis for the default qdisc on all Linux network interfaces (pfifo_fast). It performs no shaping or rearranging of packets. It simply transmits packets as soon as it can after receiving and queuing them. This is also the qdisc used inside all newly created classes until another qdisc or a class replaces the FIFO.
A real FIFO qdisc must, however, have a size limit (a buffer size) to prevent it from overflowing in case it is unable to dequeue packets as quickly as it receives them. Linux implements two basic FIFO qdiscs, one based on bytes, and one on packets. Regardless of the type of FIFO used, the size of the queue is defined by the parameter limit. For a pfifo the unit is understood to be packets and for a bfifo the unit is understood to be bytes.
pie
PIE is designed to control delay effectively. First, an average dequeue rate is estimated based on the standing queue. The rate is used to calculate the current delay. Then, on a periodic basis, the delay is used to calculate the dropping probabilty. Finally, on arrival, a packet is dropped (or marked) based on this probability. PIE makes adjustments to the probability based on the trend of the delay i.e. whether it is going up or down.The delay converges quickly to the target value specified. alpha and beta are statically chosen parameters chosen to control the drop probability growth and are determined through control theoretic approaches. alpha determines how the deviation between the current and target latency changes probability. beta exerts additional adjustments depending on the latency trend. The drop probabilty is used to mark packets in ecn mode. However, as in RED, beyond 10% packets are dropped based on this probability. The bytemode is used to drop packets proportional to the packet size.
fq
A packet scheduler is charged with organizing the flow of packets through the network stack to meet a set of policy objectives. The kernel has quite a few of them, including CBQ for fancy class-based routing, CHOKe for routers, and a couple of variants on the CoDel queue management algorithm. FQ joins this list as a relatively simple scheduler designed to implement fair access across large numbers of flows with local endpoints while keeping buffer sizes down; it also happens to implement TCP pacing.
FQ keeps track of every flow it sees passing through the system. To do so, it calculates an eight-bit hash based on the socket associated with the flow, then uses the result as an index into an array of red-black trees. The data structure is designed, according to Eric, to scale well up to millions of concurrent flows. A number of parameters are associated with each flow, including its current transmission quota and, optionally, the time at which the next packet can be transmitted.
That transmission time is used to implement the TCP pacing support. If a given socket has a pace specified for it, FQ will calculate how far the packets should be spaced in time to conform to that pace. If a flow's next transmission time is in the future, that flow is added to another red-black tree with the transmission time used as the key; that tree, thus, allows the kernel to track delayed flows and quickly find the one whose next packet is due to go out the soonest. A single timer is then used, if needed, to ensure that said packet is transmitted at the right time.
The scheduler maintains two linked lists of active flows, the "new" and "old" lists. When a flow is first encountered, it is placed on the new list. The packet dispatcher services flows on the new list first; once a flow uses up its quota, that flow is moved to the old list. The idea here appears to be to give preferential treatment to new, short-lived connections — a DNS lookup or HTTP "GET" command, for example — and not let those connections be buried underneath larger, longer-lasting flows. Eventually the scheduler works its way through all active flows, sending a quota of data from each; then the process starts over.
There are a number of additional details, of course. There are limits on the amount of data queued for each flow, as well as a limit on the amount of data buffered within the scheduler as a whole; any packet that would exceed one of those limits is dropped. A special "internal" queue exists for high-priority traffic, allowing it to reach the wire more quickly. And so on.
One other detail is garbage collection. One problem with this kind of flow tracking is that nothing tells the scheduler when a particular flow is shut down; indeed, nothing can tell the scheduler for flows without local endpoints or for non-connection-oriented protocols. So the scheduler must figure out on its own when it can stop tracking any given flow. One way to do that would be to drop the flow as soon as there are no packets associated with it, but that would cause some thrashing as the queues empty and refill; it is better to keep flow data around for a little while in anticipation of more traffic. FQ handles this by putting idle flows into a special "detached" state, off the lists of active flows. Whenever a new flow is added, a pass is made over the associated red-black tree to clean out flows that have been detached for a sufficiently long time — three seconds in the current patch.
cake
The CAKE Principle:
(or, how to have your cake and eat it too)
This is a combination of several shaping, AQM and FQ
techniques into one easy-to-use package:
- An overall bandwidth shaper, to move the bottleneck away
from dumb CPE equipment and bloated MACs. This operates
in deficit mode (as in sch_fq), eliminating the need for
any sort of burst parameter (eg. token buxket depth).
Burst support is limited to that necessary to overcome
scheduling latency.
- A Diffserv-aware priority queue, giving more priority to
certain classes, up to a specified fraction of bandwidth.
Above that bandwidth threshold, the priority is reduced to
avoid starving other classes.
- Each priority class has a separate Flow Queue system, to
isolate traffic flows from each other. This prevents a
burst on one flow from increasing the delay to another.
Flows are distributed to queues using a set-associative
hash function.
- Each queue is actively managed by Codel. This serves
flows fairly, and signals congestion early via ECN
(if available) and/or packet drops, to keep latency low.
The codel parameters are auto-tuned based on the bandwidth
setting, as is necessary at low bandwidths.
The configuration parameters are kept deliberately simple
for ease of use. Everything has sane defaults. Complete
generality of configuration is not a goal.
The priority queue operates according to a weighted DRR
scheme, combined with a bandwidth tracker which reuses the
shaper logic to detect which side of the bandwidth sharing
threshold the class is operating. This determines whether
a priority-based weight (high) or a bandwidth-based weight
(low) is used for that class in the current pass.
This qdisc incorporates much of Eric Dumazet's fq_codel code,
customised for use as an integrated subordinate.
How to apply a packet scheduler:
1. Open terminal on your device
2. Use the "su" command to become root
3. Use tc to change the packet scheduler(qdisc) on your device. I have included an example below, the first line is for WiFi and the second for data. In the example, we are setting the qdisc to fq_pie, which is a mix of PIE with per flow rate shaping from fq.
Code:
tc qdisc add dev wlan0 root fq_pie
tc qdisc add dev rmnet_data0 root fq_pie
4. Confirm your packet scheduler has been applied by using the tc tool again. I have included an example below.
Code:
tc qdisc
To use another packet scheduler after applying a previous one, you will need to either reboot or remove the added qdisc from each interface using the command I have included below.
Code:
tc qdisc del root dev wlan0
tc qdisc del root dev rmnet_data0

Ubermallow is coming for the 5X as well, it is compiling now.

Support fauxsound?

added to index
[INDEX] LG NEXUS 5X Resources Compilation Roll-Up

Awesome! Thanks Despair!

Dwayne01 said:
Support fauxsound?
Click to expand...
Click to collapse
Just added it in R1.3
dbrohrer said:
Awesome! Thanks Despair!
Click to expand...
Click to collapse
You are welcome!

Thanks, any details of your rom?, aosp based?

NisseGurra said:
Thanks, any details of your rom?, aosp based?
Click to expand...
Click to collapse
It's aosp based with tons of optimizations
Sent from my Nexus 6P using Tapatalk

DespairFactor said:
It's aosp based with tons of optimizations
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Nice, i try it, any recommendations on gapps?

NisseGurra said:
Nice, i try it, any recommendations on gapps?
Click to expand...
Click to collapse
Use the purenexus arm64 gapps

So far, feels snappy, notification leds functional, charging led not.
No bugs so far.

@DespairFactor I took a gander at some of your other kernels in your signature. They seem pretty well optimized. The BFS scheduler for the Nexus 6 intrigued me as well. Are some of those features and optimizations built in (or planned to be built into) this kernel or is this simply a loosened up stock kernel that allows users to tweak more settings?

Alcolawl said:
@DespairFactor I took a gander at some of your other kernels in your signature. They seem pretty well optimized. The BFS scheduler for the Nexus 6 intrigued me as well. Are some of those features and optimizations built in (or planned to be built into) this kernel or is this simply a loosened up stock kernel that allows users to tweak more settings?
Click to expand...
Click to collapse
Check my github
Sent from my Nexus 6P using Tapatalk

Where do I find feature list etc for this ROM?

stackz07 said:
Where do I find feature list etc for this ROM?
Click to expand...
Click to collapse
On github or on your phone when you flash it...
https://github.com/ubermallow

NisseGurra said:
So far, feels snappy, notification leds functional, charging led not.
No bugs so far.
Click to expand...
Click to collapse
can you help? how to flash it on mda98e ?stuck on boot

georgiem9 said:
can you help? how to flash it on mda98e ?stuck on boot
Click to expand...
Click to collapse
Wipe system/data/cache/dalvik and then flash rom, gapps and kernel
Sent from my Nexus 6P using Tapatalk

georgiem9 said:
can you help? how to flash it on mda98e ?stuck on boot
Click to expand...
Click to collapse
I think its not working on mda89e flashed mdb08i then root install recovery , then flashed uber + gaps + kernel booting now thanks

georgiem9 said:
I think its not working on mda89e flashed mdb08i then root install recovery , then flashed uber + gaps + kernel booting now thanks
Click to expand...
Click to collapse
I suppose there are different ramdisk offsets for the older build.

Related

[READ BEFORE ASKING]CoMMON ANDROID TERMS, VERSIONS AND CAF*[FOR EVERYONE]

(*CAF - Custom Aftermarket Firmware.)
This thread is courtesy of Diablo67 in the Android General forum..obviously not many go there and read and then ask questions to which answers already exist..so please..new and old users..go through this ASAP
Apps2SD:A method of storing applications and cache on the device's microSD card.
ADB:Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
•A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
•A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
•A daemon, which runs as a background process on each emulator or device instance.
Android:A Linux-based operating system for mobile devices such as HTC EVO.Versions are alphabetically codenamed after snacks: Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, Jelly Donut.
AMOLED:Active Matrix Organic Light Emitting Diode. Basically, a very colorful, bright, display found in some smartphones.
APK:Android application package file. Each Android application is compiled and packaged in a single file that includes all of the application's code (.dex files), resources, assets, and manifest file. The application package file can have any name but must use the .apk extension. For example: myExampleAppname.apk. For convenience, an application package file is often referred to as an ".apk".
Alpha:The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test the software using white box techniques. Additional validation is then performed using black box or gray box techniques, by another testing team. Moving to black box testing inside the organization is known as alpha release.[1]
Alpha software can be unstable and could cause crashes or data loss. The exception to this is when the alpha is available publicly (such as a pre-order bonus), in which developers normally push for stability so that their testers can test properly. External availability of alpha software is uncommon in proprietary software. However, open source software, in particular, often have publicly available alpha versions, often distributed as the raw source code of the software.
The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be a feature complete.
Boot Animation:Boot animation is a term for a graphical representation of the boot process of the operating system.
Boot animation can be a simple visualisation of the scrolling boot messages in the console, but it can also present graphics or some combinations of both.
Unlike splash screens, boot screen or boot animation is not necessarily designed for marketing purposes, but can be to enhance the experience of the user as eye candy, or provide the user with messages (with an added advantage of color coding facility) to diagnose the state of the system.
Bootloader:This small program's only job is to load other data and programs which are then executed from RAM.Often, multiple-stage boot loaders are used, during which several programs of increasing complexity load one after the other in a process of chain loading.
Bootloop:When your system recycles over and over without entering the main OS.
Beta: is the software development phase following alpha. It generally begins when the software is feature complete. Software in the beta phase will generally have many more bugs in it than completed software, as well as speed/performance issues. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it.
The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software, willing to test the software without charge, often receiving the final software free of charge or for a reduced price.
Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as a preview, prototype, technical preview (TP), or early access.
Some software is kept in perpetual beta—where new features and functionality is continually added to the software without establishing a firm "final" release.
CPU:It stands for Central Processing Unit and handles all the complex mathematical formulas necessary to do everyday things like surfing the Internet.
Custom:Independent developers who like to customize their devices beyond the standard options provided often tend to release the fruits of their labor for the rest to enjoy, in form of custom ROMs.
Cache:A component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache miss), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the greater the number of requests that can be served from the cache, the faster the overall system performance becomes.
CDMA:Mobile phone standards called cdmaOne, CDMA2000 (the 3G evolution of cdmaOne) and WCDMA (the 3G standard used by GSM carriers), which are often referred to as simply CDMA, and use CDMA as an underlying channel access method.
CIQ:Carrier IQ. A piece of preinstalled software that runs with elevated access in the background of portable devices by default and records everything. Potentially can be exploited to steal information.
Dual Core:A dual core processor is a central processing unit (CPU) that has two separate cores on the same die, each with its own cache. It essentially is two microprocessors in one. This type of CPU is widely available from many manufacturers. Other types of multi-core processors also have been developed, including quad-core processors with four cores each, hexa-core processors with six, octa-core processors with eight and many-core processors with an even larger number of cores.
Dalvik:The Android platform's virtual machine. The Dalvik VM is an interpreter-only virtual machine that executes files in the Dalvik Executable (.dex) format, a format that is optimized for efficient storage and memory-mappable execution.
Dalvik Cache:Writable cache that contains the optimized bytecode of all apk files (apps) on your Android device. Having the information in it's own cache makes applications load faster and perform better.
EXT2:The ext2 or second extended filesystem is a file system for the Linux kernel. It was initially designed by Rémy Card as a replacement for the extended file system (ext).
ext2 was the default filesystem in several Linux distributions, including Debian and Red Hat Linux, until supplanted more recently by ext3, which is almost completely compatible with ext2 and is a journaling file system. ext2 is still the filesystem of choice for flash-based storage media (such as SD cards, and USB flash drives) since its lack of a journal minimizes the number of writes and flash devices have only a limited number of write cycles. Recent kernels, however, support a journal-less mode of ext4, which would offer the same benefit along with a number of ext4-specific benefits.
EXT3:Third extended filesystem, is a journaled file system that is commonly used by the Linux kernel. It is the default file system for many popular Linux distributions, including Debian. Stephen Tweedie first revealed that he was working on extending ext2 in Journaling the Linux ext2fs Filesystem in a 1998 paper and later in a February 1999 kernel mailing list posting, and the filesystem was merged with the mainline Linux kernel in November 2001 from 2.4.15 onward.Its main advantage over ext2 is journaling, which improves reliability and eliminates the need to check the file system after an unclean shutdown. Its successor is ext4.
EXT4:It was born as a series of backward compatible extensions to ext3, many of them originally developed by Cluster File Systems for the Lustre file system between 2003 and 2006, meant to extend storage limits and add other performance improvements.However, other Linux kernel developers opposed accepting extensions to ext3 for stability reasons,and proposed to fork the source code of ext3, rename it as ext4, and do all the development there, without affecting the current ext3 users. This proposal was accepted, and on 28 June 2006, Theodore Ts'o, the ext3 maintainer, announced the new plan of development for ext4.
FC/FC's:Short for "force close," meaning an app that has crashed.
Fastboot:A diagnostic protocol used primarily to modify the flash filesystem in Android smartphones from another computer over a USB connection. It is part of the Android Debug Bridge library.
Utilizing the Fastboot protocol requires that the device be started in a boot loader or Second Program Loader mode in which only the most basic hardware initialization is performed. After enabling the protocol on the device itself it will accept any command sent to it over USB via a command line. Some of most commonly used fastboot commands include:
•flash - Overwrites a partition in flash with a binary image stored on the host computer.
•erase - Erases a partition in flash.
•reboot - Reboots the device into the either the main operating system or the system recovery partition.
•devices - Displays a list of all devices (with Serial #) connected to the host computer.
Flashing:The ROM memory used in smartphones and tablets etc. is often same as flash memory found in SD cards and USB flash drives, simply optimized for better speed and performance while running the operating system.
Hotspot:A spot that offers Internet access over a wireless local area network through the use of a router connected to a link to an Internet service provider. Hotspots typically use Wi-Fi technology.You can connect wifi campatible devices to it.
HDMI:High-Definition Multimedia Interface) is a compact audio/video interface for transmitting encrypted uncompressed digital data.It is a digital alternative to consumer analog standards, such as radio frequency (RF) coaxial cable, composite video, S-Video, SCART, component video, D-Terminal, or VGA (also called D-sub or DE-15F). HDMI connects digital audio/video sources (such as set-top boxes, DVD players, HD DVD players, Blu-ray Disc players, AVCHD camcorders, personal computers (PCs), video game consoles (such as the PlayStation 3 and Xbox 360), AV receivers, tablet computers, and mobile phones) to compatible digital audio devices, computer monitors, video projectors, and digital televisions.
Kang:Someone writes a code,someone else modifies the code to make their own release,its concidered a kang release.
Kernel:A kernel is a layer of code that allows the OS and applications to interface with your phone's hardware. The degree in which you can access your phone's hardware features depends on the quality of code in the kernel. The homebrew (rooting) community for HTC has made several kernel code improvements that give us additional features from our hardware that the stock kernel does not. When you flash a custom ROM, you automatically get a kernel. But you can also flash a standalone kernel ROM on top of the existing one, effectively overwriting it. These days, the difference in custom kernels is less about new features and more about alternate configurations. Choosing a custom kernel is basically choosing one that works best with your ROM.
Launcher:Collectively, the part of the Android user interface on home screens that lets you launch apps, make phone calls, etc. Is built in to Android, or can be purchased in the Android Market.
LCD Densityixel density is a measurement of the resolution of devices in various contexts; typically computer displays, image scanners, and digital camera image sensors.
First of all you need to understand that the Android User Interface uses something called a "display independent pixel" or a "dip" (yes, it's confusing because the density settings are in "dots per inch" or "dpi" which are considered the same as "ppi" or "pixels per inch" as well).
The default LCD Density setting on Android is 160 dpi. As far as the operating system is concerned 1 dip @ 160 dpi = 1 screen pixel. It doesn't mean that's actually true, but you've gotta start somewhere. In my opinion it would have been a lot nicer if they'd chosen 100 dpi because then it would be an easy percentage thing, but they didn't so we're stuck with this formula.
Mod:The act of modifying a piece of hardware or software or anything else for that matter, to perform a function not originally conceived or intended by the designer.
Nandroid:To backup the current running rom.
Nightly:A build that is performed at the end of each day of development. If you use a continuous integration server, it will generally be configured to build the code and run the unit tests on every check in. At the end of each day you may want to run more extensive tests, regression test and integration tests for example, which take too long to run on each check in and these would be triggered after the nightly build. If you have a full continuously delivery pipeline the nightly build may also be used to deploy the built code to environments for user testing.
Open GL:An open source 3D graphics library used in many devices, including Android devices.
Open & Closed Beta: Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test and are invitation only, while open betas are from a larger group to the general public and anyone interested. The testers report any bugs that they find, and sometimes suggest additional features they think should be available in the final version.
Overclock:To increase the speed of your CPU.
Partition:The phone's internal memory (not the SD card) is solid-state (flash) memory, AKA NAND. It can be partitioned much like a normal hard drive can be partitioned. The bootloader exists in its own partition. Recovery is another partition; radio, system, cache, etc are all partitions.
Here are the standard partitions on an Android phone:
/misc - not sure what this is for.
/boot - bootloader, kernel
/recovery - holds the recovery program (either clockworkmod or RA recovery for a rooted Evo)
/system - operating system goes here: Android, Sense, boot animation, Sprint crapware, busybox, etc
/cache - cached data from OS usage
/data - user applications, data, settings, etc.
Recovery Mode:A small separate operating mode you can boot your device into, used for device administration. Two popular custom recovery modes are Amon Ra and Clockwork.
Rom/Firmware:Read-Only Memory and technically speaking, it refers to the internal storage of a device, which is supposed to contain the operating system instructions that needn’t be modified at all during the device’s normal operation.
Recovery Mode:A small separate operating mode you can boot your device into, used for device administration. Two popular custom recovery modes are Amon Ra and Clockwork.
Rom/Firmware:Read-Only Memory and technically speaking, it refers to the internal storage of a device, which is supposed to contain the operating system instructions that needn’t be modified at all during the device’s normal operation.
Ram: (Random Access Memory) A group of memory chips, typically of the dynamic RAM (DRAM) type, which function as the computer's primary workspace. When personal computers first came on the market in the late 1970s, 64KB (64 kilobytes) of RAM was the upper limit. Today, 64MB (64 megabytes) of SDRAM is entry level for a desktop computer, a thousand times as much (see SDRAM).
The "random" in RAM means that the contents of each byte of storage in the chip can be directly accessed without regard to the bytes before or after it. This is also true of other types of memory chips, including ROMs and PROMs. However, unlike ROMs and PROMs, RAM chips require power to maintain their content, which is why you must save your data onto disk before you turn the computer off. To learn about the types of RAM chips and how to upgrade your memory, see memory module. To learn how memory is used to process data, see computer or memory. See also dynamic RAM and static RAM.
Recovery:RecoverySystem contains methods for interacting with the Android recovery system (the separate partition that can be used to install system updates,wipe user data,etc).
Root:The first level of a folder.
Rooting:A process allowing users of mobile phones, tablet PCs, and other devices running the Android operating system to attain privileged control (known as "root access") within Android's subsystem. Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices, resulting in the ability to alter or replace system applications and settings, run specialized apps that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user. Rooting is analogous to jailbreaking devices running the Apple iOS operating system or the Sony PlayStation 3. On Android, rooting can also facilitate the complete removal and replacement of the device's operating system.
SBC: (the ability to charge your battery beyond the default safe limit). The concept is similar to overclocking a processor: you're overriding the safety limits established to achieve additional performance. The benefit here is that you may gain more use of your battery per charge. The drawback is that you can damage the battery and significantly reduce its longevity. Some kernels claim they are using a safe technique to prevent battery damage. Just be aware of the potential risks.
Sideloading:It means installing applications without using the official Android Market.
Splash Screen:A splash screen is an image that appears while android is loading.Splash screens cover the entire screen or simply a rectangle near the center of the screen. The splash screens of operating systems and some applications that expect to be run full-screen usually cover the entire screen.
Superuser/SU:On many computer operating systems, the superuser is a special user account used for system administration. Depending on the operating system, the actual name of this account might be: root, administrator or supervisor.
Normal work on such a system is done using ordinary user accounts, and because these do not have the ability to make system-wide changes any viruses and other malware - or simple user errors - do not have the ability to adversly affect a whole system. In organizations, administrative privileges are often reserved for authorized experienced individuals.
Script:The Scripting Layer for Android (abridged as SL4A, and previously named Android Scripting Environment or ASE) is a library that allows the creation and running of scripts written in various scripting languages directly on Android devices. SL4A is designed for developers and is still alpha quality software.
These scripts have access to many of the APIs available to normal Java Android applications, but with a simplified interface. Scripts can be run interactively in a terminal, in the background, or via Locale.
SDK: (SDK or "devkit") is typically a set of software development tools that allows for the creation of applications for a certain software package, software framework, hardware platform, computer system, video game console, operating system, or similar platform.
Stock:This is the operating system in its default form, without any modifications made to it except for any device-specific support required to run it on the particular device.
Tethering:Means sharing the Internet connection of an Internet-capable mobile phone with other devices. This sharing can be offered over a wireless LAN (Wi-Fi), Bluetooth, or by physical connection using a cable. In the case of tethering over wireless LAN, the feature may be branded as a mobile hotspot.The Internet-connected mobile phone acts as a portable router when providing tethering services to others.
Underclock:To reduce the speed of your CPU.
Undervolt:Undervolting means taking some of the voltage from the CPU which in return gives a longer battery life and lower temperature during intensive use of the CPU.
USB:Stands for Universal Serial Bus. Is a method of connecting devices to a computer. Most smartphones now use microUSB cables to charge and sync.
Updater Script:When Android devices install updates via 'update.zip' files using recovery mode they have to perform a wide range of functions on files and permissions. Instead of using a minimal shell such as {b,d,c}sh the Android designers decided to create a small functional language that can be extended by device manufacturers if necessary. Since the Android "Donut" release (v1.6) the scripting language is called Edify and is defined primarily in the bootable/recovery/{edify,edifyscripting,updater} directories of the Android source-code tree.
Click to expand...
Click to collapse
Nice work
BELOW IS THE DETAILED LIST OF ALL ANDROID VERSIONS AND DETAILS.
1.0:Android 1.0, the first commercial version of the software, was released on 23 September 2008.The first Android device, the HTC Dream (G1), incorporated the following Android 1.0 features:
•Android Market application download and updates through the Market app
•Web browser to show, zoom and pan full HTML and XHTML web pages – multiple pages show as windows ("cards")
•Camera support – however this version lacked the option to change the camera's resolution, white balance, quality, etc.
•Folders allowing the grouping of a number of app icons into a single folder icon on the Home screen.
•Access to web email servers, supporting POP3, IMAP4, and SMTP.
•Gmail synchronization with the Gmail app
•Google Contacts synchronization with the People app
•Google Calendar synchronization with the Calendar app
•Google Maps with Latitude and Street View to view maps and satellite imagery, as well as find local business and obtain driving directions using GPS
•Google Sync, allowing management of over-the-air synchronization of Gmail, People, and Calendar
•Google Search, allowing users to search the Internet and phone apps, contacts, calendar, etc
•Google Talk instant messaging
•Instant messaging, text messaging, and MMS
•Media Player, enabling management, importing, and playback of media files – however, this version lacked video and stereo Bluetooth support
•Notifications appear in the Status bar, with options to set ringtone, LED or vibration alerts
•Voice Dialer allows dialing and placing of phone calls without typing a name or number
•Wallpaper allows the user to set the background image or photo behind the Home screen icons and widgets
•YouTube video player
•Other apps include: Alarm Clock, Calculator, Dialer (Phone), Home screen (launcher), Pictures (Gallery), and Settings.
•Wi-Fi and Bluetooth support
1.1:On 9 February 2009, the Android 1.1 update was released, initially for the T-Mobile G1 only. The update resolved bugs, changed the API and added a number of other features:
•Details and reviews available when a user searches for businesses on Maps
•Longer in-call screen timeout default when using the speakerphone, plus ability to show/hide dialpad
•Ability to save attachments in messages
•Support added for marquee in system layouts
Click to expand...
Click to collapse
FrOM HERE ON, GOOGLE DECIDED TO NAME THEIR VERSIONS IN ALPHABETICAL ORDER, STARTING WITH C, AS 2 VERSIONS HAD ALREADY BEEN RELEASED.
Cupcake:On 30 April 2009, the Android 1.5 update, dubbed Cupcake, was released, based on Linux kernel 2.6.27.The update included several new features and UI amendments:
•Support for third-party virtual keyboards with text prediction and user dictionary for custom words
•Support for Widgets - miniature application views that can be embedded in other applications (such as the Home screen) and receive periodic updates
•Video recording and playback in MPEG-4 and 3GP formats
•Auto-pairing and stereo support for Bluetooth added (A2DP and AVRCP profiles)
•Copy and paste features added to web browser
•User pictures shown for Favorites in Contacts
•Specific date/time stamp shown for events in call log, and one-touch access to a contact card from call log event
•Animated screen transitions
•Ability to upload videos to YouTube
•Ability to upload photos to Picasa
Donut:On 15 September 2009, the Android 1.6 SDK – dubbed Donut – was released, based on Linux kernel 2.6.29.Included in the update were numerous new features:
•Voice and text entry search enhanced to include bookmark history, contacts, and the web
•Ability for developers to include their content in search results
•Multi-lingual speech synthesis engine to allow any Android application to "speak" a string of text
•Easier searching and ability to view app screenshots in Android Market
•Gallery, camera and camcorder more fully integrated, with faster camera access
•Ability for users to select multiple photos for deletion
•Updated technology support for CDMA/EVDO, 802.1x, VPNs, and a text-to-speech engine
•Support for WVGA screen resolutions
•Speed improvements in searching and camera applications
•Expanded Gesture framework and new GestureBuilder development tool
Eclair:On 26 October 2009, the Android 2.0 SDK – codenamed Eclair – was released, based on Linux kernel 2.6.29.Changes included:
•Expanded Account sync, allowing users to add multiple accounts to a device for email- and contact-synchronization
•Exchange email support, with combined inbox to browse email from multiple accounts in one page
•Bluetooth 2.1 support
•Ability to tap a Contacts photo and select to call, SMS, or email the person
•Ability to search all saved SMS and MMS messages, with delete oldest messages in a conversation automatically deleted when a defined limit is reached
•Numerous new camera features, including flash support, digital zoom, scene mode, white balance, color effect and macro focus
•Improved typing speed on virtual keyboard, with smarter dictionary that learns from word usage and includes contact names as suggestions
•Refreshed browser UI with bookmark thumbnails, double-tap zoom and support for HTML5
•Calendar agenda view enhanced, showing attending status for each invitee, and ability to invite new guests to events
•Optimized hardware speed and revamped UI
•Support for more screen sizes and resolutions, with better contrast ratio
•Improved Google Maps 3.1.2
•MotionEvent class enhanced to track multi-touch events
•Addition of live wallpapers, allowing the animation of home-screen background images to show movement
2.0.1:The Android 2.0.1 SDK was released on 3 December 2009.It was a minor platform release deployable to Android-powered handsets, including minor API changes, bug fixes and framework behavioral changes
2.1:The 2.1 SDK was released on 12 January 2010.It was a minor platform release deployable to Android-powered handsets, including minor amendments to the API and bug fixes.
Froyo:On 20 May 2010, the Android 2.2 (Froyo) SDK was released, based on Linux kernel 2.6.32.Its features included:
•Speed, memory, and performance optimizations
•Additional application speed improvements, implemented through JIT compilation
•Integration of Chrome's V8 JavaScript engine into the Browser application
•Support for the Android Cloud to Device Messaging (C2DM) service, enabling push notifications
•Improved Microsoft Exchange support, including security policies, auto-discovery, GAL look-up, calendar synchronization and remote wipe
•Improved application launcher with shortcuts to Phone and Browser applications
•USB tethering and Wi-Fi hotspot functionality
•Added an option to disable data access over mobile network
•Updated Market application with batch and automatic update features
•Quick switching between multiple keyboard languages and their dictionaries
•Voice dialing and contact sharing over Bluetooth
•Support for Bluetooth-enabled car and desk docks
•Support for numeric and alphanumeric passwords
•Support for file upload fields in the Browser application
•Support for installing applications to the expandable memory
•Adobe Flash support
•Support for extra-high-PPI screens (320 ppi), such as 4" 720p
•Gallery allows users to view picture stacks using a zoom gesture
2.2.1:The Android 2.2.1 update was released on 18 January 2011, and included a number of bug fixes, security updates, and performance improvements.
2.2.2:The Android 2.2.2 update was released on 22 January 2011, and fixed minor bugs, including SMS routing issues that affected the Nexus One.
2.2.3:The Android 2.2.3 update was released on 21 November 2011, and consisted of two security patches.
Gingerbread:On 6 December 2010, the Android 2.3 (Gingerbread) SDK was released, based on Linux kernel 2.6.35.Changes included:
•Updated user interface design with increased simplicity and speed
•Support for extra-large screen sizes and resolutions (WXGA and higher)
•Native support for SIP VoIP internet telephony
•Faster, more intuitive text input in virtual keyboard, with improved accuracy,better suggested text and voice input mode
•Enhanced copy/paste functionality, allowing users to select a word by press-hold, copy, and paste
•Support for Near Field Communication (NFC), allowing the user to read an NFC tag embedded in a poster, sticker, or advertisement
•New audio effects such as reverb, equalization, headphone virtualization, and bass boost
•New Download Manager, giving users easy access to any file downloaded from the browser, email, or another application
•Support for multiple cameras on the device, including a front-facing camera, if available
•Support for WebM/VP8 video playback, and AAC audio encoding
•Improved power management with a more active role in managing apps that are keeping the device awake for too long
•Enhanced support for native code development
•Switched from YAFFS to ext4 on newer devices
•Audio, graphical, and input enhancements for game developers
•Concurrent garbage collection for increased performance
•Native support for more sensors (such as gyroscopes and barometers)
2.2.3:Released on 9 February 2011, Android 2.3.3 included several improvements and API fixes
2.3.4:Version 2.3.4 introduced support for voice or video chat using Google Talk.
2.3.5:Released on 25 July 2011, Android 2.3.5 included a number of system enhancements:
•Improved network performance for the Nexus S 4G, among other fixes and improvements
•Fixed Bluetooth bug on Samsung Galaxy S
•Improved Gmail application
•Shadow animations for list scrolling
•Camera software enhancements
•Improved battery efficiency
2.3.6:Released on 2 September 2011, this version fixed a voice search bug. The 2.3.6 update had the side-effect of impairing the Wi-Fi hotspot functionality of many Canadian Nexus S phones. Google acknowledged this problem and fixed it in late September.
2.3.7:Android 2.3.7 introduced Google Wallet support for the Nexus S 4G.
Honeycomb:On 22 February 2011, the Android 3.0 (Honeycomb) SDK – the first tablet-only Android update – was released, based on Linux kernel 2.6.36.The first device featuring this version, the Motorola Xoom tablet, was released on 24 February 2011.Changes included:
•Optimized tablet support with a new virtual and “holographic” user interface
•Added System Bar, featuring quick access to notifications, status, and soft navigation buttons, available at the bottom of the screen
•Added Action Bar, giving access to contextual options, navigation, widgets, or other types of content at the top of the screen
•Simplified multitasking – tapping Recent Apps in the System Bar allows users to see snapshots of the tasks underway and quickly jump from one app to another
•Redesigned keyboard, making typing fast, efficient and accurate on larger screen sizes
•Simplified, more intuitive copy/paste interface
•Multiple browser tabs replacing browser windows, plus form auto-fill and a new “incognito” mode allowing anonymous browsing
•Quick access to camera exposure, focus, flash, zoom, front-facing camera, time-lapse, and more
•Ability to view albums and other collections in full-screen mode in Gallery, with easy access to thumbnails for other photos
•New two-pane Contacts UI and Fast Scroll to let users easily organize and locate contacts
•New two-pane Email UI to make viewing and organizing messages more efficient, allowing users to select one or more messages
•Support for video chat using Google Talk
•Hardware acceleration
•Support for multi-core processors
•Ability to encrypt all user data
3.1:The 3.1 SDK was released on 10 May 2011.Changes included:
•UI refinements
•Connectivity for USB accessories
•Expanded Recent Apps list
•Resizable Home screen widgets
•Support for external keyboards and pointing devices
•Support for joysticks and gamepads
•Support for FLAC audio playback
•High-performance Wi-Fi lock, maintaining high-performance Wi-Fi connections when device screen is off
•Support for HTTP proxy for each connected Wi-Fi access point
3.2:The 3.2 SDK was released on 15 July 2011,first appearing on Huawei's MediaPad tablet.Changes included:
•Improved hardware support, including optimizations for a wider range of tablets
•Increased ability of apps to access files on the SD card, e.g. for synchronization
•Compatibility display mode for apps that have not been optimized for tablet screen resolutions
•New display support functions, giving developers more control over display appearance on different Android devices
3.2.1:The Android 3.2.1 update was released on 20 September 2011, and included a number of amendments:
•Bug fixes and minor security, stability and Wi-Fi improvements
•Update to Android Market with automatic updates and easier-to-read Terms and Condition text
•Update to Google Books
•Improved Adobe Flash support in browser
•Improved Chinese handwriting prediction
3.2.2:The 3.2.2 update was released on 30 August 2011, and included bug fixes and other minor improvements for the Motorola Xoom 4G.
Ice Cream Sandwhich:Android 4.0 – codenamed Ice Cream Sandwich, and based on Linux kernel 3.0.1– was previewed at the May 2011 Google I/O event,and officially launched at the Galaxy Nexus and Ice Cream Sandwich release event on 19 October 2011.
•Enhanced speed and performance
•Virtual buttons in the UI, in place of capacitive or physical buttons
•Separation of widgets in a new tab, listed in a similar manner to apps
•Easier-to-create folders, with a drag-and-drop style
•A customizable launcher
•Improved visual voicemail with the ability to speed up or slow down voicemail messages
•Pinch-to-zoom functionality in the calendar
•Offline search, a two-line preview, and new action bar at the bottom of the Gmail app
•Ability to swipe left or right to switch between Gmail conversations
•Integrated screenshot capture (accomplished by holding down the Power and Volume-Down buttons)
•Improved error correction on the keyboard
•Ability to access apps directly from lock screen (similar to HTC Sense 3.x)
•Improved copy and paste functionality
•Better voice integration and continuous, real-time speech to text dictation
•Face Unlock, a feature that allows users to unlock handsets using facial recognition software
•New tabbed web browser, allowing up to 16 tabs
•Automatic syncing of browser with users' Chrome bookmarks
•A new typeface family for the UI, Roboto
•Data Usage section in settings that lets users set warnings when they approach a certain usage limit, and disable data use when the limit is exceeded
•Ability to shut down apps that are using data in the background
•Improved camera app with zero shutter lag, time lapse settings, panorama mode, and the ability to zoom while recording
•Built-in photo editor
•New gallery layout, organized by location and person
•Refreshed "People" app with social network integration, status updates and hi-res images
•Android Beam, a near-field communication feature allowing the rapid short-range exchange of web bookmarks, contact info, directions, YouTube videos and other data
•Hardware acceleration of the UI
•Resizeable widgets – already part of Android 3.1 for tablets, but new for cellphones
•Wi-Fi Direct
•1080p video recording for stock Android devices
4.0.2:The Android 4.0.2 update was released on 28 November 2011,and fixed minor bugs on the Verizon Galaxy Nexus,the US launch of which was later delayed until December 2011.
4.0.3:The Android 4.0.3 update was first released on 16 December 2011.It included a number of bug fixes and optimizations, and offered improvements to graphics, databases, spell-checking and Bluetooth functionality,along with new APIs for developers,including a social stream API in the Contacts provider. Other features included Calendar provider enhancements, new camera apps enhancing video stabilization and QVGA resolution, and accessibility refinements such as improved content access for screen readers.
Jelly Bean:The report also mentions some interesting features that originally planned in the presence of ice Cream Sandwich is likely to be postponed and will be displayed on the jelly bean.
Reportedly,this is because these features are not ready until it came time to release the ice cream sandwiches.Google itself has not confirmed anything regarding this information.
Click to expand...
Click to collapse
Different Custom After Market Firmwares.
BeLOW ARE THE DIFFERENT CUSTOM AFTER MARKET FIRMWARES.
MIUI
(pronounced "Me You I", a play on the common abbreviation of the words user interface as UI),developed by Xiaomi Tech, is an aftermarket firmware for cell phones based on the open-source Android operating system. It features a heavily-modified user interface that does away with the Android app drawer and has drawn comparisons with Apple's iOS.It includes additional functionality not found in stock Android, including toggles on the notification pull-down, new music, gallery, and camera apps, and an altered phone dialer that displays matching contacts as a user enters a number.
MIUI is based on Android 2.3.7 and CyanogenMod 7.1 sources, and was initially developed in the Chinese language by Chinese startup Xiaomi.Xiaomi added a number of apps to enhance the basic framework; those include MITalk (a Blackberry Messenger clone),MINotes,MIBackup,MIMusic,and MIGallery.MIUI is made up of two parts, MI and UI, where UI stands for User Interface and MI, as stated by Xiaomi CEO Lei Jun, stands for Mobile Internet and Mission Impossible.
The modified operating system has been criticized for being similar to iOS.Due to the fact that MIUI is developed in China, some features that are not relevant to the Chinese market, such as WiMax support, are unavailable on MIUI, and without access to the source code, it is not possible for 3rd parties to easily add this support.
AOSP
The Android Open Source Project (AOSP) is led by Google, and is tasked with the maintenance and development of Android.According to the project "The goal of the Android Open Source Project is to create a successful real-world product that improves the mobile experience for end users."AOSP also maintains the Android Compatibility Program, defining an "Android compatible" device "as one that can run any application written by third-party developers using the Android SDK and NDK", to prevent incompatible Android implementations.The compatibility program is also optional and free of charge, with the Compatibility Test Suite also free and open-source.
CYANOGENMOD
CyanogenMod is an open source replacement firmware based on the Android mobile operating system for smart phones and tablet computers. It offers features and options not found in the official firmware distributed by vendors of these devices.
Features supported by CyanogenMod include native theming support (also called the "T-Mobile Theme Engine"), Free Lossless Audio Codec (FLAC) support, a large Access Point Name list, an OpenVPN client, a reboot menu, support for Wi-Fi, Bluetooth, and USB tethering, CPU overclocking and performance enhancements, soft buttons and other "tablet tweaks", toggles in the notification pull-down (such as Wi-Fi, Bluetooth and GPS), app permissions management, as well as other interface enhancements. CyanogenMod is also stated to increase performance and reliability compared with official firmware releases.
CyanogenMod is developed as free and open source software based on the official releases of Android by Google, with added original and third-party code.
Click to expand...
Click to collapse
Thank You. Now I know what CAF means.
Android_Sheriff said:
Thank You. Now I know what CAF means.
Click to expand...
Click to collapse
code aurora forum
http://forum.xda-developers.com/sitesearch.php?q=code aurora forum
Thanks!
Now, I know what is "kanging" means, this thread is very useful...

[MOD] CrossBreeder - Entropy Lag Reduce/DNS Speedup/Clean Adblock

Crossbreeder is an 5in1 package created to make Android devices run faster with less lag and to give a significant performance boost.
Tested and confirmed to give our wildfires a considerable boost. Tested on CM6, CM7, CM9.
head to the original thread to get the flashable ZIP. and please remember to read the OP carefully before using this.
Zip files are also attached to this post.
Original Thread -
forum.xda-developers.com/showthread.php?t=2113150
all credit goes to idcrisis for creating this package. I'm just sharing this with my fellow buzzers.
what Crossbreeder actually do, QUOTED FROM ORIGINAL POST,
This is a combination of 5 different
key methodologies to improve the
Android experience:
1. It's a big new feature, DNS
caching, parallelising and tether
boost . A lot of the lag in a lot of
apps, apart from the GUI lag, is due
to slow DNS querying, specially on
the mobile network.
CrossBreeder now runs a caching,
parallelising DNS client on the
device. So now most of your DNS
queries will be served from the
cache and if not found, the query
will be sent in in parallel to
multiple DNS servers including the
two Google DNS servers and your
two ISP servers and the quickest
reply will be served to you, hot and
transparent. You can read this
rationale for this approach - http://
ma.ttwagner.com/make-dns-fly-...q-
all-servers/
This speeds up network access and
networked apps, like Browsers of
course, and Tapatalk, Gmail and
thousands of others drastically. And
removes a lot of the lag where it was
due to DNS querying. This will not
increase your network or download
speed but pages will load much
faster.
This will future proof your devices as
more and more apps start using
HTML5 and/or reside completely as
web pages or the like.
CrossBreeder boosts your tethering
connection. Client devices to your
device will take advantage of the
new DNS. Hence their usage is also
improved! In many cases this update
might even fix a broken tethering
feature on your phone. So if your
ROM doesn't have a working
tethering support, you an try and
install this update. It might
magically start working!
CrossBreeder blocks ads and
spyware in an efficient manner by
blocking access to the host. It does
this using a static block list of known
ad sites and behaving as an
authoritative DNS server for these
sites and redirecting them to a
dummy address. CrossBreeder runs a
simple web server serving empty
images and pages, so ads completely
disappear instead of showing an ugly
Page/Image Not found error.
You can update this block list from
an external specialised tool like
Adaway if you need
It also renames any existing /etc/
hosts file on your device. Testing
has proven that keeping a system
wide /etc/hosts file as is used by
most other Ad blocking software
actually slows down your system. So
it is recommended to use this
method instead. Check this out for
the demonstration of the slowdown
and how to test it yourself - http://
forum.xda-developers.com/
show...php?p=41877518
In order to achieve all this DNS
related functionality, CrossBreeder
relies on the excellent open source
utilities - DNRD and Dnsmasq
2. Modulate OS entropy levels for
lag reduction ala Seeder. The whole
OS reads either /dev/random or /
dev/urandom and both need
entropy. However this mod uses a
completely different, lightweight and
efficient random number generator
called Havege . This sharply reduces
cpu consumption and corresponding
battery life loss compared to Seeder.
It also does a better job at keeping
entropy levels high hence your
device is more responsive. It doesn't
run in a CPU intensive loop either.
The extend queue functionality has
also been added to CrossBreeder.
See here for another rationale
favouring Havege compared to Rngd
- ( http://code.google.com/p/csrng/ -
Look for the limitations.)
3. Change kernel parameters
specially the wakeup threshold ones
so read blocks are released instantly
and writes never wake up as we have
an external entropy generator. And a
host of other fail safe and working
tweaks from the community for each
key subsystem. ( one can look
inside /etc/CrossBreeder/
zzCrossBreeder ).
4. Remove /dev/random as it's
blocking . Link it to non-blocking /
dev/urandom. Since /dev/random is
blocking and designed to protect us
from Quantum alien cryptographers
with mathematical certainty and
urandom is non blocking pseudo-
random device that most apps and
OSs are using anyway and with
Haveged running, is as secure
anyway as it's very difficult to empty
the entropy pool faster than Havege
can replenish it. Pre ICS devices
have a lot to gain with this but ICS+
devices show visible gains too.
5. Frandom support (Optional) -
CrossBreeder now supports linking
both your random devices to the
extremely fast alternative - Frandom
( http://billauer.co.il/
frandom.html ). This module is
orders of magnitude (10-50 times)
faster than the standard character
devices ( Check this out - http://
forum.xda-developers.com/
show...&postcount=134 ). The
erandom character device also
installed by Frandom doesn't use up
system entropy at all on top of being
fast. You will need to ask your ROM
developer to develop the kernel
module for you and then place it
in /system/lib/modules.
CrossBreeder will then try and load
it and if successful, make all the
necessary adjustments so that both /
dev/random and /dev/urandom are
pointing to /dev/frandom and /dev/
erandom respectively. The speed
benefits are to be seen to be
believed. But since each ROM
requires a unique kernel module,
this option is left optional ( but
auto detect ). Advanced users can
even try and load the frandom
module built for other kernels if
they don't have one readily available
for their own kernel version using
the Punchmod utility. Read this:
http://forum.xda-developers.com/
show...5#post41920265
remember to download both Crossbreeder and uninstall ZIP files. it's very unlikely that crossbreeder will cause any problems, but it's better to be prepared.
Feedbacks are welcome
Edit - Attachments will no longer be updated. Visit the original thread for latest versions.
lakshan_456 said:
Crossbreeder is an 5in1 package created to make Android devices run faster with less lag and to give a significant performance boost.
Tested and confirmed to give our wildfires a considerable boost. Tested on CM6, CM7, CM9.
head to the original thread to get the flashable ZIP. and please remember to read the OP carefully before using this.
Zip files are also attached to this post.
Original Thread -
forum.xda-developers.com/showthread.php?t=21131500
all credit goes to idcrisis for creating this package. I'm just sharing this with my fellow buzzers.
what Crossbreeder actually do, QUOTED FROM ORIGINAL POST,
This is a combination of 5 different
key methodologies to improve the
Android experience:
1. It's a big new feature, DNS
caching, parallelising and tether
boost . A lot of the lag in a lot of
apps, apart from the GUI lag, is due
to slow DNS querying, specially on
the mobile network.
CrossBreeder now runs a caching,
parallelising DNS client on the
device. So now most of your DNS
queries will be served from the
cache and if not found, the query
will be sent in in parallel to
multiple DNS servers including the
two Google DNS servers and your
two ISP servers and the quickest
reply will be served to you, hot and
transparent. You can read this
rationale for this approach - http://
ma.ttwagner.com/make-dns-fly-...q-
all-servers/
This speeds up network access and
networked apps, like Browsers of
course, and Tapatalk, Gmail and
thousands of others drastically. And
removes a lot of the lag where it was
due to DNS querying. This will not
increase your network or download
speed but pages will load much
faster.
This will future proof your devices as
more and more apps start using
HTML5 and/or reside completely as
web pages or the like.
CrossBreeder boosts your tethering
connection. Client devices to your
device will take advantage of the
new DNS. Hence their usage is also
improved! In many cases this update
might even fix a broken tethering
feature on your phone. So if your
ROM doesn't have a working
tethering support, you an try and
install this update. It might
magically start working!
CrossBreeder blocks ads and
spyware in an efficient manner by
blocking access to the host. It does
this using a static block list of known
ad sites and behaving as an
authoritative DNS server for these
sites and redirecting them to a
dummy address. CrossBreeder runs a
simple web server serving empty
images and pages, so ads completely
disappear instead of showing an ugly
Page/Image Not found error.
You can update this block list from
an external specialised tool like
Adaway if you need
It also renames any existing /etc/
hosts file on your device. Testing
has proven that keeping a system
wide /etc/hosts file as is used by
most other Ad blocking software
actually slows down your system. So
it is recommended to use this
method instead. Check this out for
the demonstration of the slowdown
and how to test it yourself - http://
forum.xda-developers.com/
show...php?p=41877518
In order to achieve all this DNS
related functionality, CrossBreeder
relies on the excellent open source
utilities - DNRD and Dnsmasq
2. Modulate OS entropy levels for
lag reduction ala Seeder. The whole
OS reads either /dev/random or /
dev/urandom and both need
entropy. However this mod uses a
completely different, lightweight and
efficient random number generator
called Havege . This sharply reduces
cpu consumption and corresponding
battery life loss compared to Seeder.
It also does a better job at keeping
entropy levels high hence your
device is more responsive. It doesn't
run in a CPU intensive loop either.
The extend queue functionality has
also been added to CrossBreeder.
See here for another rationale
favouring Havege compared to Rngd
- ( http://code.google.com/p/csrng/ -
Look for the limitations.)
3. Change kernel parameters
specially the wakeup threshold ones
so read blocks are released instantly
and writes never wake up as we have
an external entropy generator. And a
host of other fail safe and working
tweaks from the community for each
key subsystem. ( one can look
inside /etc/CrossBreeder/
zzCrossBreeder ).
4. Remove /dev/random as it's
blocking . Link it to non-blocking /
dev/urandom. Since /dev/random is
blocking and designed to protect us
from Quantum alien cryptographers
with mathematical certainty and
urandom is non blocking pseudo-
random device that most apps and
OSs are using anyway and with
Haveged running, is as secure
anyway as it's very difficult to empty
the entropy pool faster than Havege
can replenish it. Pre ICS devices
have a lot to gain with this but ICS+
devices show visible gains too.
5. Frandom support (Optional) -
CrossBreeder now supports linking
both your random devices to the
extremely fast alternative - Frandom
( http://billauer.co.il/
frandom.html ). This module is
orders of magnitude (10-50 times)
faster than the standard character
devices ( Check this out - http://
forum.xda-developers.com/
show...&postcount=134 ). The
erandom character device also
installed by Frandom doesn't use up
system entropy at all on top of being
fast. You will need to ask your ROM
developer to develop the kernel
module for you and then place it
in /system/lib/modules.
CrossBreeder will then try and load
it and if successful, make all the
necessary adjustments so that both /
dev/random and /dev/urandom are
pointing to /dev/frandom and /dev/
erandom respectively. The speed
benefits are to be seen to be
believed. But since each ROM
requires a unique kernel module,
this option is left optional ( but
auto detect ). Advanced users can
even try and load the frandom
module built for other kernels if
they don't have one readily available
for their own kernel version using
the Punchmod utility. Read this:
http://forum.xda-developers.com/
show...5#post41920265
remember to download both Crossbreeder and uninstall ZIP files. it's very unlikely that crossbreeder will cause any problems, but it's better to be prepared.
Feedbacks are welcomed
Click to expand...
Click to collapse
Tested on rempuzzle, change nothing , will test other thing.
And Tested on miui v2.3,it improve the performances.
On aokp v5, it make bootloop when We usés the ROM too long ( without oc ).
On miui v4, improve stability.
Sent from my HTC Wildfire using xda app-developers app
Pator57 said:
Tested on rempuzzle, change nothing , will test other thing.
And Tested on miui v2.3,it improve the performances.
On aokp v5, it make bootloop when We usés the ROM too long ( without oc ).
On miui v4, improve stability.
Sent from my HTC Wildfire using xda app-developers app
Click to expand...
Click to collapse
well,rempuzzle probably don't need this, since its fast enough as it is now. but it would have been great if this worked.
I think aokp v5 has seeder intergrated, maybe they are conflicting with each other. but crossbreeder says it prevents seeder from executing, so I'm not sure.
anyway thanks for the info
but crossbreeder says it prevents seeder from executing, so I'm not sure.
Click to expand...
Click to collapse
It does. I had that myself when crossbreeder stopped seeder app automatically after having flashed it.
gerope said:
It does. I had that myself when crossbreeder stopped seeder app automatically after having flashed it.
Click to expand...
Click to collapse
yes, I know it does, I was just guessing a probable cause for the bootloop.
Maybe it's something else, better leave that to devs to look into.
Tested this on DK froyo ROM. It does make a difference.
Sent from my HTC Wildfire using Tapatalk 2
Updated Attached files to latest version (6.23.13_v2)
If your current Kernel doesn't support Init.d executions, try an app like Universel Init.d
https://play.google.com/store/apps/...&utm_medium=organic&utm_term=universal+init.d
Pator57 said:
Tested on rempuzzle, change nothing , will test other thing.
And Tested on miui v2.3,it improve the performances.
On aokp v5, it make bootloop when We usés the ROM too long ( without oc ).
On miui v4, improve stability.
Sent from my HTC Wildfire using xda app-developers app
Click to expand...
Click to collapse
I flashed AOKP v5 and deleted the seeder script from Init.d folder after flashing Crossbreeder, and I did not experience any bootoops while I was using that ROM ( I used it for about 2 weeks)
Does Rempuzzle support Init.d scripts?
lakshan_456 said:
I flashed AOKP v5 and deleted the seeder script from Init.d folder after flashing Crossbreeder, and I did not experience any bootoops while I was using that ROM ( I used it for about 2 weeks)
Does Rempuzzle support Init.d scripts?
Click to expand...
Click to collapse
Yea, im sure.
Sent from my HTC Wildfire using xda app-developers app
Definitely, this mod effects, cm7 becomes smoother.
while coming out of app drawer back to main screen, scrolling has also improved.
Thanks
Sent from my HTC Wildfire using Tapatalk 2
Intresting..
Thnx for this m8 Going to try hopefully it will reduce many lags :]
-------------------------------
Btw i'm new to this all :] :good:
New update available.
Visit the Original thread for more info and downloads.
http://forum.xda-developers.com/showthread.php?t=2113150

SecAndy : let's get the party started

Pronounced "say candy", the goal of SecAndy is to come up with as secure and private of an OS as possible. So as not to reinvent the wheel, we'll base this initiative on our open source code of choice (Android or maybe other developers' choice).
I am not a developer myself but I can without a doubt, because of former professional experiences, organize a project and gather the right people together as a community in order to make sure that project sees the light of day after it has acquired a life of its own if needed, which I think we will agree is something that this kind of project requires because of the scrutiny it will quickly attract.
I am officially calling upon this post all interested developers that could help us fork Android or other open source OS.
Let's get a kickstarter funded and let the party begin. I will update you later today on the advancement of such.
This thread welcomes constructive ideas and developer participation, but here are beginning requirements we'll need to fulfill eventually to privatize and secure android :
- default browser allowing custom search engines such as https://ixquick.com or duckduckgo
- default system search pointing to those custom engines for online component
- control of gps at firmware level to allow full disability
- peer to peer file exchange (think BitTorrent sync) with 1024 to 2048 bit encryption
- implementation of secure sms and mms exchange (think textsecure)
- implementation of encrypted voice channels (think redphone or SIP with end-to-end encryption)
- root vpn for all online access
- systemwide warning of insecure solutions (example : wanting to use gmail or regular email)
- PGP transparent email solution
- Tor option for root vpn (subject to mitm attacks but more on that later)
- peerguardian type auto-updated database to identify suspicious IP address ranges
- systematic in-out firewall control auto updated with peerguardian database and community based rules database
- hardened malware protection and app permissions with automatic permission audit based on application type
- full device encryption and lockup (in case of unauthorized user)
- full remote wipe out and bricking with auto IMEI reporting (in case of theft, might have to be amended because of attack vector)
- full remote location capability with real time tracking (that one might have to be scratched, high security risk because of attack vector)
This obviously doesn't cover all the bases but would be a good start... I know a lot of these options can be implemented with a mismatch of apps and custom Roms but having it all at an OS level AOKP style would greatly help in building an android by the people for the people community that could eventually loosen the stranglehold of less than transparent corporations.
100 views total between both threads in 24 hours and not one comment. Obviously I'm approaching this the wrong way. More news at 11.

[KERNEL][ROM][NOUGAT]Despair Kernel/UBERSTOCK

This is the new refined home for DarkRoom Development. If you submit bug reports without a log, you may be prosecuted...or executed.
Disclaimer:
If your device fails to comply with your standards of what you consider functioning, I am not liable. This is provided free of charge and does not come with a warranty. Although, if you provide a log, I can provide some sort of assurance that I will look into your issue.
Links:
Social:
Twitter - http://twitter.com/DespairDev
G+ Community - https://plus.google.com/u/0/communities/117685307734094084120
Downloads:
Google Drive – https://drive.google.com/drive/folders/0Bwcofov-xyI0ZVhQUWJhMm9PMkU
Source:
Github – https://github.com/matthewdalex/
Github – https://github.com/UBERROMS/
Credits:
faux123
franco
Google
flar2
imoseyon
Cl3Kener
neobuddy89
Star Wars
XDA:DevDB Information
[KERNEL][ROM][NOUGAT]Despair Kernel/UBERSTOCK, Kernel for the Nexus 6
Contributors
DespairFactor
Source Code: https://github.com/UBERROMS
Kernel Special Features:
Version Information
Status: Testing
Created 2015-07-07
Last Updated 2017-06-17
Packet Schedulers/Congestion Avoidance Algorithms:
CDG vs. Cubic vs. Westwood:
CDG
CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm which reacts to both packet loss and inferred queuing delay. It attempts to operate as a delay-based algorithm where possible, but utilises heuristics to detect loss-based TCP cross traffic and will compete effectively as required. CDG is therefore incrementally deployable and suitable for use on shared networks. During delay-based operation, CDG uses a delay-gradient based probabilistic backoff mechanism, and will also try to infer non congestion related packet losses and avoid backing off when they occur. During loss-based operation, CDG essentially reverts to reno-like behaviour. CDG switches to loss-based operation when it detects that a configurable number of consecutive delay-based backoffs have had no measurable effect. It periodically attempts to return to delay-based operation, but will keep switching back to loss-based operation as required.
Cubic
CUBIC is an enhanced version of BIC: it simplifies the BIC window control and improves its TCP-friendliness and RTT-fairness. The window growth function of CUBIC is governed by a cubic function in terms of the elapsed time since the last loss event. Our experience indicates that the cubic function provides a good stability and scalability. Furthermore, the real-time nature of the protocol keeps the window growth rate independent of RTT, which keeps the protocol TCP friendly under both short and long RTT paths.
Westwood
TCP Westwood estimates the available bandwidth by counting and filtering the flow of returning ACKs and adaptively sets the cwnd and the sshtresh after congestion by taking into account the estimated bandwidth.TCP Westwood, is a sender-side-only modification to TCP New Reno that is intended to better handle large bandwidth-delay product paths (large pipes), with potential packet loss due to transmission or other errors (leaky pipes) and with dynamic load (dynamic pipes). TCP Westwood+ is an evolution of TCP Westwood, in fact it was soon discovered that the Westwood bandwidth estimation algorithm did not work well in the presence of reverse traffic due to ACK compression. Westwood+ is friendly towards TCP Reno and fairer than Reno in bandwidth allocation.
Packet Schedulers:
Why use a non default packet scheduler?
Packet schedulers are a portion of the kernel that queues network data on a specific interface and governs how they are transmitted and received including buffers. Below I will breakdown a couple of the packet schedulers included in this kernel.
fq_codel
FQ_Codel (Fair Queuing Controlled Delay) is queuing discipline that combines Fair Queuing with the CoDel AQM scheme. FQ_Codel uses a stochastic model to classify incoming packets into different flows and is used to provide a fair share of the bandwidth to all the flows using the queue. Each such flow is managed by the CoDel queuing discipline. Reordering within a flow is avoided since Codel internally uses a FIFO queue.
pfifo_fast
The FIFO algorithm forms the basis for the default qdisc on all Linux network interfaces (pfifo_fast). It performs no shaping or rearranging of packets. It simply transmits packets as soon as it can after receiving and queuing them. This is also the qdisc used inside all newly created classes until another qdisc or a class replaces the FIFO.
A real FIFO qdisc must, however, have a size limit (a buffer size) to prevent it from overflowing in case it is unable to dequeue packets as quickly as it receives them. Linux implements two basic FIFO qdiscs, one based on bytes, and one on packets. Regardless of the type of FIFO used, the size of the queue is defined by the parameter limit. For a pfifo the unit is understood to be packets and for a bfifo the unit is understood to be bytes.
pie
PIE is designed to control delay effectively. First, an average dequeue rate is estimated based on the standing queue. The rate is used to calculate the current delay. Then, on a periodic basis, the delay is used to calculate the dropping probabilty. Finally, on arrival, a packet is dropped (or marked) based on this probability. PIE makes adjustments to the probability based on the trend of the delay i.e. whether it is going up or down.The delay converges quickly to the target value specified. alpha and beta are statically chosen parameters chosen to control the drop probability growth and are determined through control theoretic approaches. alpha determines how the deviation between the current and target latency changes probability. beta exerts additional adjustments depending on the latency trend. The drop probabilty is used to mark packets in ecn mode. However, as in RED, beyond 10% packets are dropped based on this probability. The bytemode is used to drop packets proportional to the packet size.
fq
A packet scheduler is charged with organizing the flow of packets through the network stack to meet a set of policy objectives. The kernel has quite a few of them, including CBQ for fancy class-based routing, CHOKe for routers, and a couple of variants on the CoDel queue management algorithm. FQ joins this list as a relatively simple scheduler designed to implement fair access across large numbers of flows with local endpoints while keeping buffer sizes down; it also happens to implement TCP pacing.
FQ keeps track of every flow it sees passing through the system. To do so, it calculates an eight-bit hash based on the socket associated with the flow, then uses the result as an index into an array of red-black trees. The data structure is designed, according to Eric, to scale well up to millions of concurrent flows. A number of parameters are associated with each flow, including its current transmission quota and, optionally, the time at which the next packet can be transmitted.
That transmission time is used to implement the TCP pacing support. If a given socket has a pace specified for it, FQ will calculate how far the packets should be spaced in time to conform to that pace. If a flow's next transmission time is in the future, that flow is added to another red-black tree with the transmission time used as the key; that tree, thus, allows the kernel to track delayed flows and quickly find the one whose next packet is due to go out the soonest. A single timer is then used, if needed, to ensure that said packet is transmitted at the right time.
The scheduler maintains two linked lists of active flows, the "new" and "old" lists. When a flow is first encountered, it is placed on the new list. The packet dispatcher services flows on the new list first; once a flow uses up its quota, that flow is moved to the old list. The idea here appears to be to give preferential treatment to new, short-lived connections — a DNS lookup or HTTP "GET" command, for example — and not let those connections be buried underneath larger, longer-lasting flows. Eventually the scheduler works its way through all active flows, sending a quota of data from each; then the process starts over.
There are a number of additional details, of course. There are limits on the amount of data queued for each flow, as well as a limit on the amount of data buffered within the scheduler as a whole; any packet that would exceed one of those limits is dropped. A special "internal" queue exists for high-priority traffic, allowing it to reach the wire more quickly. And so on.
One other detail is garbage collection. One problem with this kind of flow tracking is that nothing tells the scheduler when a particular flow is shut down; indeed, nothing can tell the scheduler for flows without local endpoints or for non-connection-oriented protocols. So the scheduler must figure out on its own when it can stop tracking any given flow. One way to do that would be to drop the flow as soon as there are no packets associated with it, but that would cause some thrashing as the queues empty and refill; it is better to keep flow data around for a little while in anticipation of more traffic. FQ handles this by putting idle flows into a special "detached" state, off the lists of active flows. Whenever a new flow is added, a pass is made over the associated red-black tree to clean out flows that have been detached for a sufficiently long time — three seconds in the current patch.
cake
The CAKE Principle:
(or, how to have your cake and eat it too)
This is a combination of several shaping, AQM and FQ
techniques into one easy-to-use package:
- An overall bandwidth shaper, to move the bottleneck away
from dumb CPE equipment and bloated MACs. This operates
in deficit mode (as in sch_fq), eliminating the need for
any sort of burst parameter (eg. token buxket depth).
Burst support is limited to that necessary to overcome
scheduling latency.
- A Diffserv-aware priority queue, giving more priority to
certain classes, up to a specified fraction of bandwidth.
Above that bandwidth threshold, the priority is reduced to
avoid starving other classes.
- Each priority class has a separate Flow Queue system, to
isolate traffic flows from each other. This prevents a
burst on one flow from increasing the delay to another.
Flows are distributed to queues using a set-associative
hash function.
- Each queue is actively managed by Codel. This serves
flows fairly, and signals congestion early via ECN
(if available) and/or packet drops, to keep latency low.
The codel parameters are auto-tuned based on the bandwidth
setting, as is necessary at low bandwidths.
The configuration parameters are kept deliberately simple
for ease of use. Everything has sane defaults. Complete
generality of configuration is not a goal.
The priority queue operates according to a weighted DRR
scheme, combined with a bandwidth tracker which reuses the
shaper logic to detect which side of the bandwidth sharing
threshold the class is operating. This determines whether
a priority-based weight (high) or a bandwidth-based weight
(low) is used for that class in the current pass.
This qdisc incorporates much of Eric Dumazet's fq_codel code,
customised for use as an integrated subordinate.
How to apply a packet scheduler:
1. Open terminal on your device
2. Use the "su" command to become root
3. Use tc to change the packet scheduler(qdisc) on your device. I have included an example below, the first line is for WiFi and the second for data. In the example, we are setting the qdisc to fq_pie, which is a mix of PIE with per flow rate shaping from fq.
Code:
tc qdisc add dev wlan0 root fq_pie
tc qdisc add dev rmnet_data0 root fq_pie
4. Confirm your packet scheduler has been applied by using the tc tool again. I have included an example below.
Code:
tc qdisc
To use another packet scheduler after applying a previous one, you will need to either reboot or remove the added qdisc from each interface using the command I have included below.
Code:
tc qdisc del root dev wlan0
tc qdisc del root dev rmnet_data0
zzmoove Breakdown:
To set a zzmoove profile using a kernel tweaker such as kernel adiutor, put the corresponding profile number into the tunable labeled "profile_number". I have included a description of the profiles below from @ZaneZam over here: http://forum.xda-developers.com/showpost.php?p=42637787&postcount=3
1 - for Default (set governor defaults)
2 - for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
3 - for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
4 - for ZaneZam Battery -> old untouched setting (a more 'harsh' setting strictly focused on battery saving DEV-NOTE: might give some lags!)
5 - for ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting (DEV-NOTE: recommended too! )
6 - for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
7 - for ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online
8 - for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
9 - for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
10 - for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
Will this work with CM12 nightly builds?
Sent from my Nexus 6 using Tapatalk
violentbydezign said:
Will this work with CM12 nightly builds?
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Yes sir!
Righteous
Sent from my Nexus 6 using Tapatalk
Well that was a fast leave of absence lol...I was just doing my daily routine of reading through my XDA threads and found this new revision of your kernel. I think i pissed off my sleeping girlfriend by shouting with excitement, oops (totally worth it though). Glad you came back ripng, er, DespairFactor. Keep up the great work!!
downloaded now time to play
thanks op
Sweet man. Thanks for continuing on....
@DespairFactor would you please add up the Kernel version in the title too.
Thanks
dany20mh said:
@DespairFactor would you please add up the Kernel version in the title too.
Thanks
Click to expand...
Click to collapse
I will when I am on R2
In for execution......
You´re fast my friend hahaha... Thanks for staying with us.
R2 is up, I added a changelog to the OP
Does your kernel still support all cores on all the time with mako hotplug?
Sent from my Nexus 6
rignfool said:
Does your kernel still support all cores on all the time with mako hotplug?
Sent from my Nexus 6
Click to expand...
Click to collapse
Of course, its part of mako hotplug
Woot your the man, glad to see you back.. Time to feed my addiction, and get rid of the shakes..
Is there a difference between this r2 and the one from a few days ago?
joeyddr said:
Is there a difference between this r2 and the one from a few days ago?
Click to expand...
Click to collapse
Compare the feature lists, its basically a cleaner code base and added only the useful stuff back.
Is force encryption on? I booted the kernel up on a clean flash of Euphoria and it gave me a decryption error? Just juandering.
bmg1001 said:
Is force encryption on? I booted the kernel up on a clean flash of Euphoria and it gave me a decryption error? Just juandering.
Click to expand...
Click to collapse
Never, I would never force anyone to encrypt their device I don't encrypt mine and obviously I would run my own work

android db (SQLite, Realm or Redus)

I have a to chose between those Database :SQLite, Realm or Redux
witch one is the best for regular db update ?
Hi smauh117, this is my opinion:
Persistence - why Realm, not Room (SQLite)?
Room Persistence Library is a part of google's android acrhitecture components announced Google IO 2017. It provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite, works well with LiveData.
But, SQLite is not simple, and relational database is not easy for a lot of android developers. In almost android application, local database is offen used for data caching only, and isn't center of bussiness processes.
Realm is a mobile database, a replacement of SQLite and ORMs. It is much more simple than SQLite, but really powerfull, easy to learn in minutes, not hours, for every mobile deveopers, both Android and iOS. Even "Realm Database is much faster than an ORM, and often faster than raw SQLite". With lazy data loading, your app can easy to archive better performance and user experience, it's really difficult if you are using Room.
Room works well with LiveData and lifecycle aware to prevent memory leaks, how about Realm ?
It dosen't matter, Realm can easy to adapt with LiveData, read more: Android Architecture Components and Realm.
For full article and source code, please visit my project here.
I also created this project to compare Realm and SQLite (with ROOM). Please checkout different branches.
Thank you
:good::good:
smaug117 said:
I have a to chose between those Database :SQLite, Realm or Redux
witch one is the best for regular db update ?
Click to expand...
Click to collapse
AFAIK: Redux is an architectural pattern and not a database like Realm and what do you mean by "regular db update" ?
Anyway, Google's Room is a pretty good and established abstraction layer over SQLite on Android. I don't recommend Realm because there're a couple of pitfalls regarding multithreading. If you don't want to use SQLite + Room check out Objectbox.
smaug117 said:
I have a to chose between those Database :SQLite, Realm or Redux
witch one is the best for regular db update ?
Click to expand...
Click to collapse
SQLIte/Room may not be the best option depending upon what you actually mean by regular db update.
That is SQLite and therefore Room (Room being an abstraction layer over SQLite) is intended as an embedded database and thus each device has it's own distinct database and synchronisation with external data would have to be coded/developed, just pulling data from one source wouldn't be overly difficult. However, two/multiple way/device synchronisation would introduce complexities and hence why many solutions use other databases that are intended as a client server solution (e.g. MYSQL for example).
Firebase, not that I've used it, could be a solution as this is a client/server solution and is designed for Android use.
Personally I find native SQLite easier and therefore faster to use than Room. I've never used Realm.
it depends on your data architecture, if you'd like to use a non relational database just go with Realm, it's like mongo for mobile apps, otherwise there is Room, which represent the relational database by using Sqlite.
@MJT said:
SQLIte/Room may not be the best option depending upon what you actually mean by regular db update.
Personally I find native SQLite easier and therefore faster to use than Room. I've never used Realm.
Click to expand...
Click to collapse
I completely agree. I use SQLite to save user preferences in the application. It is simple and stable.
And this is a cross-platform solution (not only for android).

Categories

Resources