Dienstag, 18. August 2015


Here is latest SOLUTION for the from me very hated ANTI PIRACY CONTENT ERASE "feature" in new/latest Lollipop 5.1.1 roms.
At first u have to download the zip from my drivelink:
when down just extract the zip and u will find the following files:
1. XposedInstaller 3.0 Alpha 4
2. xposed-v71-sdk22-arm-by-romracer-20150816
3. DisableContentGuard 2.1
let this files untouched and follow the steps below!!!!
Install/flash the Xposed Framework.
Now install XposedInstaller_3.0_alpha4,its a must to have this version.
Now simply install the DisableContentGuard.apk and enable it in Xposed and reboot,done.
Now all is like without the anti piracy trash.Lucky Patcher etc is running perfect again.
Tested on several Lollipop 5.1.1 roms by me and some others.
Big thanx and credits to the awesome devs of following apps:
Xposed Framework/Xposed Framework installer
Lucky Patcher
Have Fun and Greeeeeeeeetz!!!!!

Samstag, 6. September 2014

WPA / WPA2 cracking [BackTrack]-KaliLinux

Here I will explain how to crack a WPA or WPA2 network. 

With the linuxdistro called BackTrack 5 from following link



• Backtrack on CD or USB 

• Computer compatible with 802.11 WLAN Card 

• Wireless Access point or WIFI router WPA / WPA2 encryption used 

• A Word List (use google u find many) 


1.BackTrack Start 

Boot your USB stick or your CD / DVD (depending on which BackTrack version you are) 

Now start BackTrack. 

After the boot process is finished you have to type:


and then:


Enter to access the Graphical interface of BackTrack. 


2.Now we start! 

Open a shell. 

Here type:


one to find out how your wifi adapter is called. 


3.Change the Mac 

Now you know the name of your adapter. (in my case it is wlan0, so I use from now on wlan0 as interface.) 

You should change your Mac address that can not be traced back to you later.

Code below:

airmon-ng stop wlan0 

ifconfig wlan0 down 

macchanger --mac (any mac) wlan0 

airmon-ng start wlan0 

It should look like this: 

airmon-ng stop wlan0 

ifconfig wlan0 down 

macchanger --mac 00: 11: 22: 33: 44: 55 wlan0 

airmon-ng start wlan0 


4.Choose Network

Now you type in the same shell:


Now the networks are looking for. 

On the left we see the BSSID something like the Mac from the router. 

If the wished network found, we press Ctrl + C to stop the whole process 

Now you copy the BSSID of the desired network.

5.Lets Go

Now you have to find the Channel


airodump-ng-c (channel) -w (filename does not matter what just take wpa or what is easy to remember.) --bssid (BSSID) wlan0 

we write our received data in a file. 

For example: 

airodump-ng-c 11 -w wpa --bssid 00: 14: F8: 4F: 14: 1A wlan0 

With this command we will write our wifi network XY with the BSSID 00: 14: F8: 4F: 14: 1A 

sending on Channel 11, all received data in the file 'wpa-01.cap' 

On WPA/WPA2 its not possible to decrypt the password,like on WEP. 

For this we need a 'handshake'. 


6.The handshake 

Our client is connected to the router ,which send with every new application the password in encrypted manner.

We might wait a (likely) forever to get our client reconnects.

But we must not.

In our shell we see below who else is online. If we get a handshake,

we see the top right in the shell. There is then 'handshake'. 

We now open a new shell to our clients throw out that he needs to reconnect. 

And type: 

aireplay-ng -0 5 -a (BSSID) wlan0 

5 is the number of tries we want to try all. 

But it is not mandatory that all works because newer routers dont allow this anymore. 

How do we get the client to disconect?

Is relatively simple. We tell the router: "Hello I'm user XY and would like like to log out." 

So we throw the client out:  

aireplay-ng -0 1 -a (BSSID)-c (Mac client) wlan0 

The Mac client we see below in shell1. 

Now we should have a handshake. 


7.Crack it! 

If we have a handshake, we can undisturbed close all our shells, and open a new one. 

In this we type: 

aircrack-ng (filename) -01.cap 

Now we need the wordlist

We now go to our Word List which is for example here. 

/ home / wordlists 

In my example, is called the Word List 'Wlist.txt'. 

Now we enter the following in the Shell:

aircrack-ng (filename) -01.cap -w (path to the Word List) 

with me Would it look like this:

aircrack-ng wpa-01.cap -w /home/wordlists/Wlist.txt 

Now the program tests all words if they match the encrypted handshake. 

If the password is found, it will be shown and youre done.




Mittwoch, 2. April 2014


Windows 8.1-Update 1,download and install it now!!!!!


Sitelink is in german language but very easy,i translated to english.




Go to this "LINK" and click on the lil black point,as you can see in picture below.

After this you see the files for different systems

Choose the files depending to your system.

32bit or 64bit or ARM-Windows 8.1 RT

Download ALL files you see,like in the picture below



Its required to install the appropriate updates in the order specified here and start your computer after each update!Files are have numbercodes.


1. install - KB2919442 then KB2939087 and reboot your pc.

2. install - KB2919355 and reboot your pc.

3. install - KB2932046 and reboot your pc

4. install - KB2938439 and reboot your pc

5. install - KB2937592 and reboot your pc

Thats it,you have updated to Windows 8.1 Update 1 which is not official released yet,but its final,no fear.



Montag, 24. Februar 2014

Latest Beta version from CyanoGenMods Gallery Next App

Exclusive here on my blog,just for test,have fun.Its a great App!!!!!!!




Samstag, 1. Februar 2014


CALIBAN666 IS ADDICTED TO FLASH: WHAT´S WHAT IN THE LINUX DIRECTORY STRUCTURE? A IN...: File Hierarchy Standard While the Windows systems still retain characteristics such as the drive letter and the backward slash as a directo...


File Hierarchy Standard

While the Windows systems still retain characteristics such as the drive letter and the backward slash as a directory separator, the other operating systems such as Mac OS X and Linux, also root have long been approached and agreed on a common directory structure, starting from the root directory "/" called.
That there is such uniformity in terms of directory contents and descriptions, is the so-called Filesystem Hierarchy Standard, thanks to short FHS. This describes the development of a Unix directory system.The current version 2.3 is dated January 2004.
The FHS is interesting on the one hand for distribution developers , but it describes where the directories and files are found. On the other hand, the user benefits from this by quickly finds his way into other Linux and Unix variants without great incorporation .Order must be: The Filesystem Hierarchy Standard describes the structure of a Unix directory system.Order must be: The Filesystem Hierarchy Standard describes the structure of a Unix directory system.Nor is anything else important for the system administrator , however : there are no drive letters , partitions, hard disks and other storage media such as USB drives and DVD drives are easily integrated as a directory in the directory structure. The expert speaks of hanging or mounting.Theoretically can be hooked at any location directory. In practice, not that happens . For there are certain places that are provided of how the / tmp or / mnt . However, you can make when putting a server of this fact , by distributing the system on multiple disks or partitions. Anyone who hires sent , prevents , for example, an uncontrolled overflow of the physical memory or can quickly move the user data to another server in the event of a fall .----------Root (/)

Is the root , the root represented by the slash at the top of the whole UNIX directory system. What does the root file system must be sufficient to boot a Linux system or repair . These diagnostics , backup and restore utilities are also required, as configuration files and boot loader information . Important commands such as mount must therefore be directly accessible. But in the root directory typically is nothing except the directories , it is imperative that the appropriate subdirectories , including the programs are also present on the root partition.Very big the root file system has still not to be. On the contrary : It is advisable to keep this as small as possible in order to possibly run it from a USB stick can . In addition, a small root partition is less susceptible to damage , such as due to a system crash .--------------/bin

The / bin directory must be on the root partition. There are important Unix commands that can be executed by all users. These commands need to be executed if no other file system is mounted. In the / bin directory under other system commands for file permissions are (chgrp, chmod, chown), copy, create, move and delete directories and files for logging and mounting of file systems, the shell sh and the su program, with which you can change the user ID.
In /bin The archive also tools tar and cpio and gzip and gunzip programs pack. With this the administrator can recover a system if the root file system is intact. There is also the network statistics tool netstat and ping to test network connections. Should it be possible to repair a system on the network must also ftp or tfpt and its associated utilities available for an FTP connection.-------/ boot
 The directory must not be on the root partition. It contains the static files of the boot loader and all other necessary files to boot up. Here is also usually the system kernel, if it is not to be found in the root directory.-------- / dev
 Also, the / dev directory or its contents will be needed on the root partition. In this directory are character-oriented and block special files through which the access to devices such as hard drives and DVD drives or interfaces is controlled.-----/ etc

The / etc directory is as much on the root partition . After all there and in the underlying directories are the files for the system configuration. Some of the directories under / etc must be present on any Unix system , while others are optional . The configuration files for the X Window subsystem , so the graphics server , can be found in the / etc/X11 directory . There may also be the directory / etc / opt. There you will find in appropriate subdirectories , configuration files from the packages from the / opt directory .---------/ home

The / home directory hierarchy can be on anything other than the root partition. It contains the subdirectories the respective home directories of users. The names of the different home directories are identical to the user name. Your own home directory is the one to which a user has all access rights. Here he can create directories , delete files and store its own configuration data.
It makes sense to the / home hierarchy on its own partition, or even better: hard drive to create, and this for several reasons: there are no Benutzerquotas available, a user can bring the entire system to overflow. Another advantage of the physically separate / home hierarchy: one can relatively easily update a system and prevents the user directories then ON again. / lib, / lib32 and / lib64
 The / lib directory, in turn, must be on the root partition. This also applies for the corresponding 32 - or 64-bit libraries that are available in the respective subdirectories. Because these directories contain shared libraries and kernel modules, ie files with statements and definitions that are needed by multiple programs or loaded by the kernel. The libraries are needed to boot the system.-----------/ media
 Even / media belongs to the root partition. There, however, it takes hardly any space, because the directory is actually empty. It only serves as a mount for floppy disks (/ media / floppy), CD and DVD drives (/ media / cdrom / media / cdrecorder, / media / dvd) or Zip disks (/ media / zip). On systems with more than one same device can exist, which all end with a number of other directories (such as / media/cdrom0 and / media/cdrom1 for two CD drives), but even in such cases should continue to be the unqualified name (/ media / cdrom) remain. In some distributions there is also directly below the root directory mount points such as / cdrom. This does not correspond to the FHS. The reason given against such directories FHS authors argue that the same stood by mount points in the root of some more directories at the root level.-----/mnt

For the directory / mnt, the same applies as for / media: It should also be on the root partition. The list is as empty as / media and intended to temporarily mount a file system. This uses the administrator about this, make a backup or mirror disks. The bad habit, / mnt to use the directory for the mounting of drives, is in conflict with this Unix tradition.---/opt

The / opt directory is not needed for booting the system and can be outsourced to the / home directory to another partition. It serves to accommodate additional software packages which are not installed via the package manager. These are then available in the directory / opt / <package> / bin or / opt / <Provider>, manual pages for the programs are placed in / opt / <package> / share / man filed. Configuration files for these packages are stored in / etc / opt, variable data programs are usually in the directory / var / opt installed.----/ proc
The / proc directory is mentioned in the FHS only in the appendix. There is no standard Unix directory in Linux but it is the de facto standard for managing process and system information. Other derivatives make the example in the / dev / kmem. The / proc directory does not need to be on the root partition.--- / root 

The administrator not only has all rights, he also has his home directory is not in the same place as the ordinary user, but directly under / in the / root directory. The directory must not necessarily be present on the root partition. Then, make sure that it points to the root directory if it can not be located.-------/ sbinThis directory must exist on the root partition again . It contains programs for system administration . Even these, are still in the same directories / usr / sbin and / usr / local / sbin .Different: The specific features of Linux devote the authors of the FHS a separate chapter.Anders: The specific features of Linux devote the authors of the FHS a separate chapter.However sbin directory are / as opposed to the other two commands for booting , data recovery and restoration are required in addition to the commands in the / bin directory. Here , for example, are programs such as stop shutdown , fdisk to partition and fsck programs for checking the file systems. In the / usr/sbin- and / usr / local / sbin directories instead are programs that are used only after mounting the / usr directory.-----/ srvThe / srv directory must not be on the root partition. It contains data for services provided by the system, such as CGI scripts or data from a Web or FTP server. In most cases the data are sorted according to the protocol , ie www , ftp, rsync or cvs .---------/ tmpThe / tmp directory must not be included on the root partition. It is used for programs that generate the temporary files. Even users have write permission to this directory. Temporarily store files there but not makes sense , because the Posix standard recommends that data be deleted from the / tmp directory at the latest at every system startup . On some systems the / tmp directory is deleted regularly via cron job .----/ usrThe second largest area in the System directory is the / usr directory hierarchy. This area must not be on the root partition , because important system commands are either under / bin or under / sbin . In / usr , however, are available for each readable data ; Host-specific or other variable data is not stored here . In the / usr hierarchy , there are several directories that are required:In stand most user commands ,- are in header files for the C programming language,- contains libraries ,- contains the hierarchy of the local machine ( and is nitially after installation mostly empty) with the subdirectories and- does not contain quite as important utilities for the administrator to be used only after booting the system , and- in are architecture-independent data such as dictionaries , man pages or program documentations.------Depending on the configuration of the system , there are other sub-directories such as / usr/X11R6 with the X Window System , / usr / games with games and / usr / src with the source code. Also, on older systems, for compatibility reasons, various symbolic links on Unterzeichnisse of / var be present , such as / usr / spool as a link to the directory / var / spool . Reason for the shift : In the directory / usr is often accessed . However, it should not be fragmented by writing and deleting temporary data, since this would affect the throughput .----------/ var In / var, see files with variable data. Also, this directory must not on the root partition. Under / var are, for example, spool directories for mail users' mailboxes or print jobs, log files (eg, the file / var / log / messages with system messages) and also some other temporary files. All the data is written to the / var directory structure during operation, the previously found under / usr place. The directory hierarchy / var should be stored on a separate partition, just because in so many variable data are included. Who does not want or can, at least this part of the directory hierarchy should not harbor on the same partition as the root partition. Because it can quickly lead to an overflow of partition, for example, if the mail transport constantly producing errors and the log files full writes to the edge of the partition.----------Recommendations for a partition scheme To partition a Linux system, there are several possibilities. Most importantly, the root partition "/" must always physically contain / bin, / dev, / etc, / lib (/ lib32 and / lib64) and / sbin included. In Debian you go from about 150 to 250 MB of space for these directories. Ins / tmp directory users can write. It can use, among others, for images that are to be written to CD, DVD or Blu-ray. Some of these programs use the / tmp directory to temporarily storing therein data itself. Anyone who uses such burning programs should therefore schedule the space accordingly and reserve about 1 to 20 GB for the / tmp directory. Who does not use burning program that comes with much less space for the temporary directory. The Debian installation guide speaks in the case of 40 to 100 Mbytes of space.The / usr directory hierarchy is the part of the file system, which first requires the most space. According to the Debian installation instructions must be reserved for a generous workstation or server installation 4-6 GB. The / var directory hierarchy contains variable data. Here mails and software packages are cached, written log files and stored databases. In Debian the subdirectory / var / www is FHS-unkonform instead of / srv / www still used for Web pages. The size of / var strongly depends on the usage of the system. The space required can vary from 30 MB up to several GB.----------In / home mount the directories of the users . Accordingly, the size of the number of system users depends. According to the Debian installation instructions you should reserve at least 100 MB. Which these days is however rather ridiculous given the amount on MP3 files , photos and movies, store the user on the system. Here, the recommendation can only be : Make as much space available.Although it is generally made with a disk and a partition. But Cleverly is the use of at least two hard drives. A disk may contain the system , the other home directories . So you can quickly take over the / home directory hierarchy to another system . The home directories , you can also manage the Logical Volume Manager , It has the advantage that you can add more partitions of the directory tree if necessary easy.On the system disk again you should at least for / var, and / tmp define your own partitions - for / tmp , because all the write in the directory / var from the already mentioned reason : Does the partition becomes full , for example because the computer flooded with spam is , at least the rest of the system still responds . Tip: Anyone who has to worry about such a thing, and the directory / var / mail can swap on a separate partition .Another partition, you can provide for the swap space . Although the cache may simply lie in a file. Efficient However, it is this to treat a separate partition. It divided in their opinions as to whether the should be on the system board or elsewhere: Some are of the view swap space and the system should be on different SCSI or IDE channels . As a size recommendation is available in Linux circles, the Pi -by- Rule of thumb : The swap partition should be as large as the RAM .---------Current project UsrMove Many well-known distributions such as Fedora 17 have currently to some directories. This is to / bin, / sbin, / lib and / lib64, which migrate to the directory / usr. It was suggested this cleanup the directory structure of the developers of Fedora distributions like Gentoo and openSUSE (suggested for version 12.2) will follow. The initiative, known as UsrMove the root tree is to act tidier, the sharing of / bin and / usr / bin is also more confusing than useful. The compatibility with the existing structure is still maintained by symbolic links. When and if the modified directory structure flows into the FHS standard, is currently unknown. (MJE / cvi / tecChannel)-------------------SO THATS ALL,I HOPE IT HELPS A LIL BIT!!!I WISH A NICE DAY AND MANY GREEEEETZ!!!-CALIBAN666- 2014------------------

Montag, 18. November 2013


About ART-Dalvik replacement-feature which comes with Android 4.4 KitKat

It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.

What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.

At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.

How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.

What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!

By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.

Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.

How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…

Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.

Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.

3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.

AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.

For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.

Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.

The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.

To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.


Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.

Introducing ART from: source.android.com

ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.

Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.

Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)

The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.

A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.

Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart

                                               MANY GREEEETZ+STAY ADDICTED!!!!