Friday, July 30, 2010

Nokia QT with Visual Studio 2008 and MFC to QT

DOWNLOAD QT SOURCE CODE
As the option to download only the Qt source code is a bit obfuscated on the current Nokia website, please follow these directions:

Go to http://qt.nokia.com/downloads and click the Go LGPL button.
Since you want only source code, look at the Qt: Framework Only column on the right. Click e.g. Download Qt libraries 4.6.3 for Windows (VS 2008, 194 MB) — choose the VS2008 one.


This starts the download for pre-built Qt. But we don’t want that as we will be building Qt ourselves. A page will appear with . Cancel the Save As dialog in your browser to cancel the binaries download you had clicked on, then click on this link, e.g. http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.3.zip
Unzip the file into e.g. c:\qt\4.6.3-vc. Please use a path with no embedded spaces, as the Qt build tools have issues with them.
SET ENVIRONMENT VARIABLES
Open Computer Properties | Advanced system settings | Environment Variables:

Edit environment variable to add: QTDIR = c:\qt\4.6.3-vc
Edit the PATH environment variable to add: %QTDIR%\bin
Either close all command prompts and Visual Studio instances, or reboot... the computer so the new command-line takes effect.
BUILD VC++ VERSION OF QT
Open a Microsoft Visual Studio 2008 Command Prompt, which is a command console with environment variables set for the specified VS. This is easily accomplished using Start | All Programs | Microsoft Visual Studio 2005 (or 2008) | Visual Studio Tools | Visual Studio 2005 (or 2008) Command Prompt.
Cleanup any previous build:
c:\> cd c:\qt\4.6.3-vc
c:\qt\4.6.3-vc> nmake distclean

c:\qt\4.6.3-vc> rm -rf tmp* // <– recursively remove all tmp\ folders and files
I use GNU Tools or even better Cygwin. Cygwin is very useful because you can also build other open source unix source code library including complicated ffmpeg that you may want to link to your QT project. You can download the gnuwin32 package maintenance utility on the sourceforge.net project portal. Cygwin can be downloaded here

3. Run Configure to target platform vc2008:

c:\qt\4.6.3-vc> configure -platform win32-msvc2008


Run Configure with no parameters to see a help screen. Configure generates nmake compatible makefiles to build all the Qt DLL’s, tools, and demos.

4. Run nmake to build.

c:\qt\4.6.3-vc> nmake

It will take awhile, but this grinds through building the specified Qt DLL’s, tools, and demos with Visual Studio.

INSTALL VISUAL STUDIO ADD-IN
The Qt Visual Studio Add-in is indispensible for developing Qt apps in Visual Studio. The Add-in has replaced the previous Qt Visual Studio Integration, which was only available to Commercial customers. Now the Add-in is used by both LPGL and Commercial licensees, and the Integration has been deprecated. While the Add-in does not allow integrated .ui editing (it instead launches Qt Designer to edit .ui files), it is fully supported and maintained by Nokia, whereas the Integration hadn’t been modified since the 4.3/4.4 timeframe.

Because Visual Studio Express does not allow add-ins, using these free versions of Visual Studio is not recommended for Qt development. You need at least Visual Studio Standard (Pro, Team System, etc. of course will also work).

1. Download and install the Qt Visual Studio Add-in to install the Qt plug-in into Visual Studio (both 2005 and 2008 are supported by the add-in).

2. Start Visual Studio.

3. Select menu Qt | Configure Qt Versions. Add c:\qt\4.6.3-vc.

4. Now Qt is fully functional, and you can use VS2008 to build Qt apps.

QT IN VISUAL STUDIO
1. See Qt menu item. Launch Qt Designer (the Resource editor) and Qt Linguist (the localization tool).

2. Create new Qt projects. File | New project, select Qt4 project.

3. Read Qt Help. Available from Help menu (Qt help is merged in with Visual Studio Help and viewed in Document Explorer.) Or, manually launch

C:\Qt\4.6.3-vc\bin\assistant.exe

4. The Whole Tomato Visual Assist X plug-in is highly recommended to develop Qt within Visual Studio

=====================================

How to generate a vc proj from a .pro QT file

there are two ways to do it.

1. On the command line with "qmake -tp vcapp -r yourProfile.pro"

Ensure that the QMAKESPEC environment variable is set to the appropriate value.
If you use Visual Studio 2008, then win32-msvc2008 is the correct value.

To set your environment variables in Windows, please see http://en.wikipedia.org/wiki/Environment_variable
Note that you may have to re-open a command window before your settings are changed.
To check that your PATH is set correctly:
C:\> qmake -v
QMake version: 2.01a
Using Qt version 4.6.3 in C:\Qt\4.6.3\lib
To see if QMAKESPEC is set correctly:
C:\> echo %QMAKESPEC%
%QMAKESPEC% // not set
win32-msvc2008 // set


2. With the Qt Visual Studio integration via the menu "Qt->Open From
.pro File" and save your project to also save the visual studio solution .sln file


==================== MFC AND QT

This walkthrough covers the migration of an MFC based program, generated by Microsoft Visual Studio's MFC Application Wizard, to the Qt toolkit using the Windows Migration Framework.

http://doc.trolltech.com/solutions/qtwinmigrate/winmigrate-walkthrough.html

and Nokia as a very nice landing page for this

http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Windows/qtwinmigrate/

Monday, July 26, 2010

Anti Hacker Rules

Anti-Hacker Standard Practices


The task of protecting your software from hackers is not easy. Put simply, complete and total protection - is not possible. If the hacker has access to your complete program, they can eventually break any and all protections you put in their way. This is not opinion - it is a fact. This is simply because they control the hardware at the most "intimate" level on which your program is running. As you know, a program is simply a set of instructions. Since the hacker controls the hardware on which those instructions are executed, eventually they will find the instructions in your program where your protections lie and simply change them.

A simple analogy illustrates this point: You have a lock on the front-door to your home don't you? When you leave the house, do you lock it? Of course you do. Why? You lock it because you don't want people to steal your stuff. If the door was unlocked, they would walk in and rob you. But, ask yourself, if they really wanted to get in, could they? If they had a crowbar and a chain-saw of course they could, sometimes they could simply kick in the door. If you had a great deal of valuables, you might get an alarm-system or a stronger door, but again, if they really wanted to rob you - they could. Software that resists hackers is just like a home with a locked door. You must make a reasonable attempt to keep your software safe since that will "keep the honest people honest", but at the same time, do not delude yourself into a false sense of security.

Of course - all is not lost. We recommend that, in light of this knowledge and accepting the facts as they are, instead of playing "the game" of protection with the intent to "win" (to completely stop the hackers) - we play for an impasse. Since we know that a "win" is impossible, we play the "game" for the next best thing - a tie. What we mean by a "tie" is that you should engineer your protections in such a way that:

It is as difficult, tedious and time consuming as possible for a cracker to crack.
Is difficult to crack successfully or without breaking some key part of the program.
If cracked, can be quickly and easily changed so the crack no longer works with the current version of the software.


What can you, as a developer, do to make your implementation of you software licensing solution as secure as possible?
What can you, as a developer, do on an ongoing basis, in order to make your software as secure as possible?
Anti-hacker standard practices are just that - standard. They should not be limited solely to your implementation of the licensing System and the code around it. So, in fact, the two concerns above are one and the same. Below are several simple "tricks" you should consider, that when used together, will force crackers trying to defeat your system to invest incrementally more time in doing so. When used in conjunction with the licensing System, their job will be unpleasant to say the least. Please be sure you understand that the purpose of playing the "game" is an impasse.

Here are several standard things you should do in any software you wish to protect to slow down crackers:

1 - Never give any registration or protection testing function a self describing name. Never use a function name like "IsActivated". Crackers will quickly locate these names (in most high level languages) and simply remove or rewrite them.
2 - Avoid unnecessary error messages. If your program gives an error message after an unsuccessful activation attempt, the crackers will be able to quickly locate the error message and know that at some point in the call stack immediately before it - a protection or activation-test function call failed.
3 - Wait using a timer in a separate thread to provide error messages. When an error message is unavoidable, you may wish to set a timer in a separate thread that will fire several seconds or minutes later to warn the user and take action. This makes tracing back to the protection call that caused the timer to start up more difficult and will slow the cracker down.
4 - Encrypt any and all protection strings. When an error message in unavoidable, be sure to dynamically generate the message string itself. The best way to do this is to store it in encrypted form in the binary and decrypt only immediately before you need it. This makes searching for the string very difficult. Better yet - encrypt all your programs strings.
5 - Use random tests for activation. Test that the program is correctly activated at random time intervals; hours, days or even weeks after it was first installed and run. Possibly test only after certain key functions (unrelated to activation) are used. This will often be missed by crackers and again will slow them down or make their crack worthless.
6 - Don't start the activation test for several seconds (or even minutes) after the activation. you may wish to store any Activation Codes input by the user temporarily in memory and after a brief pause try to activate them. You may even wish to require the user to restart the program before you input the value. This makes it difficult to trace and will slow the cracker down.
7 - Use CRC checksums in your application and dlls. Have your EXEs check themselves, check other DLLs, or even have them check each other. Consider computing a checksum on just a small section of the file itself instead of the whole thing - this makes the crackers job more difficult.
8 - Use Anti-Debugging tricks. Be sure you have read the Anti-Debugging section for more information on how to slow down crackers by having your software resist debuggers.
9 - Use Anti-Disassembling tricks. Be sure you have read the Anti-Disassembling section for more information on how to slow down crackers by having your software resist disassembling.
10 - Use more activation checking routines than the minimum necessary. You should test in several places, and in places where the crackers might not expect it. Check at random time intervals too (see above). One routine requires a time investment from the cracker to remove, then more routines will require even more time to break.
11 - Use Honey Pots. A "Honey Pot" is a fake or decoy routine (or set of routines) you code into your program that seem to check activation, but in fact - does nothing. Have it write and read registry keys, manipulate files, jump all over in memory computing useless values and doing meaningless comparisons. Use your imagination here. Name honey pots to draw the crackers attention (like "CheckReg"). The point is to waste their time with a ruse.
12 - Wrap Activation testing routines in ridiculously long code. Consider using several long procedures which do a huge amount of unnecessary (but seemingly meaningful) processing. At some point during this useless processing, legitimately check the activation. Consider even checking it two or three times in different ways. This make the crackers job of tracing through this giant jumble of assembly looking for the "real" code a more frustrating experience. This will slow them down. Your testing routines can safely take 5 to 20 seconds to execute on a reasonably fast machine.
13 - If you use a demo version of your software with limited features, make sure you don't have "grayed out" buttons or menu options. A cracker can simply change the enabled property of these controls which will effectively make your features visible again. It is always preferable to dynamically create these controls only when they are available.
If you use a demo version of your software with limited features, consider not distributing the actual binary code to execute those functions. The simplest way to do this is to include the "paid version only code" inside a DLL which is called from your program when it is legitimately purchased. Then when a customer purchases your software, give them an Activation Code to release your software protections as well as the required DLL containing the code for the missing features.
14 - If your program has been cracked, release a new version. This is probably the most important principle which makes all the above tricks worth while. Once you have wasted the crackers time as much as possible, slowing them down with all these tricks (and others you may think up yourself), you must immediately make all their hard work go to waste - release a new version fast. Change a few things around, re-organize the code, update the version number, test - and re-release. The cracker will have to start all over again. Reaction time is important too. Expect to move quickly if a crack is released. Try and release a new version as rapidly as possible to maximize the frustration effect.

cyclic redundancy check

A CRC (cyclic redundancy check) is a numeric value computed from some source (file, string, digest, etc). Unlike encryption, a CRC value is always the same size regardless of the source size. A CRC is also commonly referred to as a hash or a checksum.

There are numerous sources on the internet for information on what a CRC is, so the algorithms wont be discussed in depth here. Regardless - it may be preferable from a security standpoint for you to develop your own CRC algorithm variation based on a well-known cryptographically secure one.

A CRC can be used to help slow down hackers by computing a CRC checksum of some file (on Windows your EXE or a DLL) and comparing the computed value with a stored value from a known and trusted source. If any of the instructions have been changed, the CRC checksum will not match.

This can be used by your software team in a couple ways to slow down the crackers:

Trojan Server Attack

A cracker may try to replace the DLL (in case of COM with a Trojan COM server with the exact same interface but whose functions always returns true values). You can use a CRC value to attempt to defeat this attack:
The basic premise is:

On Windows Operating Systems, read from the registry the location of the DLL based on the known GUID of the COM server you want to check.
If that file exists, calculate a CRC checksum on it. (Any CRC or hashing algorithm can be used - it doesn't matter).
Compare the checksum calculated against your known checksum which you have previously computed on a trusted copy of the COM server. Take action depending on the match.
Perform a CRC check on the dll every time your program starts but before you actually use the system. Check the return value of the CRC check on the dll against a value you store inside your program. If they are not the same - the dll has been swapped, damaged or altered. To make this even more secure have the value inside the program you check against be stored in three different places, and assemble it just before you use it. A C++ example follows where, at development time, you have already run your CRC function on a trusted copy of the dll file and you know it should return a value of 3070908778 :

char buffer1[25] = {'\0'};
char buffer2[25] = {'\0'};
const char * val1 = "778"; // declared in a different module somewhere
const int val2 = 3070; // declared in a different module somewhere
static int val3 = 908; // maybe read from the registry where your installer wrote it.

if (CRCCheck("mydll.dll") != atol(strcat(strcat( itoa(val2, buffer1, 10), itoa(val3, buffer2, 10)), val1)))
{
// DefeatAttempt! - shut down.
}

You can even implement or use you own version of itoa, atol and strcat

CRCChecks can be quite simple to implement. We suggest that you use your own CRC to ensure that it is original.

Binary Instruction Replacement Attack
A cracker may simply replace the protection calls in your program to do nothing - ignoring the COM server altogether. In fact - this is a very common attack used by most crackers. You can use a CRC value to attempt to defeat this attack:

All 32-bit executables have a CRC checksum field in their programs PE header. You can force your compiler to generate this checksum. Then, using the Win32 API MapFileAndCheckSumA() you can get both the computed checksum and the stored one. Then simply compare them. This of course only works if the cracker doesn't change the stored one, but can sometimes be effective. There are many more sophisticated approaches to using CRCs in your program to detect the integrity of both itself and external modules (dlls) but they are beyond the scope of this help file.

You may even wish to consider computing the checksum on just a small section of the file itself instead of the whole thing - this makes the crackers job more difficult. Don't just have EXEs and DLLs check themselves, have them check each other.



Anti-Debugging



Debuggers are tools just like your IDE that allow crackers to trace a programs execution as they are running - instruction by instruction.

There are numerous anti-debugging tricks that are documented in books and on-line, but all approach the problem from two specific angles:

They attempt to detect any debugger that is currently attached to the process or running in the background.

They attempt to detect specific debuggers (like SoftICE and others).

Protected software should use some sophisticated techniques to protect you from debuggers in both these ways, However, this is only effective when the Binary/DLL methods are actually called to perform some action. To be even more resistant you should consider implementing anti-debugging tricks of your own.

There are simply too many well-documented ways to detect specific debuggers (like SoftICE) available to discuss them here. Many of them are very complex to implement or are ineffective. Instead, we suggest you make at least a simple attempt to detect debuggers. The simplest way to do this is with the Win32 API function call "IsDebuggerPresent". Although this is relatively simple to replace by most crackers, and only works on Windows NT, 2000 and XP, placing it in various unexpected locations in your program can sometimes be quite effective at slowing them down.


Anti-Disassembling

Disassemblers are tools crackers use to translate application code back into assembler or even a higher level language. There are several disassemblers on the market of various quality. Some even write comments on the translated code, which makes it easier for the cracker to understand.


Since the purpose of disassembling is to understand the programs code, a good way to counter disassemblers is to make it more incomprehensible internally. The simplest way to defend against disassemblers is to insert numerous small bits of code in between the legitimate program code instructions that do nothing meaningful, but appear to, and are complex to understand.

A simple way to do this is to define a number of anti-disassembling macros and inline functions. Use your imagination to write these macros and functions. Do lots of pointer arithmetic and mathematical transformations. Conditionally and unconditionally jump all around in memory. Make sure your anti-disassembling routines are macros or inline functions so the anti-disassembling code gets pre-processed and duplicated everywhere it is placed (instead of a simple function call which can be found and replaced in a single location by a cracker).

Then, sprinkle these macros and functions liberally around areas of your programs you wish to protect from disassembling. Increase the density of the routines around sensitive areas. Naturally this will increase the footprint of your binary and can potentially impact performance so use this trick very wisely. You may wish to reserve its use for areas only around your protections and licensing code.

The more you can make the crackers job tedious, the more time he will have to invest in cracking your software - which is the ultimate goal - to slow them down as much as possible.

Reading

http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=1597494224
http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0321294319
http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0072262877
http://blogs.technet.com/b/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx
http://www.amazon.com/IDA-Pro-Book-Unofficial-Disassembler/dp/1593271786/ref=pd_sim_b_7

Qualcomm Snapdragon vs OMA Texas Instrument




The Qualcomm Snapdragon platform continues to generate robust industry attention to accompany its steadily expanding customer base. At the recent COMPUTEX 2010 show, Qualcomm unveiled the sampling of the third generation of its Snapdragon platform – namely its first dual-CPU Snapdragon chipsets consisting of the MSM8260, MSM8660 and QSD8672 products that feature enhanced dual cores that can run at up to 1.2GHz and 1.5GHz respectively, and are targeted at the high-end smartphone market area (the third generation Snapdragon platform is expected to support commercial products by the end of 2010). The new third-generation Snapdragon products complement its first-generation QSD8x50 1GHz core product and the second-generation MSM8x55 and QSD8x50A products with 1GHz enhanced core, including multimedia optimizations and 1.3GHz enhanced core respectively.

The Snapdragon platform can be viewed as competing within the mobile application processor market segment (also referred to as the mobile multimedia processor market segment). Today the application processor segment includes IC platforms that typically integrate the application processor core along with additional functions such as baseband modem andwireless connectivity functions onto a single system-on-a-chip (SoC); this includes the Qualcomm Snapdragon. The application processor market also consists of IC platforms that exclude integration of baseband modems (e.g., TI’s OMAP 4). The application processor platform segment addresses a wide range of mobile devices including smartphones, mobile Internet devices (MIDs), netbooks and portable media devices. By its nature, the mobile application processor market segment attracts a wide swath of competition from the top-tier mobile silicon players, including Samsung, Apple, Intel and TI. Due to Qualcomm’s historically solid competitive foundation, based heavily on its CDMA chipset royalties, and the burgeoning traction of the Snapdragon platform (in over 140 device designs), it presents a mounting competitive challenge and thus generates the key issue of how the competition can position against the overall Snapdragon platform.
Perspective Current Perspective
The Snapdragon platform has been commercially available since Q4 2008 through the QSD8650 and QSD8250 first generation product offerings. From its inception, Qualcomm positioned the Snapdragon platform as an innovative breakthrough offering since it uses the in-house custom developed Scorpion CPU as the core application processor based on the ARMv7-based Cortex-A8 core. This approach has enabled Qualcomm to engineer improvements over standard off-the-shelf ARMv7-based Cortex-A8 processors in areas such as power consumption (e.g., the first Scorpion processor required 150 mW less power consumption at 600 MHz than the non-customized ARM equivalent and so on) as well as optimizing the processor design for the low-power (LP) process. As a result, the Snapdragon platform has proven a stalwart in the smartphone application processor market, as evidenced by the Snapdragon platform’s incorporation in over 140 device designs that include mobile devices that range from HTC’s Droid Incredible and Nexus One smartphones to Huawei’s S7 tablet, to name a few.

For the first generation Snapdragon QSD82x0 products and the second generation Snapdragon MSM8x55 and QSD8x50A products, Qualcomm shares platform and product metrics in areas such as core processor clock speed/performance, flexible wireless connectivity functions, HD video/3D/display/camera support and O/S versatility. This gives rivals a wide range of product areas to seek selective differentiation against the Qualcomm Snapdragon platform, although Qualcomm is hardly unique in that regard.

The topic of core processor clock speed and performance, for example, represents a straightforward and intuitive product area for rivals to assert competitive differentiation. The Snapdragon platform’s first-generation QSD8x50 supports a 1GHz core processor while the second-generation MSM8x55 and QSD8x50A products support a 1GHz enhanced core, including multimedia optimizations and a 1.3GHz enhanced core respectively. In contrast, Intel asserts that its x86 processor-based Moorestown platform via the Atom Z6xx processor series can support up to 1.5GHz clock speed for smartphone devices and up to 1.9 GHz clock speed for tablet devices. Such metrics will still match the third generation Snapdragon QSD8672 product that is designed to run dual cores that operate at 1.5GHz (this product should appear in mobile devices at retail by the end of 2010). This complements Intel’s overall efforts to position its Moorestown platform as prime time ready for smartphone technology due to the improvements realized in areas such as power consumption advances in battery life spans (based on 1500 mAh batteries) in support of 1080p/720p video (e..g, up to four hours for 1080p video) and browsing applications as well as multi-fold improvements gained in Java script, Web page, graphics and video performance. This includes up to fourfold Java script performance improvement and at least a doubling of Web page download performance and graphic performance in relation to the Qualcomm Snapdragon platform as well as wielding the industry’s only across-the-board support of 1080 HP/MP/BP 30 fps and 720 HP/MP/BP 30 fps video capabilities. Intel’s overall R&D investment and marketing blitz on behalf of the Moorestown platform is certainly targeted at Snapdragon, as well as advancing Intel’s longstanding ambition to promote the x86 processor architecture as a viable alternative to the ARM processor architecture that dominates the mobile device silicon market today. Intel hopes to play a more prominent role within the overall mobile device silicon market beyond netbook silicon. There is a bit of irony here as Intel is looking to use the Intel Moorestown platform to attack the ARM-centric Snapdragon platform in Qualcomm’s backyard of smartphone and tablet silicon, while Qualcomm is developing the Snapdragon platform to help more directly challenge Intel’s prominence within the netbook silicon segment.

Apple, Samsung and TI are Qualcomm rivals that also use the customization of the ARMv7-based Cortex-A8 processor to achieve select advancements over the standard ARM offering. Samsung and Apple currently have a strange bedfellow arrangement that can influence how they position their respective platforms against the Snapdragon platform. Samsung collaborated with Intrinsity in developing and introducing its 45nm-based Hummingbird platform during 2009. In April 2010, it was revealed that Apple acquired Intrinsity in stealth mode to lock up the FastCore intellectual property (IP) that was instrumental in realizing the iPad A4 processor’s enhancements to standard issue ARM Cortex-8 core processor technology (e.g., achieving 1 Ghz clock speed on a 45nm process). Through the acquisition, Apple can promote that its A4 processor development efforts are dedicated exclusively to the support of Apple products such as the iPad and iPhone, and the company can avoid the dissipation of processor engineering resources that its rivals, such as Qualcomm, are obliged to perform through the open-ended support of multiple OEM products. Samsung should look to further elucidate its plans to license the Hummingbird technology to other mobile device vendors and what if any impact this has on its Apple relationship. The Apple acquisition of Intrinsity does not change the fact that Apple’s A4 technology remains based on Samsung’s 45nm SoC technology and Samsung continues to have access and wield the Hummingbird IP gained from its joint collaboration with Intrinsity prior to the Apple acquisition of Intrinsity.

Samsung continues to register significant product development and marketing advances with its Hummingbird SC5PC110 processor. The Hummingbird S5PC110 runs the Samsung Galaxy S smartphone, which Samsung asserts will launch in an astonishing 110 countries. One area the Samsung can assert clear product differentiation against Qualcomm is in the area of 3D graphics. The S5PC110 processor can scale up to support 90 million triangles per second. In contrast, the Qualcomm QSD8650 delivers only 22 million triangles per second while the pending QSD8672 will do up to 80 million triangles per second. Additionally, in the related area of 2D graphics rendering, Samsung’s S5PC110 product can support up to one billion pixels per second while Qualcomm’s QSD8650 supports only 133 million pixels per second and the upcoming QSD8672 product still comes up short against Samsung with an improved 500 million pixels per second.

TI’s OMAP 4 platform using the OMAP4440 processor is slated to support mobile device products that will hit retail in late 2010/early 2011. The OMAP processor series is already found in well-known mobile handset products such as the Nokia N-series, the Motorola DROID, and the Palm Pre. However, OMAP 4 dual core clock speeds are limited to just 1 GHz, and that’s for a product that is not yet in generally available mobile products. In this regard, OMAP 4 only ties the Qualcomm Snapdragon’s first generation 1 GHz product and trails both the second and third generation 1.2Ghz-1.5Ghz products. However, TI has already staked out a competitive position against Qualcomm in this area showing how apples-to-apples comparisons can prove dicey at times in the mobile silicon space. TI asserts that the OMAP 4 can deliver improved resolution display and still image metrics in relation to the Snapdragon platform, despite the core processor clock speed differentials. For example, the OMAP 4 can deliver 20-megapixel camera support while the QSD8x50 product can only handle 12-megapixel cameras. Moreover, TI advocates the OMAP 4 platform will prove more flexible in hardware support of future video codecs in relation to the Snapdragon platform. TI will also invoke that its OMAP4440 processor will use the ARM Cortex-9 architecture, which can yield performance improvements over ARM Cortex-A8 products (up to 30 percent according to ARM) and more flexible dual core power management arrangements.

Overall the most serious long-term competitive threats to the Qualcomm Snapdragon platform within the smartphone and tablet application processor market will prove to be the major mobile silicon players such as Samsung, Apple and TI, as well as Intel, who already possess competitive application processor platforms targeted specifically at smartphone, MID and tablet products. Mobile silicon rivals such as Marvell, Freescale, NVIDIA and ST-Ericsson all sport viable mobile application processor platforms but need to prove they can move the market needle more within the mobile application processor market segment to mount a serious challenge to Qualcomm in the evolving smartphone/tablet silicon market segment. Marvell and Freescale have achieved market distinction within the ereader niche, for example, but are not able to match the Snapdragon’s presence in over 140 device design wins. Samsung, Apple, Intel and TI all possess the product differentiators in areas such as core processor clock speed/performance, power consumption metrics, and HD video/3D/display/camera video performance and the global channels to challenge the Snapdragon’s early market prominence in this area into the foreseeable future.
Recommended Actions Vendor Actions
• Mobile application processor vendors that target emerging 4G/LTE silicon devices should consider getting out ahead of the market in explaining how their platforms optimally complement the region-sensitive E-UTRA LTE bands (TDD/FDD modes). In general, mobile application processor vendors should posit the 4G/LTE market represents a new level playing field in the market as Qualcomm’s dominance in the CDMA/3G silicon market will not directly translate into the same type of dominance within the 4G/LTE space.

• Mobile application processor vendors should note that they generally rely on third-party partners to supply fundamental mobile silicon components such as baseband modems and RF transceivers to complement their application processor platforms while Qualcomm uses integrated in-house baseband modem and RF transceiver components as part of the Snapdragon offering. This provides some latitude in asserting that they can select best-of-breed components in these areas and have more supply chain flexibility in relation to Qualcomm’s single vendor approach.

• Intel should continue to pointing out that the smartphone/tablet market is still in its developing stages, which gives Intel ample opportunity to capitalize on new market opportunities in this fast growing segment. This includes pointing out that the Atom Z6xx series is already in the advanced demo stage in smartphones with 3.8”+ displays and ~15mm thin tablets and the x86 platform supports rising mobile O/Ss such as Android and MeeGo.
User Actions
• Smartphone and tablet OEMs need to test and contrast the Intel Atom Processor Z6xx series (prior codename Lincroft SoC) against competing ARM-based mobile device SoCs, such as Qualcomm’s Snapdragon platform, due to factors such as its compact package (i.e., 13.8x13.8x1.1mm with 0.5mm pitch), support of 19 power islands with on-die clock and power gating, new ultra low-power states (i.e., SOi1, SOi3), and the leveraging of Intel’s Hi-K 45nm LP SoC process.

• Smartphone and tablet OEMs should investigate the new OS power management (OSPM) capability that accompanies the overall Moorestown platform. This includes support of integrated PMUs, software-based OS power management options, and fine-grain power management functions that create power islands for sub-systems (i.e., power is only allocated to the application running and not dispersed to idle applications, etc.) and factor in such capabilities in seeking apples-to-apples validation of Intel’s power conservation claims on behalf of the Atom Moorestown platform in relation to the Snapdragon platform

Wednesday, July 21, 2010

Android WebKIT JS/HTML framework : PhoneGap

This guide will help you setup your first android project but not a basic one. One taking advantage of WebKIT Javascript framework.

The first thing to do is to download and install all the required dependencies.

Please contribute platform specific instructions where needed.

Installing dependencies

1. Java JDK
If you do not already have the java JDK installed on you'r system, install the Java SE Development Kit - JDK 6 from here:
http://java.sun.com/javase/downloads/index.jsp

If you're running Windows this is a standard installer file, just follow the on screen instructions for installation.

2. Eclipse
Install the Eclipse IDE for Java Developers from http://www.eclipse.org/downloads/. This a ZIP archive file, extract the folder “eclipse” for me I extracted eclipse
under C:\eclipse . Most other flavors of Eclipse (like Aptana or platform specific builds) will also work, provided that you install all the necessary Eclipse plug-ins.

3. Android SDK
Install the Android SDK Package from here:
http://developer.android.com/sdk/index.html

Extract the downloaded archive and place it somewhere you'll remember like C:\sdk\android-sdk-windows
and add the tools sub directory to your environment PATH. Additional information and instructions for adding the Android SDK to your PATH can be found at:
http://developer.android.com/sdk/installing.html

Be sure to do the following (WINDOWS):
Add android SDK to your Path
Add android sdk tools (\android-sdk-windows\tools) to your path. This is necessary
for ruby to find the command "android create project" later on.

4. ADT Plug-in for Eclipse
Install the ADT Plug-in for Eclipse as described here:
http://developer.android.com/sdk/eclipse-adt.html

5. Adding Android SDK components
Install at least the required Android SDK components using the Eclipse ADT plug-in, as described here:
http://developer.android.com/sdk/adding-components.html

You can also launch the ADT tool by running android in your terminal.

To verify your installation of Eclipse, Android SDK, ADT, and Java, you can build a sample “Hello World” application using the instructions located here:
http://developer.android.com/guide/tutorials/hello-world.html.

6. Apache ANT

Windows - download and unzip Apache ANT and add it to your PATH http://ant.apache.org/index.html.

7. Ruby

Windows - download and install Ruby from the official site http://www.ruby-lang.org/en/downloads/ or use the RubyInstaller (recommended) here http://rubyinstaller.org/

8. Installing PhoneGap
Now make sure you download the latest version of PhoneGap here:
http://github.com/phonegap/phonegap-android.

9. edit the droidgap ruby file

change target_id = 5 to target_id = 6 to target Android 2.0.1 if your phone is running 2.0.1

10. Build framework and sample application

C:\Dev\mydroid\phonegap-android>ruby ./droidgap c:/sdk/android-sdk-win
dows/ phonegap com.phonegap.droid.demo c:/Dev/mydroid/phonegap-android/example/ c:/dev/mydroid
/phonegap-android/phonegap/

11. Once the phonegap app has been generated launch eclipse

To load eclipse and be able to see the workspace location use the -showlocation parameter

c:\eclipse\eclipse -showlocation

12. Next is to import the generated project in eclipse, fix any compilation errors, include the phonegap jar in your project build path and finally edit AndroidManifest.xml otherway you are going to see few crashes when trying to access lower level java class

I replaced the < by { and > by }

{?xml version="1.0" encoding="utf-8"?}
{manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.tuniverse.droid"
android:versionCode="1"
android:versionName="1.0"}
{uses-permission android:name="android.permission.INTERNET" /}
{uses-permission android:name="android.permission.CAMERA" /}
{uses-permission android:name="android.permission.VIBRATE" /}
{uses-permission android:name="android.permission.ACCESS_GPS" /}
{uses-permission android:name="android.permission.ACCESS_ASSISTED_GPS" /}
{uses-permission android:name="android.permission.ACCESS_LOCATION" /}
{uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /}
{uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /}
{uses-permission android:name="android.permission.READ_PHONE_STATE" /}
{uses-permission android:name="android.permission.RECEIVE_SMS" /}
{uses-permission android:name="android.permission.RECORD_AUDIO" /}
{uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" /}
{application android:icon="@drawable/icon" android:label="@string/app_name"}
{activity android:name=".WebActivity"
android:label="@string/app_name" android:configChanges="orientation|keyboardHidden"}
{intent-filter}
{action android:name="android.intent.action.MAIN" /}
{category android:name="android.intent.category.LAUNCHER" /}
{/intent-filter}
{/activity}
{/application}
{/manifest}



13. When your app will build with no error, you can run the application
in the debugger or in the emulator.

To view the android log (emulator) open a shell (usually the same one than the one
used to lauch eclipse and run

abt logcat



If you want a nicer logcat output you can use some very cool python script to output the android log in color !!! Install python first from here

As you can see, the colored adb logcat is a huge improvement.

To easily use the code, copy the files color_console.py, coloredlogcat.py and logcat.bat to your Android SDK/Tools path like c:\android-sdk-windows-1.5_r3\tools\logcat.bat. Now, instead of running "adb logcat" just run "logcat".


You can download the files here colored_logcat.zip (3 KB)
Thanks go to
Jeff Sharkey
André Burgaud



To install APK applications on your Android phone do the following:

Copy the APK file you want to install to your phone's memory card and insert
the card into your Android phone.
Go to Android Market and search for the Apps Installer application.
Open it and click on the Install button.
After it is installed, just open it. It will show you all the APK files stored directly in the root directory of your memory card.
Just click on the application you want to install and it will be installed.

Using the Android SDK and USB driver

There is one more method that can be used, you can install APK files into your phone using the Android SDK. Download the Android SDK.

First of all, install the Android SDK on your computer. You will also need
to install the Android USB drivers to connect the SDK to your phone via USB. You can get instruction on how to install it from here

To install applications from other sources, you also need go to Settings -> Application Settings and enable Unknown Sources. Also go to Settings -> SD Card and Phone Storage -> Disable Use for USB Storage. You can enable it again later.

Next, just open Command Prompt and type: adb install path/file.apk

where path is the full path to the APK file and file is the name of the APK application file. Your application is now installed. This is all you need to do, now just open the application on your phone and use it.