Database Info

Is it possible to make the G1 run native file types?

I was thinking last night, that maybe by recreating the entire system.img and userdata.img we can add more files the G1 can read.
but
I guess it will take a long time but if all extreme developers pitch in then we can get it done in no time.
Maybe we can add more than just native file types... this could be an innovation.

What exactly are you asking about?
Running software written in, for example, C?
This is possible right now to a certain extent. Terminal software (i.e. text only) can be cross compiled and run from the terminal. This is not a challenge, or for that matter, even particularly innovative.
What I suspect you are after is more along the lines of running GRAPHICAL software that is compiled for the native hardware. Neat idea, would be ok for now, but this will introduce SEVERE problems once other hardware shows up. Code that is compiled in a native executable format can only run on the same hardware (or sufficiently similar) as that for which it was compiled, so if you had software compiled for one hardware set, it will NOT work on another. That is the reason why the UI is all JAVA.

lbcoder said:
What exactly are you asking about?
Running software written in, for example, C?
This is possible right now to a certain extent. Terminal software (i.e. text only) can be cross compiled and run from the terminal. This is not a challenge, or for that matter, even particularly innovative.
What I suspect you are after is more along the lines of running GRAPHICAL software that is compiled for the native hardware. Neat idea, would be ok for now, but this will introduce SEVERE problems once other hardware shows up. Code that is compiled in a native executable format can only run on the same hardware (or sufficiently similar) as that for which it was compiled, so if you had software compiled for one hardware set, it will NOT work on another. That is the reason why the UI is all JAVA.
Click to expand...
Click to collapse
Hmm, what about if you had an app that compiled the c code(akin to gcc but in apk form) aand executed the app from there? In theory that'd give you a little app launcher from which you could run native apps... plus it should be a lot faster than the java code of apks

Android Native Development Kit RELEASED

Check it out here:
http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html

Yes, I heard they were making this actually happen...
As for building Apps in C/C++ Native..
Pros:
-More Stable
-More Unique (no Android UI features unless integrated)
-More Sophisticated
-Will open to a more known (learned) framework, by this I mean if you know C/C++ and already have apps built for other mobile devices it should be much easier to port it over to Android (look out for the flood Android Market)
-Other open sourced / commercial apps will be more easily ported...some ideas?...START A THREAD!!!...but just for the record...Apache...FireFox...just about anything that has an open source that relies on C programming...crap you can even extend this by adding Ruby, Perl...etc.
-Remember, this is a Development Kit...it just adds tools to the 1.5 SDK that allow you to create C based applications and build them in the android environment. All your apps should still work going back to RC-30 or even further back...depends on the kernel support I would guess.
Cons:
Much Larger Apps (file size)
Need to learn how the Linux Kernel works (for developers)
Other:
Load times? Ok, so for example if you have one app...say...TuneWiki...just an example of a popular resource hog...if it were to be redeveloped under C++ and optimized for the Android Modified Linux Kernel...your resources could easily be cut in half since you are not relying on the Dalvik VM.
SO...outcome?
Better for all, as long as you know what you are doing.
We should also see a huge upswing in crapware on the market from student programmers doing C++ projects on an easy open-sourced mobile platform (that has a public SDK).
So you'll see a lot of "Hello World" type apps that will have next to no function...have fun with those...................
From the Official NDK User Forum: Link

acidnine
Very nice post. Thanks for the insight.

acidnine said:
Pros:
-More Stable
Click to expand...
Click to collapse
The opposite actually. Poorly written interpreted code breaks elegantly in a vm. Poorly written compiled code can take a whole system down.
-More Unique (no Android UI features unless integrated)
Click to expand...
Click to collapse
You can't integrate any Android frameworks (UIs, etc) period.
-More Sophisticated
Click to expand...
Click to collapse
I've seen some very sophisticated Java and some **** C/C++. Don't assume that higher level programming languages are necessarily less sophisticated than lower level ones.
-Will open to a more known (learned) framework, by this I mean if you know C/C++ and already have apps built for other mobile devices it should be much easier to port it over to Android (look out for the flood Android Market)
Click to expand...
Click to collapse
The NDK will enable some applications that couldn't previously have been done in the Dalvik vm for performance issues, but it isn't going to be a "flood". Fact of the matter is a lot of developers who have needed native performance or didn't want to rewrite a C/C++ codebase have deployed native code already.
but just for the record...Apache...FireFox...just about anything that has an open source that relies on C programming...crap you can even extend this by adding Ruby, Perl...etc.
Click to expand...
Click to collapse
FF is written in C++... [edit: I should also point out that the NDK provides for native code support in the form of libraries (mainly as a helper for computation-intensive functions). Nothing in the way of window managers or other UI is addressed, meaning for the majority of "visible" C/C++ apps the developer would have to rewrite a significant portion in Java still.]
Cons:
Much Larger Apps (file size)
Need to learn how the Linux Kernel works (for developers)
Click to expand...
Click to collapse
I don't know what to say other than these two statements are generally incorrect. There are two main cons to using NDK as opposed to the standard SDK, and they are 1) Reduced (or no) compatibility on future Android devices 2) Significantly reduced ease of debugging.

very interesting...subscribed

jashsu said:
You can't integrate any Android frameworks (UIs, etc) period.
Click to expand...
Click to collapse
Not true. This isn't full native code apps, this is the ability to call native libraries in a davlik app.
From the actual NDK page ...
The NDK provides:
A set of tools and build files used to generate native code libraries from C and C++ sources
A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
Documentation, samples, and tutorials
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Click to expand...
Click to collapse

.milFox said:
Not true. This isn't full native code apps, this is the ability to call native libraries in a davlik app.
From the actual NDK page ...
Click to expand...
Click to collapse
Correct. As I pointed out above, the NDK actually is just a framework for building native libraries that standard dalvik apps then call. However, my point was that the libraries themselves (the products of the NDK) cannot access or invoke the Android framework. There is a pointed distinction.

At least this could mean the beginning of some video codec porting to the G1's hardware. Be nice to be able to actually make use of my video collection without having to reencode everything.

neonrush said:
At least this could mean the beginning of some video codec porting to the G1's hardware. Be nice to be able to actually make use of my video collection without having to reencode everything.
Click to expand...
Click to collapse
That is probably what the NDK is perfect for. It's CPU intensive stuff, already written in platform independent C/C++ that can then be called from within a nice Androidy UI.

So they basically added JNI to the SDK...

http://en.wikipedia.org/wiki/Java_Native_Interface

Does the 1ghz processor on WP7 fully utilised?

Can anyone with experiences or skillful developers answer my question?
every time when I opening up an application which i downloaded from the marketplace(non-stock apps),the speed was like i open an app on my iphone 3g,laggy and sluggish.
Honestly,the wp7 experience is not that great for me CURRENTLY and I don't have much money like M$,if not I could buy a second gen wp7 device.So,is it possible mango will fix everything up?or just the 1ghz processor is not good enough to run wp7?
I would prefer windows mobile 6.5 with wp7 animation&transition,then i'm good to go.

now this could be a novel question
but could it be the application itself? you even said native programs are smooth....

yea,true,native apps are buttery smooth.However,in other apps are so laggy.any solution for these problems?is it related to the APIs or the OS itself?

It's related to developers running business and dal code on the ui thread.
Give it time, devs will learn how to do it properly, especially with the new tools coming in VS soon.
1Ghz is plenty, and barely relative.
Is the Xbox fast enough? Of course, even 5 years after - because devs know how to utilise it properly, and build FOR the platform, not blame the platform for their inefficient code.

sylau90 said:
Honestly,the wp7 experience is not that great for me CURRENTLY and I don't have much money like M$,if not I could buy a second gen wp7 device.So,is it possible mango will fix everything up?or just the 1ghz processor is not good enough to run wp7?
Click to expand...
Click to collapse
Mango will fix a lot of it, developers need to fix some of it as well.
http://www.mobiletechworld.com/2011...overview-32bit-color-support-better-controls/

thanks mate @PG2G,thats really helpful and looks promising...can't wait for mango

domineus said:
now this could be a novel question
but could it be the application itself? you even said native programs are smooth....
Click to expand...
Click to collapse
Microsoft and oems cam use native code. Thirsting party developers cannot. That is why stock apps perform perfectly but third party apps suffer.
Developers can fix it by stripping out all the eye candy from their apps but then your left with a modern day textual user interface...
I hope they open up some native apps soon. Even in desktop apps the performance advantage odd an mfc oems or Delphi app is immediately apparent compared to their .net counterparts, even with beastly hardware.
Better hardware and os-level optimization will help the situation soon, though...
Sent from my SGH-T959 using XDA App

3rd party apps are all written in .NET managed code. When the app first loads, it needs to be compiled into native code and also instantiate inside a SliverLight player. Both take extra processing power and time compared to native apps that need to do neither tasks. I'm sure MS will continue to optimize the speed of JIT and SilverLight player. It will never match the native app load speed but it also won't bring down the entire OS if something goes wrong like the native apps potentially could do.

foxbat121 said:
3rd party apps are all written in .NET managed code. When the app first loads, it needs to be compiled into native code and also instantiate inside a SliverLight player. Both take extra processing power and time compared to native apps that need to do neither tasks. I'm sure MS will continue to optimize the speed of JIT and SilverLight player. It will never match the native app load speed but it also won't bring down the entire OS if something goes wrong like the native apps potentially could do.
Click to expand...
Click to collapse
.NET can precompile assemblies. That is what NGen does on the desktop. I'd find it quite odd if all of the base OS assemblies (entire .NET framework, etc.) isn't NGen'd on the phone. In fact, it would be pretty amatuer for Microsoft not to do that.
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.
Click to expand...
Click to collapse
Issues at play:
1. Older SoC with Older GPU in it: The phones would obviously perform better with a newer 1GHz Snapdragon or TI OMAP CPU. A Hummingbird would fly (too bad Samsung couldn't use it) with WP7.
2. Overreliance on Managed Code: This will get better as software is optimized more (the base platform) and WP7 users move to newer devices. But Managed Code, while not far behind Native code in many instances, just can't touch Native code in many places. You could develop MFC applications for Windows Mobile. .NET CF applications could not compete with those applications for performance.
3. Resources: Stock Apps do Multi-Task and in many cases you cannot truly exit them. If those apps are in the background eating up resources, then you will get worse performance.
Expanding on that, and of particular interest is RAM. Devices say they have 512 MB RAM but most devices have 128 MB dedicated to the GPU. The system and applications cannot use that for general purpose tasks. So while you may think you have 512 MB RAM, you really only have a configuration equivalent to 384 RAM with a 128 MB Graphics card in your phone. 128 MB is a large percentage of 512 (though a small number), and it can have performance implications on the device.
This is why HTC added an extra 64 MB RAM in their HD2/7 devices. The HD2/HD7 have 576 MB RAM, but 128 MB is dedicated to the GPU, so the system/apps really only has access to 448 MB of that.
4. Module dependency: Native Applications written in something like Visual C++ (MFC) or Delphi/C++Builder (VCL) don't really have that many module dependencies. That's why their load times are ridiculously fast. .NET applications have large module dependency chains and have to load in many cases a lot more libraries. There's a huge difference between loading the C++ Runtime and an MFC Shared Library (assuming the app was NOT statically compiled) and loading the app and having it daisy-chainload 20 different modules into memory.
Not to mention Native Applications can be multi-tasked much better because well written native apps tend to not use as much RAM.
On PCs this is less of a problem these days, since CPUs/RAM and even Hard Drives (SSD, etc.) are so fast and we have tons of RAM. But on phones, all of these factors can have factorably performance implications (excuse the redundancy).
But it is only that bad in certain types of apps - particularly those with long lists and tons of eye candy in the user interfaces. It should get better with updates.
P.S. There are ways to sandbox Native Apps, as well

Bypassing PatchGuard...?

So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.
In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.
I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.
I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)
However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.
The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.

please release your jailbreak so that other people can help you.

If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.

why not change the variables back after you launch your unsigned exe?

windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?

Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Cheers!

bfosterjr said:
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Click to expand...
Click to collapse
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.
You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.
Defeating PatchGuard would be the optimal experience for users.

...
...

Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.

bfosterjr said:
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.

SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!

Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.

A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.

netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa

As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.

sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.

sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.

netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)

sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)

SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/

Difference between Android Runtime

ART is Google's 2-year-long ongoing secret project, which aims to boost the performance of our Android devices. It's based on the premise that modern devices are pretty powerful in terms of CPU speed and memory capacity, especially in comparison with the first generation of Android devices. In other words,*ART is still in its infancy, considered too unstable to be introduced as a standard runtime. Luckily, there is no special hacking involved to get it running.ART compiles the intermediate language, Dalvik bytecode, into a*system-dependent binary. The whole code of the app will be pre-compiled during install (once), thus removing the lag that we see when we open an app on our device. With no need for JIT compilation, the code should execute much faster.
While Dalvik is based on*JIT (just in time) compilation. It means that each time you run an app, the part of the code required for its execution is going to be translated (compiled) to machine code at that moment. As you progress through the app, additional code is going to be compiled and cached, so that the system can reuse the code while the app is running. Since JIT compiles only a part of the code, it has a smaller memory footprint and uses less physical space on the device.
If you find this helpful please give me a :thumbup::thumbup: thanks for that in advance

Nice copypasta, but you forgot to credit the original author for writing it for you. Allow me to do it for you:
Thanks to Marko Vitas for this informative article! https://www.infinum.co/the-capsized...ntroducing-the-new-android-runtime-in-kit-kat

Hawaiisa said:
Nice copypasta, but you forgot to credit the original author for writing it for you. Allow me to do it for you:
Thanks to Marko Vitas for this informative article! https://www.infinum.co/the-capsized...ntroducing-the-new-android-runtime-in-kit-kat
Click to expand...
Click to collapse
Sorry for that but my younger brother has done that. He knew my password and logged in and just do the copy paste. Bt now I have changed the password

Now have a look at my own words
Dalvik is based on JIT (just in time) compilation. It
means that each time you run an app, the part of
the code required for its execution is going to be translated (compiled) to machine code at that
moment.
ART (Android RunTime) is the next version of
Dalvik. Dalvik is the runtime, bytecode, and VM used
by the Android system for running Android
applications.
ART has two main features compared to Dalvik:
Ahead-of-Time (AOT) compilation, which
improves speed (particularly startup time) and
reduces memory footprint (no JIT)
Improved Garbage Collection (GC)
AOT means your apps are compiled to native code
once. What is stored on your phone and run is
effectively native, not byte, code.