Quantcast
Channel: Intel Developer Zone Articles
Viewing all 554 articles
Browse latest View live

Training Series for Development on Intel-based Android* Devices

$
0
0

This series of videos presents an overview of Intel tools available for Android* developers through Intel® Software. You´ll discover the benefits of these tools in your everyday life as a programmer whether or not you´re targeting Intel devices. These tools will improve your life as a developer by saving you time, allowing you to create better experiences, and helping you target your app to multiple platforms and architectures. Take a look at the five training videos and follow the links to learn more about each tool.

Intel Tools for Android* Developers

Xavier Hallade, Intel Technical Engineer and GDE

Android* developers can benefit from one or more of the tools that Intel offers. Xavier gives a quick description of some of the tools available, what they can do for you, and the benefits you can gain in terms of productivity and results. He also covers how the tools that can help you in debugging, performance optimization, cross-platform development and more.

 

NDK: Discover the Android Native Development Kit

Xavier Hallade, Intel Technical Engineer and GDE

Xavier introduces us to the Android* Native Development Kit (NDK), the official component you can use to integrate C/C++ into Android* applications. In some scenarios the usage of the NDK can generate a big performance boost on your app.

 

Intel® Graphics Performance Analyzers 

Seth Schneider, Intel Technical Engineer

Seth presents the Graphics Performance Analyzers, a set of powerful tools that help developers utilize the full performance potential of their platform. The Analyzers provide a system performance view in real time, track down errors, locate graphic issues and more.

 

Build Multi-OS Native apps with Intel® INDE​

Karthiyayini Chinnaswamy, Intel Technical Engineer, and Jeff Kataoka, Intel Marketing Manager

Karthi and Jeff walk us through Intel INDE, a developer productivity suite that enables cross-OS and cross-architecture native mobile application development using Java* and C++. Take a look at the set of tools that will allow you to improve your app performance and save time through code reuse and streamlined access of platform capabilities.

 

Develop Apps in HTML5 Using the Intel® XDK

Dale Schouten, Intel Technical Consulting Engineer

The Intel XDK allows you to develop in HTML5 and obtain installable mobile apps for Android*, Windows* and iOS*. Dale walks us through the features of the tool that makes it easy for developers to create, debug, and deploy apps across multiple OSs, using one code base.

 


Multi-OS Engine [Beta] Download and Installation

$
0
0

Multi-OS Engine provides time-saving and productivity features to use Java code to create Android* and iOS* apps.  

Thank you for applying for early access to the Multi-OS Engine beta.  With your approval for early access to this beta product, please utilize the links below to download the Multi-OS Engine.

Download the Multi-OS Engine beta below:

Windows* Host version (175MB)

OS X* Host version (116MB) 

 

Multi-OS Engine Developer Resources:

If you have an OS X* development machine, refer to the  Quick Start Guide for Local Build

If you have a Windows* development machine, refer to the Quick Start Guide for Remote Build

For more information:

Explore Intel® INDE

A suite of C++/Java* native developer tools for creating cross-OS, media-rich performance applications.

For a complete list of EULAs used by Intel® INDE, see the product release notes.
 

Project Newton - Total Solution for Smart Home IoT Control

$
0
0

Download PDF

Introduction

“Smart home” is the term used for a wide range of functionalities that enable users to control and manage their home devices using their smartphones, tablets or laptops, for example, control their thermostats remotely from an app on their smartphones. However, many think smart homes have two main stumbling blocks: no unified solution and they’re not practical yet. Project Newton, one of Intel’s latest innovation projects, can help mitigate these issues.

Problems

“There’s no unified solution”: Users want to make their own choices. They want to buy smart devices, like TVs, fridges, air-conditionings, from Apple, Samsung, Tencent, Xiaomi, etc. But each manufacturer has its own solution (for example, different manufactures have different communication protocols to follow) for smart homes. It’s almost impossible to standardize ecosystems.

“They’re not practical yet”: Previous smart home IoT control solutions included: Voice control, which might be impacted by background noise; Phone control or other remote controller, which can be inconvenient because it involves fetching a phone, launching the related app, searching for the IoT device you want to control, etc; Gesture recognition via camera, which can depend on the light environment and your position/direction in the room.

Project Newton

Project Newton is intended to provide an advanced total solution for smart home IoT control.

  • Connect any smart home IoT device
  • Does not depend on hand-held devices
  • Low cost
  • Not dependent on the environment, light intensity, noise level, or positional direction of the user

We developed an advanced total solution to smart home IoT control, named Project Newton. This system includes the connection of all main platforms (Intel® Core™ processor, Intel® Centrino* processor technology, Intel® Atom™ processor, ARM* mobile platforms) and all IoT platforms (Intel® Edison board, Intel® Galileo board, Raspberry*, Spark*, Mbed*, Freescale*, Arduino Uno*, etc.). Thus, Project Newton can connect platforms running all current mainstream OSs (Windows*, Linux*, Android*) and NonUI-OSs (Mbed*, Contiki*, RIOT*, Spark*, OpenWRT*, Yocto*, WindRiver*, VxWorks*, Raspbian*, etc.) in real time.

Smart home vendors usually define a set of application layer communication protocols, but these protocols are relatively closed. In Project Newton, we use CoAP (Constrained Application Protocol), which is a software protocol intended to allow simple electronics devices to communicate interactively over the Internet. CoAP protocol, based on the RESTful framework, is converted into an HTTP protocol to build a smart gateway easily. The basic prototype of CoAP design in Project Newton is below.

CoAP Design of Project Newton
CoAP Design of Project Newton

To classify all OSs supported in this idea, Intel® Galileo board, Intel® Edison board, UNO, and Spark boards support Arduino programming standards. Popular IoT LPC1768 boards support Mbed and RIOT operating systems. Mbed is a platform and operating system for Internet-connected devices based on ARM and is convenient for the operation of hardware resources by calling corresponding objects. RIOT is an open source operating system that supports multi-threading and several different development boards. It can be programmed using standard C language. An LPC1768 chip needs to use an external Wi-Fi* module for communication. Windows, Linux, and Android also easily adapt to CoAP. The software architecture of Project Newton is below.

Software Architecture of Project Newton
Software Architecture of Project Newton

OS Connection Implementation in Project Newton

  • CoAP Implementation

The source code for CoAP is open source code called MicroCoAP, which can be downloaded. It’s lightweight and written in standard C code, so it’s easy to transform it onto different platforms. MicroCoAP contains four files (CoAP.h, CoAP.c, endpoints.c, and main.c). CoAP.h and CoAP.c implement CoAP protocol, which is shown below, and endpoints.c includes response functions related to specific nodes.

CoAP Protocol

The main.c file builds a CoAP server. We mostly use CoAP_packet_t, CoAP_parse, CoAP_handle_req, and CoAP_build. CoAP_packet_t defines the data structure of a CoAP packet. The CoAP_parse function parses the hexadecimal data received from the network or serial port and converts the data to CoAP_packet_t structure. The CoAP_handle_req function analyzes received CoAP packets and makes proper responses. The CoAP_build function translates the response packets into hexadecimal data. The key source code to build a CoAP server is shown below.

The key source code to build a CoAP server

  • Arduino* Implementation

Arduino is an open-source electronic prototyping platform that creates an Arduino software and hardware standard. The Intel® Edison board, the Intel® Galileo board, and the Spark core board follow the Arduino standard. It mainly consists of two functions: setup and loop. Function setup initializes the hardware and is called once before a loop function. Function loop is a dead loop that can be used to execute the main function.

To add COAP to an Arduino board, just add the three files (CoAP.h, CoAP.c, endpoints.c) into the project and modify the setup and loop functions according to main.c in microCoAP, which can be found below.

CoAP server on Arduino* platform

  • Mbed Implementation

Mbed is an object-oriented C++ library developed for the ARM Cortex*-M processor. We can operate general purpose input/output (GPIO) and other hardware resources by using a related class. However, there is no default Wi-Fi module or library. Here, the UART-to-WIFI module is used to add Wi-Fi functionality to Mbed. Class WIFI is developed based on the datasheet of UART-WIFI module, and each function will send a relative string to the UART-WIFI module.

You need to add the three files (CoAP.h, CoAP.c, endpoints.c) into the project and modify main.c file according to main.c file in microCoAP project. To compile it, just use the make command—everything has been set properly in the Makefile, which is shown below.

CoAP server on Mbed platform
CoAP server on Mbed platform

  • RIOT Implementation

RIOT is an open source developer friendly operating system for IoT that can support several boards, such as the Mbed LPC1768 and the Spark Core development kit. It supports C and C++ language programming. The tests folder contains many sample APIs to connect with the hardware. Similar to Mbed, CoAP server can be implemented by changing the Wi-Fi class of Mbed into a C function and modifying APIs related to the serial port. However, it often crashes in our experiments, so it’s just for testing. To compile it, use the “BOARD=Mbed_lpc1768 make clean all flash” command in the root folder and use “BOARD=Mbed_lpc1768 make term” to monitor the serial port and get print information from Mbed. See the CoAP server code structure for RIOT below.

RIOT code structure
RIOT code structure

  • Contiki Implementation

Contiki is a multi-process open source OS. An example folder contains several samples of using APIs to control hardware. It also does not have a default Wi-Fi module. To implement CoAP server, use the similar functions of RIOT and rewrite the UART sample. To compile it, use the “TARGET=cc2530dk make” command and download the binary program using jlink. Check out the sample code below.

Sample code of CoAP server on Contiki
Sample code of CoAP server on Contiki

  • OpenWRT Implementation

OpenWRT is an eMbedded Linux for routers. It supports standard Linux API. So the microCoAP code can be used directly. In the package folder, set up the microCoAP project and modify the Makefile according to the Makefile in other project. Then, run the make command in the root directory. The compiled app will be in the bin folder. The app can be uploaded into the development board by ftp or usb storage. Finally, use the opkg command install CoAP*.ipk to install the CoAP app, and CoAP will be installed in OpenWRT. Add “/usr/bin/CoAP &” into the /etc/rc.local file. See the CoAP server code structure for OpenWRT below.

OpenWRT code structure
OpenWRT code structure

Practical Solution in Project Newton

To be a practical solution in IoT, it must be able to control any IoT device by natural gestures, without wearing any electronic wearable devices and not be affected by environmental light/noise/etc. One way a solution like this could be implemented is by using a 9 axis gyroscope to detect the user’s hand motions.

A sample of 9 axis gyroscope with Wi-Fi*
A sample of 9 axis gyroscope with Wi-Fi*

A pattern recognition algorithm analyzes the data in real time and detects the user’s position, direction, and gestures. By calculating the relative position/direction between users and IoT devices, the system can identify which IoT device the user is facing. By further calculating their hand direction and gestures, the targeted IoT device is selected and controlled

Show Cases of Project Newton

Here are the demo show cases in our lab, where Project Newton was used to connect and control a variety of devices with different OSs. These demo show cases include environment (Figure 1), controlling development boards (Intel® Edison board in Figure 2), controlling Android devices (Figure 3), controlling a robot arm (Figure 4), and controlling a robot car (Figure 5).

 The demo show cases environment in our lab
Figure 1: The demo show cases environment in our lab

 Select (blue) and control (green) boards in Project Newton
Figure 2: Select (blue) and control (green) boards in Project Newton

 Control Android devices in Project Newton
Figure 3: Control Android devices in Project Newton

 Control Robot Arm in Project Newton
Figure 4: Control Robot Arm in Project Newton

 Control Robot Car in Project Newton
Figure 5: Control Robot Car in Project Newton

 

Going Further

Project Newton, an advanced total solution for smart home IoT control, is an easy-to-use solution that gives users the ability to connect any smart home IoT device they want. It’s a low-cost solution that frees the user from having to use a hand-held device. And it does not rely on environmental parameters like light, noise level, etc.

However, like all open source projects, Project Newton could be even better. Our next steps are to improve gesture recognition, boost performance, and incorporate wearable devices. For example, the next-generation Google* Glass reportedly will sport a larger prism and will be powered by an Intel Atom processor, which could be a better practical IoT control solution for Project Newton.

 

About the Author

Zhen Zhou earned an MS degree in software engineering from Shanghai Jiaotong University. He joined Intel in 2011 as an application engineer in the Developer Relations Division Mobile Enabling Team. He works with internal stakeholders and external ISVs, SPs, and carriers in the new usage model initiative and prototype development on the Intel Atom processor, traditional Intel® architecture, and embedded Intel architecture platforms.

Case Study: Implementing Intel® x86 Support for Android* with CRI Middleware

$
0
0

Download PDF

Overview

Android* devices powered by the Intel® Atom™ processor are rising in popularity, and supporting applications are being released continuously. To meet the needs of application developers focused on creating games for Android devices with Intel Atom processors, middleware companies began supporting x86.

One such company, CRI Middleware Co., Ltd., offers runtime library x86 support for Android middleware. It has done this by changing the build settings of the makefile in the Android NDK and replacing the ARM* NEON* instructions. Included in x86 support of the middleware runtime library for Android devices is a plug-in for Unity*, a game engine developed by Unity Technologies, which allows developers to build games by simply setting the x86 folder as the build target with the Android NDK.

About CRI

CRI is a Japanese company researching, developing, and selling audio/video middleware. Founded in 1983 as a research institute of the independent IT solution vendor CSK Corporation, CRI developed middleware for the Sega home video game console. After going independent in 2001, it has racked up accomplishments with middleware for gaming consoles and is now producing products under the CRIWARE* brand.

In the past few years CRI has been focused on supporting smartphones and expanded its middleware for the iPhone* and Android. CRI currently provides the integrated sound middleware CRI ADX*2 for Android, the high quality and high performance movie middleware CRI Sofdec* 2, and the file compression/packing middleware FileMajik PRO. Using these, game and application developers are able to add powerful video to games and new rendering of communication with interactive sound, all while increasing development efficiency.

Integrated sound middleware CRI ADX 2

Integrated sound middleware CRI ADX 2

High quality and high performance movie middleware CRI Sofdec 2

High quality and high performance movie middleware CRI Sofdec 2

Intel® x86 Supported Backgrounds

CRI has been focused on Intel x86 support for middleware since 2012 when Android devices powered by the Intel Atom processor arrived in the market. Software developers began to call for Android x86 emulator support. There were issues with the operating speed of the original ARM emulator that emulates the ARM architecture, but high-speed operation was achieved using the x86 emulator and the Intel® Hardware Accelerated Execution Manager (Intel® HAXM). Many developers who used it said that they wanted to use CRIWARE with the x86 emulator for development efficiency gains, and thus an x86 support version was first released in June 2013.

Yusuke Urushihata, CRI unit head, states, “X86 support is simple to achieve using Android NDK. We were actually able to add support by simply adding one line for the output destination to the makefile.”

CRI released CRIWARE for the Android NDK development environment.

NDK development environment

NDK development environment

Later in August 2014 the game engine company Unity Technologies announced x86 support for Unity 4 and 5, and a native development environment was released. As a result, developers then called for CRI middleware x86 support for the Unity library which CRI later released.

Development integration manager at CRI, Atsushi Sakurai, stated, “Game developers (users) using the 3D game engine Unity strongly requested x86 support, so we decided to provide x86 middleware support.”

Unity development environment

Unity development environment

Other than Unity, the 2D-oriented Coco2d-x is another CRI-supported video game framework, which runs in the native Android development environment. Because it is written in C++, it does not require a special library.

Development Focused on x86 Support

CRI developed the runtime library with the program development environment Android NDK, creating it in a pre-determined order and adding support without any hitches.

Most parts of the build settings of the Android NDK makefile (Android.mk) are repaired and added one line at a time such that they are output in x86 format.

When it came to decode processing of videos, CRI used ARM NEON instructions, however it produced a make error when running a build for x86. Therefore, CRI rewrote the decode processing code in optimized C and C++ that has proven itself on Intel® architecture-based platforms.

To establish x86 support immediately, it was crucial that the CRI-provided middleware was multi-platform. Multi-platform support was originally included in the design concept of CRI’s middleware, so that a framework like the NEON instruction set exists for switching to a different environment even in the event of a target-specific problem. For example, even if the endians in the source code are different, they are automatically distinguished using CRI to configure the environment built with little endians.

How to use CRIWARE* for x86 Support

CRI provides libraries for ARM and x86.

The procedure when using Unity for video game development and CRIWARE to provide x86 support for Android devices with Intel Atom processors is quite simple. All you need to do is use the Android NDK to run the application’s build. As long as you’re using an Intel Atom processor-based device with Android and you have a test environment, x86 support is easy to achieve.

In native development environment, the application makefile and x86-targeted settings are modified one line at a time when you run the build. During this process, the library with x86 support is stored in an x86 folder that is automatically created in the libs folder.

Evaluation and Future Prospects of Intel® Atom™ Processor-based Devices running Android

At the present time, CRI has not yet finished its data analysis and so hasn’t drawn any conclusions as to the performance of Android devices powered by the Intel Atom processor versus ARM-powered ones.

Nevertheless, an application’s video and audio processing speed almost always depends more on the platform and audio/video drivers than on architecture, so the processor matters. Intel Atom processor-based devices run smoothly and do not experience slow operations or unnatural screen movements.

Moving forward, the possibility of supporting Intel® Streaming SIMD Extensions (Intel® SSE) is being examined for processing ARM NEON’s video decode instructions. Furthermore, preparations for 64-bit Android have also begun. CRI is therefore hoping for continued provision of information and technical support from Intel.

An Often Overlooked Game Performance Metric—Frame Time

$
0
0

Download PDF

As a quality assurance provider, Enzyme tests a large array of games on a weekly basis. When it comes to compatibility and performance testing, we have stumbled upon many instances where apparent performance hitches were not evident in the data collected during frame rate benchmarks.

The frame rate, or frames per second (FPS), while being a viable and simple method of measurement, is not the be-all and end-all data to consider when assessing performance. Another important metric to consider regarding frames is frame time.

Frame time mostly refers to the time it takes for the software to render each frame. More precisely, the data takes into consideration the duration of the benchmark multiplied by the average FPS of the application or rather, the total amount of frames rendered over the length of the benchmark rather than its duration in seconds. This data can be collected using benchmarking tools, such as the suite of Intel® INDE Graphic Performance Analyzers, and is crucial to take into account when assessing performance.

To illustrate this, consider a one-second frame time. If 60 frames are rendered during the first 500ms, followed by an absence of frames in the last 500ms of that second, the frame rate measure would still show an average of 60 FPS since the total number of frames displayed within that second is indeed 60.

While this case is unlikely, it demonstrates a worst-case scenario: a visible in-game hitch that is ignored by the frame rate data.

The frame time measurement provides more precise data as it keeps track of the time interval between every displayed frame. In the same case described above, a peak of 500ms will be easily and clearly identified when running the benchmark, allowing your team to troubleshoot the probable performance loss causes.

Small hitches in frames
Small hitches can be identified through the frame time and be completely ignored by the frame rate.

From a testing perspective, this type of data is often analyzed when comparing different hardware to identify the source of performances issues. We more often rely on the frame time than the frame rate as its linear nature makes it easier to analyze and is generally a more reliable source of information when it comes to a game's performances.

For instance, we have used frame time to compare performances with different storage devices. The following charts are representative of a situation where a clear difference is visible between an HDD and an SSD, yet can only be seen through frame time.

SSD's frame time
SSD's frame time is more stable than an HDD's. Frame rates are very similar for both.

Again, the performance issues are not represented in the FPS benchmark, whereas the frame time measurements clearly demonstrate an obvious increase in hitches on a system with an HDD compared to a system with an SSD. This type of comparison can prove to be useful for games that are heavy on texture streaming as we can determine if the type of storage device used causes a bottleneck.

In the end, FPS is a measurement that tends to even out the very short spikes. Frame time will catch everything; it might be a bit more intimidating to analyze since it contains a lot more data, but it is crucial to take it into account if you want to thoroughly troubleshoot and debug your software.

If you have questions on frame time measurement or would like to discuss other performance analysis best practices, don’t hesitate to contact us.

About the author
Enzyme was founded in 2002 by Yan Cyr and Emmanuel Viau, two pioneers in the video game industry. Using their international experience and the expertise of all the Enzymers, we have combined creativity and discipline in order to create Quality Assurance (QA) services and a testing methodology that add value to the clients’ products.

We are a passionate community dedicated to QA for video games, apps, software and websites. Whether you need QA testing, PC/Mobile compatibility testing, project evaluation or focus groups, or you are looking for localization or linguistic resources, or you need methodology or project management consultants, partnering with us will contribute to the achievement of your goals.

Our mission is to put our passionate workforce to use and contribute to the success of your projects.

Intel Multi-OS Engine: Enabling HTTPS

$
0
0

The standard java.net.URL class provides HTTPS functionality. To make it work you only need to set up security providers and CA certificates (cacerts).

Here is how you can do this on Mac OS X* from the command line.

Change the current directory to the resources directory of your Intel INDE Multi-OS Engine module and do the following:

Set up Security Providers

  1. Create a ./java/security directory.
    mkdir –p ./java/security
  2. Copy the security.properties file from the Android code repository to the directory you created in the previous step.
    cd ./java/security/
    
    curl –o ./security.tar.gz “https://android.googlesource.com/platform/libcore/+archive/master/luni/src/main/java/java/security.tar.gz”
    
    tar --extract --file=./security.tar.gz ./security.properties
    
    rm ./security.tar.gz
    
    cd ../../
  3. Zip the ./java directory to an application.jar file.
    zip –r application.jar ./java
  4. Finally, remove the ./java directory.
    rm –R ./java

Set up CA Certificates

  1. Create the ./android_root/etc/security/cacerts directory.
    mkdir –p ./ android_root/etc/security/cacerts
  2. Copy the cacerts directory from the Android code repository to the directory you created in the previous step.
    cd ./android_root/etc/security/cacerts
    curl –o ./cacerts.tar.gz “https://android.googlesource.com/platform/libcore/+archive/master/luni/src/main/files/cacerts.tar.gz”
    tar --extract --file=./cacerts.tar.gz
    rm ./cacerts.tar.gz
    cd ../../../../

In the Finder application the resulting directory structure of your Intel INDE Module should look as follows:

Finder directory structure

In Android Studio the structure of your Intel INDE Multi-OS Engine module should look as follows:

Android Studio directory structure

The structure of the resulting Xcode* project should look as follows: 

Xcode directory structure

Now you should be able to use HTTPS in your project through the java.net.URL class.

How to port an app using Multi-OS Engine, a feature of Intel® INDE

$
0
0

Overview

Do you have an existing Android* app? Thinking of porting it to iOS* platforms as well? But you have no iOS development experience. Well, you don’t need to! Multi-OS Engine will address your problem. Please refer to this if you are not already familiar with Multi-OS Engine. To get a technical overview of Multi-OS Engine, please refer this article.

Multi-OS Engine SDK provides the below resources for app development from IDE integration to application deployment.

This article will provide you details on how to port an existing android apps to iOS using the Multi-OS Engine. In this tutorial we will be using a local MAC machine for application development. For remote development, please refer to the remote build getting started guide.

The process for porting an existing android app to Multi-OS Engine can be broken into a step by step process.

Let us start by creating a project in Android Studio. Please refer to the quick start guide for local build on instructions on creating and Android Project and Multi-OS Engine module

Assuming that the project and the Multi-OS Engine module have been created, we will go through each step briefly with code snippets for better understanding.

Identify business logic and separate the UI

With the Multi-OS Engine you can reuse java code to create Android and iOS apps. The Multi-OS Engine allows you to code in Java with common business functionality which can be shared between Android and iOS.

Design of UI using Multi-OS Engine

Next, design your iOS UI using one of the two ways mentioned below:

1. Xcode storyboard designer

· To use Xcode designer, you can open your module in the Xcode. Right click on your Multi-OS Engine module, and open project in Xcode.

· The module opens up in Xcode. Click on storyboard under the resources folder.

· Once, your UI design is ready, you can copy the storyboard to your project under resources folder in Android Studio.

2. Multi-OS Engine Designer

· The designer is similar to Android. The format of designer is ixml file. More information of using Multi-OS Engine can be found here.

Bind UI in Java

Open your controller class under <modulename> --> java --> <package_name> --> ui --> AppViewController. In this class, you can associate the bindings to the Xcode UI Layout.

· Add class variables to all the views used in your design in your controller file.

· Once the class variables are added, associate the getters and setters for IBActions or IBoutlets (Please note this step is only needed if you are using Xcode designer to design your interface). However, the @Property annotation is only for people who do NOT use Xcode designer. If people use Xcode designer and have native stubs they should NOT use @Property annotation.

Event Handling

If you have an event handling associated with any component, you can create instances of the event based classes that need to be assigned an action in order to respond to some event.

Implementation of business logic

We then create a separate module for the business logic which will be in java.

· To create the module, right click on your project in the Project Explorer and create a new module. Choose the New module as “Java Library”.

· Once the module is created, it has to be accessed by both the Android module and iOS module. For this, right click on the project, open module settings and add dependencies for the iOS module and the android module.

· The business logic module is compiled using the Java compiler. We need to update gradle settings to build the module. Under Gradle scripts – choose build.gradle(Module:businesslogic)

  • Add the following script at the end-
 compilJava {

    targetCompatibility = 1.7

    sourceCompatibility = 1.7

}
 

This covers your app porting! Hope you found this article useful. In the end I would suggest sharing of your code as much as possible between the two apps. If you have any questions please feel free to post in on our Multi-OS Engine Forum.

Step by Step guide to build iOS apps using UI builder of Multi-OS Engine of Intel INDE

$
0
0

Author: Yash Oswal

If you have reached this article, I presume you know what Intel Multi-OS Engine is capable of and its cool new features. If not, refer to these articles - Why Multi-OS Engine? and the Technical Overview of Multi-OS Engine.

This article specifically talks about the UI Builder. Multi-OS Engine(MOE) provides its own UI builder to build iOS apps which is similar to Android layout to build but has view objects similar to that of iOS. In this tutorial I am going to build a simple Quiz application for iOS using MOE and its UI builder.

Step 1: To build any MOE application first make a stock Android sample application like this:       

Step 2: Then right click on the android project and select Intel MOE Module to create a new module.

Step 3: Then select stock Hello World Application as a starting point for making the app.

Step 4: Name your application and click finish

Step 5: These are the files that are created by MOE.

Step 6: Next click on the sample_design.ixml file to start editing your UI.

Step 7: As you can see some parameters are already set as default like initialViewController and its viewController. You can set parameters according to your own needs.

Step 8: After deleting the default label and button you can start adding your own view objects. Method of adding object is quite simple you just have to drag and drop just like android layout.

Step 9: You can set all the parameters related to your UI in the properties tab. The parameters here are quite similar to those seen on Xcode.

Step 10: Here add two labels and two buttons to make the UI of the app.

Step 11: Name the iboutlets for all the view objects that you place in your UI.

Step 12: And set up your IBActions for buttons under events. 

Step 13: The MOE auto-generates all the IBOutlets and IBActions in the corresponding Java viewcontroller file.

Step 14: Now add the class variables corresponding to all the view objects in UI and assign them their corresponding IBOutlets in viewDidLoad method.

Step 15: Now create a QuizDataSet.java file which can work as a data source for the app and instantiate its object in the AppViewController class.

Step 16: Next set the texts of the Question and Answer Labels in the Action methods showQuestion and showAnswer.

Step 17: After this just run the app. 

Voila! You have designed your first iOS app with the UI designer of the Multi-OS Engine.


Intel® XDK FAQs - General

$
0
0
Q1: How can I get started with Intel XDK?

There are plenty of videos and articles that you can go through here to get started. You could also start with some of our demo apps that you think fits your app idea best and learn or take parts from multiple apps.

Having prior understanding of how to program using HTML, CSS and JavaScript* is crucial to using Intel XDK. Intel XDK is primarily a tool for visualizing, debugging and building an app package for distribution.

You can do the following to access our demo apps:

  • Select Project tab
  • Select "Start a New Project"
  • Select "Samples and Demos"
  • Create a new project from a demo

If you have specific questions following that, please post it to our forums.

Q2: Can I use an external editor for development in Intel® XDK?

Yes, you can open your files and edit them in your favorite editor. However, note that you must use Brackets* to use the "Live Layout Editing" feature. Also, if you are using App Designer (the UI layout tool in Intel XDK) it will make many automatic changes to your index.html file, so it is best not to edit that file externally at the same time you have App Designer open.

Some popular editors among our users include:

  • Sublime Text* (Refer to this article for information on the Intel XDK plugin for Sublime Text*)
  • Notepad++* for a lighweight editor
  • Jetbrains* editors (Webstorm*)
  • Vim* the editor
Q3: How do I get code refactoring capability in Brackets*, the code editor in Intel® XDK?

You will have to add the "Rename JavaScript* Identifier" extension and "Quick Search" extension in Brackets* to achieve some sort of refactoring capability. You can find them in Extension Manager under File menu.

Q4: Why doesn’t my app show up in Google* play for tablets?

...to be written...

Q5: What is the global-settings.xdk file and how do I locate it?

global-settings.xdk contains information about all your projects in the Intel XDK, along with many of the settings related to panels under each tab (Emulate, Debug etc). For example, you can set the emulator to auto-refresh or no-auto-refresh. Modify this file at your own risk and always keep a backup of the original!

You can locate global-settings.xdk here:

  • Mac OS X*
    ~/Library/Application Support/XDK/global-settings.xdk
  • Microsoft Windows*
    %LocalAppData%\XDK
  • Linux*
    ~/.config/XDK/global-settings.xdk

If you are having trouble locating this file, you can search for it on your system using something like the following:

  • Windows:
    > cd /
    > dir /s global-settings.xdk
  • Mac and Linux:
    $ sudo find / -name global-settings.xdk
Q6: When do I use the intelxdk.js, xhr.js and cordova.js libraries?

The intelxdk and xhr libraries are only needed with legacy build tiles. The Cordova* library is needed for all. When building with Cordova* tiles, intelxdk and xhr libraries are ignored and so they can be omitted.

Q7: What is the process if I need a .keystore file?

Please send an email to html5tools@intel.com specifying the email address associated with your Intel XDK account in its contents.

Q8: How do I rename my project that is a duplicate of an existing project?

Make a copy of your existing project directory and delete the .xdk and .xdke files from them. Import it into Intel XDK using the ‘Import your HTML5 Code Base’ option and give it a new name to create a duplicate.

Q9: How do I try to recover when Intel XDK won't start or hangs?
  • If you are running Intel XDK on Windows* it must be Windows* 7 or higher. It will not run reliably on earlier versions.
  • Delete the "project-name.xdk" file from the project directory that Intel XDK is trying to open when it starts (it will try to open the project that was open during your last session), then try starting Intel XDK. You will have to "import" your project into Intel XDK again. Importing merely creates the "project-name.xdk" file in your project directory and adds that project to the "global-settings.xdk" file.
  • Rename the project directory Intel XDK is trying to open when it starts. Create a new project based on one of the demo apps. Test Intel XDK using that demo app. If everything works, restart Intel XDK and try it again. If it still works, rename your problem project folder back to its original name and open Intel XDK again (it should now open the sample project you previously opened). You may have to re-select your problem project (Intel XDK should have forgotten that project during the previous session).
  • Clear Intel XDK's program cache directories and files.
    On a [Windows*] machine this can be done using the following on a standard command prompt (administrator not required):
    > cd %AppData%\..\Local\XDK
    > del *.* /s/q
    To locate the "XDK cache" directory on [OS X*] and [Linux*] systems, do the following:
    $ sudo find / -name global-settings.xdk
    $ cd <dir found above>
    $ sudo rm -rf *
    You might want to save a copy of the "global-settings.xdk" file before you delete that cache directory and copy it back before you restart Intel XDK. Doing so will save you the effort of rebuilding your list of projects. Please refer to this question for information on how to locate the global-settings.xdk file.
  • If you save the "global-settings.xdk" file and restored it in the step above and you're still having hang troubles, try deleting the directories and files above, along with the "global-settings.xdk" file and try it again.
  • Do not store your project directories on a network share (Intel XDK currently has issues with network shares that have not yet been resolved). This includes folders shared between a Virtual machine (VM) guest and its host machine (for example, if you are running Windows* in a VM running on a Mac* host). This network share issue is a known issue with a fix request in place.

Please refer to this post for more details regarding troubles in a VM. It is possible to make this scenario work but it requires diligence and care on your part.

  • There have also been issues with running behind a corporate network proxy or firewall. To check them try running Intel XDK from your home network where, presumably, you have a simple NAT router and no proxy or firewall. If things work correctly there then your corporate firewall or proxy may be the source of the problem.
  • Issues with Intel XDK account logins can also cause Intel XDK to hang. To confirm that your login is working correctly, go to the Intel XDK App Center and confirm that you can login with your Intel XDK account. While you are there you might also try deleting the offending project(s) from the App Center.

If you can reliably reproduce the problem, please send us a copy of the "xdk.log" file that is stored in the same directory as the "global-settings.xdk" file to mailto:html5tools@intel.com.

Q10: Is Intel XDK an open source project? How can I contribute to the Intel XDK community?

No, It is not an open source project. However, it utilizes many open source components that are then assembled into Intel XDK. While you cannot contribute directly to the Intel XDK integration effort, you can contribute to the many open source components that make up Intel XDK.

The following open source components are the major elements that are being used by Intel XDK:

  • Node-Webkit
  • Chromium
  • Ripple* emulator
  • Brackets* editor
  • Weinre* remote debugger
  • Crosswalk*
  • Cordova*
  • App Framework*
Q11: How do I configure Intel XDK to use 9 patch png for Android* apps splash screen?

Intel XDK does support the use of 9 patch png for Android* apps splash screen. You can read up more at http://developer.android.com/tools/help/draw9patch.html on how to create a 9 patch png image. We also plan to incorporate them in some of our sample apps to illustrate their use.

Q12: How do I stop AVG from popping up the "General Behavioral Detection" window when Intel XDK is launched?

You can try adding nw.exe as the app that needs an exception in AVG.

Q13: What do I specify for "App ID" in Intel XDK under Build Settings?

Your app ID uniquely identifies your app. For example, it can be used to identify your app within Apple’s application services allowing you to use things like in-app purchasing and push notifications.

Here are some useful articles on how to create an App ID for your

iOS* App

Android* App

Windows* Phone 8 App

Q14: Is it possible to modify Android* Manifest through Intel XDK?

You cannot modify the AndroidManifest.xml file directly with our build system, as it only exists in the cloud. However, you may do so by creating a dummy plugin that only contains a plugin.xml file which can then be add to the AndroidManifest.xml file during the build process. In essence, you need to change the plugin.xml file of the locally cloned plugin to include directives that will make those modifications to the AndroidManifext.xml file. Here is an example of a plugin that does just that:

<?xml version="1.0" encoding="UTF-8"?><plugin xmlns="http://apache.org/cordova/ns/plugins/1.0" id="com.tricaud.webintent" version="1.0.0"><name>WebIntentTricaud</name><description>Ajout dans AndroidManifest.xml</description><license>MIT</license><keywords>android, WebIntent, Intent, Activity</keywords><engines><engine name="cordova" version=">=3.0.0" /></engines><!-- android --><platform name="android"><config-file target="AndroidManifest.xml" parent="/manifest/application"><activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" android:label="@string/app_name" android:launchMode="singleTop" android:name="testa" android:theme="@android:style/Theme.Black.NoTitleBar"><intent-filter><action android:name="android.intent.action.SEND" /><category android:name="android.intent.category.DEFAULT" /><data android:mimeType="*/*" /></intent-filter></activity></config-file></platform></plugin>

You can check the AndroidManifest.xml created in the apk, using the apktool with the command line:  

aapt l -M appli.apk >text.txt  

This adds the list of files of the apk and details of the AndroidManifest.xml to text.txt.

Q15: How can I share my Intel XDK app build?

You can send a link to your project via an email invite from your project settings page. However, a login to your account is required to access the file behind the link. Alternatively, you can download the build from the build page, onto your workstation, and push that built image to some location from which you can send a link to that image. 

Q16: Why does my iOS build fail when I am able to test it successfully on a device and the emulator?

Common reasons include:

  • Your App ID specified in the project settings do not match the one you specified in Apple's developer portal.
  • The provisioning profile does not match the cert you uploaded. Double check with Apple's developer site that you are using the correct and current distribution cert and that the provisioning profile is still active. Download the provisioning profile again and add it to your project to confirm.
  • In Project Build Settings, your App Name is invalid. It should be modified to include only alpha, space and numbers.
Q17: How do I add multiple domains in Domain Access? 

Here is the primary doc source for that feature.

If you need to insert multiple domain references, then you will need to add the extra references in the intelxdk.config.additions.xml file. This StackOverflow entry provides a basic idea and you can see the intelxdk.config.*.xml files that are automatically generated with each build for the <access origin="xxx" /> line that is generated based on what you provide in the "Domain Access" field of the "Build Settings" panel on the Project Tab. 

Q18: How do I build more than one app using the same Apple developer account?

On Apple developer, create a distribution certificate using the "iOS* Certificate Signing Request" key downloaded from Intel XDK Build tab only for the first app. For subsequent apps, reuse the same certificate and import this certificate into the Build tab like you usually would.

Q19: How do I include search and spotlight icons as part of my app?

Please refer to this article in the Intel XDK documentation. Create an intelxdk.config.additions.xml file in your top level directory (same location as the other intelxdk.*.config.xml files) and add the following lines for supporting icons in Settings and other areas in iOS*.

<!-- Spotlight Icon --><icon platform="ios" src="res/ios/icon-40.png" width="40" height="40" /><icon platform="ios" src="res/ios/icon-40@2x.png" width="80" height="80" /><icon platform="ios" src="res/ios/icon-40@3x.png" width="120" height="120" /><!-- iPhone Spotlight and Settings Icon --><icon platform="ios" src="res/ios/icon-small.png" width="29" height="29" /><icon platform="ios" src="res/ios/icon-small@2x.png" width="58" height="58" /><icon platform="ios" src="res/ios/icon-small@3x.png" width="87" height="87" /><!-- iPad Spotlight and Settings Icon --><icon platform="ios" src="res/ios/icon-50.png" width="50" height="50" /><icon platform="ios" src="res/ios/icon-50@2x.png" width="100" height="100" />

For more information related to these configurations, visit http://cordova.apache.org/docs/en/3.5.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens.

For accurate information related to iOS icon sizes, visit https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html

NOTE: The iPhone 6 icons will only be available if iOS* 7 or 8 is the target.

Cordova iOS* 8 support JIRA tracker: https://issues.apache.org/jira/browse/CB-7043

Q20: Does Intel XDK support Modbus TCP communication?

No, since Modbus is a specialized protocol, you need to write either some JavaScript* or native code (in the form of a plugin) to handle the Modbus transactions and protocol.

Q21: How do I sign an Android* app using an existing keystore?

Uploading an existing keystore in Intel XDK is not currently supported but you can send an email to html5tools@intel.com with this request. We can assist you there.

Q22: How do I build separately for different Android* versions?

Under the Projects Panel, you can select the Target Android* version under the Build Settings collapsible panel. You can change this value and build your application multiple times to create numerous versions of your application that are targeted for multiple versions of Android*.

Q23: How do I display the 'Build App Now' button if my display language is not English?

If your display language is not English and the 'Build App Now' button is proving to be troublesome, you may change your display language to English which can be downloaded by a Windows* update. Once you have installed the English language, proceed to Control Panel > Clock, Language and Region > Region and Language > Change Display Language.

Q24: How do I update my Intel XDK version?

When an Intel XDK update is available, an Update Version dialog box lets you download the update. After the download completes, a similar dialog lets you install it. If you did not download or install an update when prompted (or on older versions), click the package icon next to the orange (?) icon in the upper-right to download or install the update. The installation removes the previous Intel XDK version.

Q25: How do I import my existing HTML5 app into the Intel XDK?

If your project contains an Intel XDK project file (<project-name>.xdk) you should use the "Open an Intel XDK Project" option located at the bottom of the Projects List on the Projects tab (lower left of the screen, round green "eject" icon, on the Projects tab). This would be the case if you copied an existing Intel XDK project from another system or used a tool that exported a complete Intel XDK project.

If your project does not contain an Intel XDK project file (<project-name>.xdk) you must "import" your code into a new Intel XDK project. To import your project, use the "Start a New Project" option located at the bottom of the Projects List on the Projects tab (lower left of the screen, round blue "plus" icon, on the Projects tab). This will open the "Samples, Demos and Templates" page, which includes an option to "Import Your HTML5 Code Base." Point to the root directory of your project. The Intel XDK will attempt to locate a file named index.html in your project and will set the "Source Directory" on the Projects tab to point to the directory that contains this file.

If your imported project did not contain an index.html file, your project may be unstable. In that case, it is best to delete the imported project from the Intel XDK Projects tab ("x" icon in the upper right corner of the screen), rename your "root" or "main" html file to index.html and import the project again. Several components in the Intel XDK depend on this assumption that the main HTML file in your project is named index.hmtl. See Introducing Intel® XDK Development Tools for more details.

It is highly recommended that your "source directory" be located as a sub-directory inside your "project directory." This insures that non-source files are not included as part of your build package when building your application. If the "source directory" and "project directory" are the same it results in longer upload times to the build server and unnecessarily large application executable files returned by the build system. See the following images for the recommended project file layout.

Q26: I am unable to login to App Preview with my Intel XDK password.

On some devices you may have trouble entering your Intel XDK login password directly on the device in the App Preview login screen. In particular, sometimes you may have trouble with the first one or two letters getting lost when entering your password.

Try the following if you are having such difficulties:

  • Reset your password, using the Intel XDK, to something short and simple.

  • Confirm that this new short and simple password works with the XDK (logout and login to the Intel XDK).

  • Confirm that this new password works with the Intel Developer Zone login.

  • Make sure you have the most recent version of Intel App Preview installed on your devices. Go to the store on each device to confirm you have the most recent copy of App Preview installed.

  • Try logging into Intel App Preview on each device with this short and simple password. Check the "show password" box so you can see your password as you type it.

If the above works, it confirms that you can log into your Intel XDK account from App Preview (because App Preview and the Intel XDK go to the same place to authenticate your login). When the above works, you can go back to the Intel XDK and reset your password to something else, if you do not like the short and simple password you used for the test.

Q27: How do I completely uninstall the Intel XDK from my system?

See the instructions in this forum post: https://software.intel.com/en-us/forums/topic/542074. Then download and install the latest version from http://xdk.intel.com.

Q28: Is there a tool that can help me highlight syntax issues in Intel XDK?

Yes, you can use the various linting tools that can be added to the Brackets editor to review any syntax issues in your HTML, CSS and JS files. Go to the "File > Extension Manager..." menu item and add the following extensions: JSHint, CSSLint, HTMLHint, XLint for Intel XDK. Then, review your source files by monitoring the small yellow triangle at the bottom of the edit window (a green check mark indicates no issues).

Q29: How do I manage my Apps in Development?

You can manage them by logging into: https://appcenter.html5tools-software.intel.com/csd/controlpanel.aspx. This functionality will eventually be available within Intel XDK after which access to app center will be removed.

Q30: I need help with the App Security API plugin; where do I find it?

Visit the primary documentation book for the App Security API and see this forum post for some additional details.

Q31: When I install my app onto my test device Avast antivirus flags it as a possible virus, why?

If you are receiving a "Suspicious file detected - APK:CloudRep [Susp]" message it is likely due to the fact that you are side-loading the app onto your device (using a download link or by using adb) or you have downloaded your app from an "untrusted" store. See the following official explanation from Avast:

Your application was flagged by our cloud reputation system. "Cloud rep" is a new feature of Avast Mobile Security, which flags apks when the following conditions are met:
  1. The file is not prevalent enough; meaning not enough users of Avast Mobile Security have installed your APK.
  2. The source is not an established market (Google Play is an example of an established market).
If you distribute your app using Google Play (or any other trusted market) your users should not see any warning from Avast.
Q32: How do I add a Brackets extension to the editor that is part of the Intel XDK?

The number of Brackets extensions that are provided in the built-in edition of the Brackets editor are limited to insure stability of the Intel XDK product. Not all extensions are compatible with the edition of Brackets that is embedded within the Intel XDK. Adding incompatible extensions can cause the Intel XDK to quit working.

Despite this warning, there are useful extensions that have not been included in the editor and which can be added to the Intel XDK. Adding them is temporary, each time you update the Intel XDK (or if you reinstall the Intel XDK) you will have to "re-add" your Brackets extension. To add a Brackets extension, use the following procedure:

  • exit the Intel XDK
  • download a ZIP file of the extension you wish to add
  • on Windows, unzip the extension here: %LocalAppData%\Intel\XDK\xdk\brackets\b\extensions\dev
  • on Mac OS X, unzip the extension here: /Applications/Intel\ XDK.app/Contents/Resources/app.nw/brackets/b/extensions/dev
  • start the Intel XDK

Note that the locations given above are subject to change with new releases of the Intel XDK.

Back to FAQs Main

Building your first app for Android* and iOS* on Apple* Mac* OS X* using Multi-OS Engine

$
0
0

This tutorial will guide you to your first cross-platform application using the Multi-OS Engine installed on Mac OSX* which we refer to as local build. You can also develop your Android* and iOS* applications in Android Studio on Windows* but in order to simulate your iOS application, you will need to remotely deploy your app to a Mac system running Xcode* (hence remote build). For this scenario, check our getting started guide with Multi-OS Engine (remote build).

In this tutorial, I will show you how to create a simple Hello World application for Android and iOS with code-sharing between the two applications. In a real-world scenario, most of your application logic will be shared.

Prerequisites

To get started, you need to meet the minimum software requirements below:

  1. Android Studio* 1.0 or higher
  2. Xcode* 6 or higher
  3. Java* Development Kit 1.7 or higher
  4. Android SDK

Overall workflow

The workflow to creating Android and iOS apps is relatively simple.

  1. In order to create an iOS application in Android Studio, we first need to start with an Android Project.
  2. We then create a Multi-OS Engine module (which will be the iOS application)
  3. For application-code sharing, we create a module called common (shared Java library)
  4. We then add the common module as a dependency for the Android and iOS application
  5. Finally, we configure the Gradle* scripts, build and launch our apps. 

Creating our first Android and iOS applications with shared logic

  1. Create an Android Project in Android Studio
    Create Android project in Android Studio
  2. Enter your Application name, Company Domain and choose a location where you want to save your project. A good practice is to store your projects in a folder called Project under your username. You may wish to follow the exact steps described here to make sure you do not stumble onto any problems. Pay attention to the auto-generated package name (com.mycompany.myfirstapp) which is in lower caps. Click Next.
    Android Studio project configuration
  3. Configure your target device and API level settings. If you just want to just get started, simply proceed with the default settings by clicking Next.
  4. Choose “Blank Activity” in the Add an activity to Mobile window and click Next.
  5. In the Customize the Activity window, you may wish to leave the settings unchanged. Click Finish to accept the default configuration.

  6. At this point, Android Studio has created an Android project. In the Project pane, you will notice the app module. This module is your Android application. We will now proceed with adding a Multi-OS Engine module, which will eventually be your iOS application.

  7. In the Project pane, right click anywhere choose New > Intel Multi-OS Module
  8. Click on Hello World application and click Next
  9. In this window, you will create an Xcode project. Later you may wish to open the iOS project created by Android Studio, in Xcode, especially if you would like to use Xcode’s Storyboard to design your native user interface. Enter the Xcode project name (usually the name of your application), Product name (application name), organization and company ID details.

    In this example, we will enter the following details to match Android S:

    Xcode project name: myfirstapp
    Product name: myfirstapp
    Organization Name: mycompany
    Company Identifier: com.mycompany


  10. Click Next to configure the new module. The module will be an iOS module. Therefore let’s name it “iOS”. Click Finish.

    We have now created an iOS application in Android Studio. If Android Studio prompts you to synchronize the Gradle scripts, please do so. In the next steps, we will create a “common” module, which will, as the name suggests, common Java code for our Android and iOS applications.

    Now, let’s proceed with creating a “common” module which will hold our shared application logic (Java). In our simple example, our shared logic will simply be a Java object which has a method called sayHello() that returns a Java String.

  11. Again the Project pane, right click and add a new Module:
  12. In the New Module window, choose “Java Library” and click Next.
  13. We recall that this library will contain all our shared (common) application logic. Therefore, let’s name it “common” and have our first Java class called “AppLogic”. Also edit the Java package name as per the patterns that were generated for other modules. In general, it will be like this: company_domain_in_reverse.appname.common, for example
    com.mycompany.myfirstapp.common

  14. Click finish and let Android Studio refresh the Projects pane and the Gradle scripts.

    We will now add some code to our AppLogic class.

  15. Navigate to common > java > com.mycompany.myfirstapp.common and open the AppLogic class. Replace the contents with the following (code in bold are newly added/edited lines):

    package com.mycompany.myfirstapp.common;

    public class AppLogic {
      private String myString;

      public AppLogic(){
       this.myString = "Hello World from common";
     }

      public String sayHello(){
       return this.myString;

    }
    }

    Finally, let’s add the common module as a dependency in the Android and the iOS apps. Note: They are called “app” and “iOS” respectively in the Project pane.

  16. Select any module’s root (right now, you have three, namely app, iOS and common). Right click and choose Open Module Settings.
  17. For bothapp and iOS modules, add the common module in the Dependencies tabs. To do this, you click on the + sign at the bottom and click Module Dependency and then you choose common in the list.

    After you have added the common module as a dependency to the iOS module, the module settings for iOS should look like this:

    Do the above for the app module as well:

  18. The Java code in the common module will be compiled by the Java compiler. The module has its own Gradle* script for the build process. We need to update our script to tell Gradle which version of Java will be used to compile our module. Open the Gradle script for the common module (Gradle Scripts > build.gradle (Module: common)) and add the following at the end:

    compileJava {
      targetCompatibility = 1.7
      sourceCompatibility = 1.7
    }

    Now, let’s code a small Android application that has a button and a text field. When you click on the text field, you call the method sayHello() of the shared AppLogic object.

  19. For the Android app, open the activity_main layout
    (app>res>layout>activity_main.xml). If you see XML code, simply click on the Design tab at the bottom to switch to a graphical interface. There should already be a Hello World text field there. Let’s add a button by dragging a button from the palette to the phone. Double click on the button and rename it to “Click Me!”. Pay attention that the ID of the button is called “button”. Android locates elements on the screen by their IDs. The existing Hello World text has the ID textView. You can see this either in the Component Tree pane or in the XML file (to view the XML code, click on Text tab at the bottom)


  20. Next in our MainActivity (app > package com.mycompany.myfirstapp > MainActivity), we import our common module and add some logic to our newly-created button (See code snippet 1). The bold lines are pieces of code that are added. For classes like Button and View which are provided in the Android SDK, you can always press Option+Enter to auto-import the relevant packages.

  21. Optional: You can test the new Android app on a real device or on an Emulator. You do this by editing the configurations of the Android app. In the configurations menu, you can choose the target device. Please consult in the official Android documentation for more information on executing an app on a real device or on a virtual device.

  22. Now, let us create the iOS app.

  23. From the Projects page, open the AppViewController java file. (iOS > java > com.mycompany.myfirstapp > ui > AppViewController). Edit the code to import the common module and add the necessary logic to the button. Note: a button was automatically created when the Hello World Multi-OS Engine Module was added. See code snippet 2 below for the whole code. The bold lines are lines that were added/edited.

  24. The code for our iOS app is ready. From there, let’s execute the iOS app in the iOS Simulator. To do that, choose iOS from the dropdown menu as in the screenshot below:

  25. Voilà! You now have a classic Hello World application running on Android and iOS with code sharing.

    This was cool! Where do I go from here? You may wish to check out our more advanced samples in the sample folder: /Applications/Intel/INDE/multi_os_engine/samples

    Feel free to play around. If you have any difficulties, do not hesitate to ask your questions on our dedicated forum. Also, watch out for our blogs for updates and features regarding the Multi-OS Engine.

Code Snippets

Code snippet 1 – Android (MainActivity.java) 

 

package com.mycompany.myfirstapp;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;


/* Import our common module */
import com.mycompany.myfirstapp.common.*;

public class MainActivity extends AppCompatActivity {

   AppLogic al = new AppLogic();
   Button button;
   TextView tv;


   @Override
   protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_main);

     button = (Button) findViewById(R.id.button);
     tv = (TextView) findViewById(R.id.textView);

     button.setOnClickListener(new View.OnClickListener() {
       @Override
       public void onClick(View v) {
         tv.setText(al.sayHello());
       }
     });

   }

   @Override
   public boolean onCreateOptionsMenu(Menu menu) {
     // Inflate the menu; this adds items to the action bar if it is present.
     getMenuInflater().inflate(R.menu.menu_main, menu);
     return true;
   }

   @Override
   public boolean onOptionsItemSelected(MenuItem item) {
     // Handle action bar item clicks here. The action bar will
     // automatically handle clicks on the Home/Up button, so long
     // as you specify a parent activity in AndroidManifest.xml.
     int id = item.getItemId();

     //noinspection SimplifiableIfStatement
     if (id == R.id.action_settings) {
       return true;
     }

     return super.onOptionsItemSelected(item);
   }
}

 

Code snippet 2 – iOS – AppViewController.java 

 

package com.mycompany.myfirstapp.ui;

import com.intel.inde.moe.natj.general.NatJ;
import com.intel.inde.moe.natj.general.Pointer;
import com.intel.inde.moe.natj.general.ann.Generated;
import com.intel.inde.moe.natj.general.ann.Owned;
import com.intel.inde.moe.natj.general.ann.RegisterOnStartup;
import com.intel.inde.moe.natj.objc.ObjCRuntime;
import com.intel.inde.moe.natj.objc.ann.ObjCClassName;
import com.intel.inde.moe.natj.objc.ann.Property;
import com.intel.inde.moe.natj.objc.ann.Selector;
import com.mycompany.myfirstapp.common.AppLogic;

import ios.NSObject;
import ios.uikit.UIButton;
import ios.uikit.UILabel;
import ios.uikit.UIViewController;

@com.intel.inde.moe.natj.general.ann.Runtime(ObjCRuntime.class)
@ObjCClassName("AppViewController")
@RegisterOnStartup
public class AppViewController extends UIViewController {

   AppLogic al = new AppLogic();

   static {
     NatJ.register();
   }

   @Generated("NatJ")
   @Owned
   @Selector("alloc")
   public static native AppViewController alloc();

   @Generated("NatJ")
   @Selector("init")
   public native AppViewController init();

   @Generated
   protected AppViewController(Pointer peer) {
     super(peer);
   }

   public UILabel statusText = null;
   public UIButton helloButton = null;

   @Override
   @Selector("viewDidLoad")
   public void viewDidLoad() {
     statusText = getLabel();
     helloButton = getHelloButton();
   }

   @Selector("statusText")
   @Property
   public native UILabel getLabel();
   @Selector("helloButton")
   @Property
   public native UIButton getHelloButton();

   @Selector("BtnPressedCancel_helloButton:")
   public void BtnPressedCancel_button(NSObject sender){
     statusText.setText(al.sayHello());
   }
}

Multi-OS Engine - OpenGL sample

$
0
0

This article describes the OpenGLBox sample in the Multi-OS Engine, a beta feature of Intel® INDE version 1.0.285 and later. This is a truly cross-platform sample. On the screenshots below you can see that the same Java-based application on iOS and Android looks and behaves the same way. Applications for different platforms share the data and part of the source code. How is this achieved? Scroll down!

OpenGLBox iOS SimulatorOpenGLBox Android

Every single OpenGL programmer has, at least one time, made this small program: the rotating 3D cube. Don't be afraid If you are not so familiar with 3D graphics programming. This example will help you to start from scratch. If you are already good at OpenGL, this article will help you to focus on the specific features of Android and iOS development. Let's begin.

Our geometry contains 6 faces, as befits a cube, and 24 vertices. Why are so many vertices? Each face has a texture of Multi-OS Engine logo. Thus, we have to divide each of 8 real vertices into 3 new vertices with different texture coordinates.

There is no lighting effects in our scene. So we are able to use pretty simple shaders. The vertex shader just transforms geometry and passes the texture coordinates to the fragment shader. Then the fragment shader makes simple texturing.

Platform specific code


INDE Multi-OS Engine does not try to hide platform-specific code unnecessarily. It's great for porting and debugging applications. The classes for each platform can have their own features:

iOS
package com.intel.inde.moe.samples.openglbox.ios;

class Main extends NSObject implements UIApplicationDelegate
class OpenGLBoxController extends GLKViewController implements GLKViewDelegate
class ShaderProgram extends ShaderProgramBase

The GLKit framework provides functions and classes that reduce the effort required to create new shader-based apps:

GLKViewController

The GLKViewController class provides all of the standard view controller functionality, but additionally implements an OpenGL ES rendering loop. A GLKViewController object works in conjunction with a GLKView object to display frames of animation in the view.

GLKView

The GLKView class simplifies the effort required to create an OpenGL ES application by providing a default implementation of an OpenGL ES-aware view. A GLKView directly manages a framebuffer object on your application’s behalf; your application simply draws into the framebuffer when the contents need to be updated.

GLKViewDelegate

An object that implements the GLKViewDelegate protocol can be set as a GLKView object’s delegate. A delegate allows your application to provide a drawing method to a GLKView object without subclassing the GLKView class.

Android
package com.intel.inde.moe.samples.openglbox.android;

class OpenGLBoxActivity extends Activity
class SurfaceView extends GLSurfaceView
class BoxRenderer implements GLSurfaceView.Renderer
class ShaderProgram extends ShaderProgramBase

There are two foundational classes in the Android framework that let you create and manipulate graphics with the OpenGL ES API: GLSurfaceView and GLSurfaceView.Renderer. To use OpenGL in your Android application, one needs to understand how to implement these classes in an activity.

GLSurfaceView

This class is a View where you can draw and manipulate objects using OpenGL API calls and is similar in function to a SurfaceView. You can use this class by creating an instance of GLSurfaceView and adding your Renderer to it. However, if you want to capture touch screen events, you should extend the GLSurfaceView class to implement the touch listeners responding to Touch Events.

GLSurfaceView.Renderer

This interface defines the methods required for drawing graphics in a GLSurfaceView. You must provide an implementation of this interface as a separate class and attach it to your GLSurfaceView instance using GLSurfaceView.setRenderer().

Common code


OpenGL-code is similar on both platforms. It allows us to take out interfaces or even abstract classes into the common part of the project. For example, a class working with shaders must inherit abstract base class ShaderProgramBase

package com.intel.inde.moe.samples.openglbox.common;

public abstract class ShaderProgramBase {

    protected static int INVALID_VALUE = -1;
    protected int programHandle = INVALID_VALUE;
    protected HashMap<String, Integer> attributes = new HashMap<String, Integer>();

    public abstract void create(String vertexCode, String fragmentCode);
    public abstract void use();
    public abstract void unUse();
    public abstract int getAttributeLocation(String attribute);
    public abstract int getUniformLocation(String uniform);

    protected abstract int loadShader(int type, String shaderCode);

    public int getProgramHandle() {
        return programHandle;
    }
}

Now let's dive into platform-specific implementations of ShaderProgramBase.create() method.

iOS:

package com.intel.inde.moe.samples.openglbox.ios;
...

public class ShaderProgram extends ShaderProgramBase {
...

    @Override
    public void create(String vertexCode, String fragmentCode) {
        ...

        programHandle = OpenGLES.glCreateProgram();
        OpenGLES.glAttachShader(programHandle, vertexShader);
        OpenGLES.glAttachShader(programHandle, fragmentShader);
        OpenGLES.glLinkProgram(programHandle);
    }
}

Android:

package com.intel.inde.moe.samples.openglbox.android;
...

public class ShaderProgram extends ShaderProgramBase {
...

    @Override
    public void create(String vertexCode, String fragmentCode) {
        ...

        programHandle = GLES20.glCreateProgram();
        GLES20.glAttachShader(programHandle, vertexShader);
        GLES20.glAttachShader(programHandle, fragmentShader);
        GLES20.glLinkProgram(programHandle);
    }
}

As you can see these code snippets look pretty similar. It may seem that the code differs only in prefixes - OpenGLES and GLES20. Not quite right but not far off. Look carefully at loadShader() method:

iOS:

package com.intel.inde.moe.samples.openglbox.ios;
...

public class ShaderProgram extends ShaderProgramBase {
...

    @Override
    protected int loadShader(int type, String shaderCode) {
        ...

        IntPtr status = PtrFactory.newIntReference();
        OpenGLES.glGetShaderiv(shader, ES2.GL_COMPILE_STATUS, status);
        if (status.getValue() == 0) {
            BytePtr info = PtrFactory.newWeakByteArray(256);
            OpenGLES.glGetShaderInfoLog(shader, 256, PtrFactory.newWeakIntReference(0), info);
            OpenGLES.glDeleteShader(shader);
            throw new IllegalArgumentException("Shader compilation failed with: " + info.toASCIIString());
        }
        ...
    }
}

Android:

package com.intel.inde.moe.samples.openglbox.android;
...

public class ShaderProgram extends ShaderProgramBase {
...

    @Override
    protected int loadShader(int type, String shaderCode) {
        ...

        int[] status = new int[1];
        GLES20.glGetShaderiv(shader, GLES20.GL_COMPILE_STATUS, status, 0);
        if (status[0] == 0) {
            String info = GLES20.glGetShaderInfoLog(shader);
            GLES20.glDeleteShader(shader);
            throw new IllegalArgumentException("Shader compilation failed with: " + info);
        }
        ...
    }
}

This code differs by the way we pass a pointers to OpenGL. You will see similar distinctions in other places too.

Common data


Now it's time to describe other common parts. Our applications uses the following general data:

  1. Geometry
    public class Geometry {
        public static final float[] VERTICES = new float[] { … };
        public static final byte[] INDICES = { … };
    }
  2. Shaders (as String constants)
    public class Shaders {
        public static final String VERTEXT_SHADER = " ... ";
        public static final String FRAGMENT_SHADER = " ... ";
    }
  3. Parameters (background color, rotation speed, different camera related values)
    public class Parameters {
        ...
        public static final float DEGREES_PER_SECOND = 90.0f;
        ...
    }

All this constants are self-explained. They represent the common 3D data model and operational logics. In larger projects the common data will be even greater. 

3D Mathematics


OpenGL ES 2.0 and later doesn’t provide built-in functions for creating or specifying transformation matrices. Instead, programmable shaders provide vertex transformation, and you specify shader inputs using generic uniform variables.

iOS:

The GLKit framework includes a comprehensive library of vector and matrix types and functions, optimized for high performance on iOS hardware.

viewMatrix = GLKit.GLKMatrix4MakeLookAt(
    0.0f, 0.0f, Parameters.EYE_Z, // eye
    0.0f, 0.0f, 0.0f, // center
    0.0f, 1.0f, 0.0f // up-vector
);
viewMatrix = GLKit.GLKMatrix4Rotate(viewMatrix,
    GLKit.GLKMathDegreesToRadians(Parameters.PITCH), 1, 0, 0);

Android:

Class android.opengl.Matrix provides math utilities. These methods operate on OpenGL ES format matrices and vectors stored in float arrays.

Matrix.setLookAtM(viewMatrix, 0,
    0.0f, 0.0f, Parameters.EYE_Z, // eye
    0.0f, 0.0f, 0.0f, // center
    0.0f, 1.0f, 0.0f // up-vector
);
Matrix.rotateM(viewMatrix, 0, Parameters.PITCH, 1, 0, 0);

But you can implement basic math classes on your own and increase the reuse of the common code.

Loading textures


iOS:

The GLKTextureLoader class simplifies the effort required to load your texture data. The GLKTextureLoader class can load two-dimensional or cubemap textures in most image formats supported by the Image I/O framework. On iOS, it can also load textures compressed in the pvrtc format. It can load the data synchronously or asynchronously.

public static int loadGLTexture(String name, String extension) {
    NSMutableDictionary options = NSMutableDictionary.alloc().init();
    options.put(NSNumber.numberWithBool(true), GLKit.GLKTextureLoaderOriginBottomLeft());

    String path = NSBundle.mainBundle().pathForResourceOfType(name, extension);
    GLKTextureInfo info = GLKTextureLoader.textureWithContentsOfFileOptionsError(path, options, null);
    if (info == null) {
        System.out.println("Error loading file: " + name + "." + extension);
        return -1;
    }

    return info.name();
}

The GLKTextureLoader and GLKTextureInfo classes do not manage the OpenGL texture for you. Once the texture is returned to your app, you are responsible for it. This means that after your app is finished using an OpenGL texture, it must explicitly deallocate it by calling the glDeleteTextures() function.

Android:

For good or bad, but we're implementing it manually:

public static int loadGLTexture(Bitmap bitmap) {
    int[] textureIDs = new int[1];
    GLES20.glGenTextures(1, textureIDs, 0);

    GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, textureIDs[0]);

    // Create Nearest Filtered Texture
    GLES20.glTexParameterf(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER,
            GLES20.GL_LINEAR);
    GLES20.glTexParameterf(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER,
            GLES20.GL_LINEAR);

    GLES20.glTexParameterf(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_S, GLES20.GL_REPEAT);
    GLES20.glTexParameterf(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_WRAP_T, GLES20.GL_REPEAT);

    // Use the Android GLUtils to specify a two-dimensional texture image from our bitmap
    GLUtils.texImage2D(GLES20.GL_TEXTURE_2D, 0, bitmap, 0);

    return textureIDs[0];
}

Of course, you always can write your own wrapper for such OpenGL-intensive code. We didn't set to ourselves such a task.

Timing


iOS:

Method timeSinceLastUpdate() returns the amount of time that has passed since the last time the view controller called the delegate’s update() method:

public void update() {
    rotation += Parameters.DEGREES_PER_SECOND * timeSinceLastUpdate();
    modelMatrix = GLKit.GLKMatrix4Identity();
    modelMatrix = GLKit.GLKMatrix4Rotate(modelMatrix, GLKit.GLKMathDegreesToRadians(rotation), 0, 1, 0);
}

Android:

There is no such method on Android. So we have to recreate it manually:

private long lastTime;

public void onSurfaceCreated(GL10 unused, EGLConfig config) {
    …
    lastTime = System.nanoTime();
}

public void onDrawFrame(GL10 unused) {
    update();
    drawBox();
}

double timeSinceLastUpdate() {
    long time = System.nanoTime();
    double delta = (double) (time - lastTime) / 1000000000;
    lastTime = time;
    return delta;
}

private void update() {
    if (isPaused)
        return;
    rotation += Parameters.DEGREES_PER_SECOND * timeSinceLastUpdate();
    Matrix.setIdentityM(modelMatrix, 0);
    Matrix.rotateM(modelMatrix, 0, rotation, 0, 1, 0);
}

Summary


OpenGL development with Java on iOS is quite similar to that on Android with many advantages:

  • OpenGL ES is a C-based API that is supported by both iOS and Android with great portability
  • Familiar Java syntax
  • Debugging two targets side by side use the powerful iOS simulator and Android emulator

 

IDF2015 Lab Notes: Getting your Nexus Player from shrink-wrap to Performance and Energy Analysis

$
0
0

Introduction:

Initially presented as a hands-on lab for Intel Developer Forum 2015 as "SFTL002: Hands-on Lab: Intel® Architecture Based Mobile Device Development Workshop – Featuring Android* TV" the lab instructions are provided here as reference in the hope that they are useful to a wider developer community.  The boot image and appropriate data capture drivers were built prior to the lab by the presenter but notes are included on how to perform both tasks in the notes, although not in as great a detail.  Regardless I hope that the following information will be useful to you, all tasks are possible with a commercially available Nexus Player device, a host PC running Ubuntu, a properly licensed version of Intel System Studio, and internet access to publicly available referenced sites.  Versions used are as follows: Nexus Player: Build LMY47V but initial build on device often much earlier, Ubuntu 14.04 LTS, ISS 2016-Beta with SoC Watch 2.0-Beta.

Table of Contents:

  1. Basic Familiarization with the Nexus Player
  2. Recovering to Factory Image
  3. Rooting the Device
  4. Running a Performance Analysis
  5. Reviewing the Results
  6. Installing Additional Drivers
  7. Re-Running Analysis and Comparing with prior results
  8. Running Energy Profile and Power Analysis
  9. Building the boot.img needed to Root the Device
  10. Building the Additional Drivers
  11. Notes for setting up Ubuntu on the host

 

Booting your Nexus Player and getting familiar with it

 

 

  • Batteries in the remote

  • Plug in the USB cable from your device to your PC, and the HDMI cable from your device to your display, THEN plug in the device power cable.

  • First thing the device will request is to sync with your remote, this is done by holding down the left arrow and circle key on the remote as indicated on the device display.

  • Then select your language and WiFi network for the device by using the remote

    • The player needs non-proxy access to the internet through a WiFi connection to continue.  Some basic security setups are supported but not a username/password combination system.

  • Then sign in to a google account, you may sign in with your own account a dummy gmail account was created for use in the lab

  • You may view Google terms of service or select continue

  • I recommend not sharing location, but that is up to you.

  • On your PC open a command prompt and check lsusb and adb devices. You will notice that the device is not listed.

  • Select Settings and “About” then scroll down to “Build” and click on the selector until you receive the message “You are now a Developer” Take a note of the build version.  You will need to build your boot.img (in this step) to match the build version on your device, or flash the device to a factory default image matching the build version desired (as in this step).  More on this later.

  • Now back out of the settings menu and return once again, you should now be able to select “Developer options” under the “Preferences” section

  • Under “Debugging” set “USB debugging” to ON, this will result in a prompt requesting access from you PC system.Check the “always allow this device” and then select OK.

  • On your PC re-run lsusb and adb devices and you will now be able to see the device

  • You may now side-load some applications if desired and/or copy over some movie files for viewing on the device.  In the lab some public domain NASA videos were used as was the VLC player and EC File Manager app otherwise available on the Google Play store.

    • adb push <filename>.mp4 /sdcard/Movies

    • adb install <filename>.apk  (device will prompt for verification)

  • Note that you may or may not be able to see the location where you copied the video files as the device is still not rooted.

    • adb shell

      • ls /sdcard

      • ls /sdcard/Movies

  • Yet they clearly exist and can be used (you can’t see the Movies directory, but you can see what files you just put there if you know the directory exists)

    • On device us File manager (just installed) to navigate and find files

    • On device use VLC player to play a video clip

  • Now we are familiar with the device and the some of the limitations of having a non-rooted device as well as some of the ways to get around this without rooting the device

Recovery to factory settings

  • Factory recovery images for the Nexus Player are available directly from Google via this site:   https://developers.google.com/android/nexus/images

  • Boot the Nexus Player (device) by plugging it in, ensure HDMI cable connects to monitor, USB connects to laptop, and power connects to power

  • On you Host machine open a terminal and navigate to the directory where you unzipped the downloaded image

  • Confirm connection with device by running adb devices

  • Boot into the bootloader via adb reboot bootloader

    • This may also be accomplished by holding down the button on the bottom of the device during initial boot.

  • Disable the oem lock to enable flashing with fastboot oem unlock. If this fails don’t be concerned just try again, sometimes it takes a couple of attempts.

  • Revert device to factory image LMY47V by running ./flash-all.sh

    • Device will reboot at least once after flashing the bootloader itself, after which it will flash the rest of the system.One may follow the progress both on one’s system as well as one’s device display.Upon completion the device will reboot once again and should come up with factory image as though it were brand new out of the box!

 

Rooting the device

  • If you attempted to run VTune prior to rooting the device you would get an error message when it attempts to install the necessary app code onto the device itself. Although VTune will often run and provide useful data even on un-rooted devices my experience with this particular device while preparing for this lab was that it did not.  Thus we root the device first.

  • On the PC navigate to the directory containing your boot.img as built here

  • Run adb reboot bootloader and wait for your device to reboot into the bootloader screen

  • Run fastboot oemunlock when successful the oem lock state should be updated on the device screen.If this fails don’t be concerned just try again, sometimes it takes a couple of attempts

  • The boot.img we have prepared for this lab is based on lollipop build LM47V which is why we needed to update the device to that build version in order for this step to work.  Should a different build need to be rooted then one would simply need to create a boot.img file for the appropriate version.  This is because we are only flashing the boot.img file and it will need to match the build version of the system.img and other components of the device which are not updated with this step.

  • Run fastboot flash boot boot.img if that completes without error then continue, otherwise retry, it should only take a second or two

  • At this point one could choose to re-lock the oem lock via fastboot oem lock, but it’s not necessary.

  • Run fastboot continue to reboot the device back to normal user interface

  • You should note on the boot screen now displays “Google” with a little unlocked lock symbol, previously there was no lock symbol on this screen. It will then continue booting back to the normal UI.

 

 

Running a performance analysis

  • Run adb root to confirm that the rooting worked and gain root access through adb

  • You may now adb shell to the device and see what directory structure is visible which previously wasn’t (such as /data)

  • Open VTune Amplifier on the host system

    • Run /opt/intel/vtune_amplifier_for_system/bin64/amplxe-gui

    • In the “Welcome” screen select “New Project...”, or use the icon in the menu bar at the top, or the drop-down menu selection

    • Input a project name such as “IDF_DemoLab”, leave the project location as default

    • On the left of the screen (ignoring the Project Navigator which you may close if you wish) select the Analysis Target “Android device (ADB)”

    • You may receive a “Verify apps?” prompt on the device at this point, go ahead and Accept.

    • Default values of “Launch Application” via ADB on device “######” should be visible (in other words it should auto detect the existence of the Nexus Player at this point).Change “Launch Application” to “Launch Android Package”

    • Select the Package name either by typing it in or by browsing for the VLC player previously installed. “org.videolan.vlc”

    • We’ll limit the length of data capture for the purposes of this lab

      • Check the “Automatically stop collection after (sec):” and put in a value of 30.This will automatically stop data collection after 30 seconds.

      • Leave the box for “Automatically resume collection after (sec):” unchecked and value blank.Note that using this option would allow for a specified number of seconds after the app launches for you to select a video to play before collection starts.For this lab go ahead and leave it blank and unchecked so we’ll make sure to analyze user activities as well as the automatic operations.

    • All other default selections should be fine, but feel free to explore and become a bit more familiar with what can be changed.

    • Select “Choose Analysis” or select the “Analysis Type” tab to get to the next step.

      • Note: "Binary/Symbol Search" and "Source Search" buttons below the "Choose Analysis" are used to provide VTune with Symbol and Source code information for more meaningful analysis results when profiling your own code.  The directory information for these files can be provided now or later simply by accessing the project properties or results screen and re-resolving symbol information (another button).

  • Now that the device is rooted you’ll notice we’ve got the option for several types of analysis such as “Basic Hotspots”, “Advanced Hotspots”, and “General Exploration”

  • For this example we’ll pick “Advanced Hotspots”

    • Use the default value of 1 for the CPU sampling interval

    • Select the “Hotspots” level of detail.Note some of the warning messages which appear when attempting other levels of detail as greater level of driver support enables greater levels of data collection.

    • Check the “Analyze user tasks” selection box

    • Uncheck the “Analyze GPU usage” as we don’t have Intel HD Graphics on this device, and ensure the “Analyze Processor Graphics hardware events:” selection is set to “None”

    • When ready go ahead and click “Start”

  • If the screen-saver on your device has triggered then click the remote to go back to the main menu, you should notice a “Waiting for debugger” message and then VLC will launch.

  • Go ahead and select a video to play during the collection (recommend the “Earth Timelapse”)

  • After 30 seconds VLC will automatically close and the results will be pulled off the device and into VTune

  • At this point you will see a lot of warnings scrolling past in the collection log screen.This is because we have not specified where VTune can find the symbol information for all the function calls associated with every piece of code run during the collected event.

     

Reviewing the results

  • At this point we will take just a brief moment to look at the results being shown in VTune, starting with the summary screen which immediately pops up upon completion of processing the collected data.

  • Hotspots Viewpoint (with pop-up description and option to de-select showing this pop-up every time)

    • Note that clicking on “change” will allow different viewpoints to be selected.This is still the same data from the same collected event, however the analysis is presented using slightly different metrics.This allows you to pick a viewpoint most appropriate to your situation.Here we will stick with Hotspots Viewpoint.

  • Summary tab: Basic high level information, how long the collection took, top most active functions during the event, CPU Usage histogram, collection and platform information.Note that on the CPU Usage Histogram you may use the sliders to re-define “poor”, “ok”, and “ideal”.

  • Bottom-up tab: Easy way to quickly identify which specific function is taking most of the time during the collection event.Particularly useful if you’ve got a code bottleneck causing a problem.

    • Several options available in the “Grouping” to change how the CPU time Pareto data can be grouped for display

    • Graph on the bottom can similarly be changed whether to show data by thread, process, etc.

    • Graph may also be used to zoom in, highlight and select specific time slice, even filter other data to a specific time segment so that you can then view the above Pareto for information filtered around a specific time of interest.

  • < >

    Top-Down Tree: Similar to the bottom-up display but instead looking at the function stack from the top down.It’s worth noting that double clicking on a specific function name either here or in the bottom-up view will open a new tab showing the specific code segment of interest.If proper symbol and source data is provided then this will take you to the specific source code file, otherwise the assembly code is showed.

  • Platform: basically a full screen view of the time-plot shown at the bottom of the Bottom-up and Top-Down screens.Allows for much better visibility. Notice that hovering the mouse pointer over various items will result in a pop-up text with some additional information such as thread ID, CPU utilization or similar

 

Installing additional drivers

  • Here we will install some additional drivers to improve collection capabilities beyond what’s by default built into the kernel.In this case we’re adding modular drivers which can be installed and removed while the device is running.Optionally when developing a device image yourself you can build these drivers in directly (typically done for the sep and pax drivers).

  • Ensure that you’ve got root access on the device by running adb root

  • Shell over to the device with adb shell

  • Re-mount the root filesystem as read-write (you may confirm prior to this that it’s read only by trying to create a new directory) with mount –o rw,remount /

  • Create a /lib directory with mkdir /lib  then a modules subdirectory with mkdir /lib/modules

  • Note that there is already a /system/lib directory and normally we would have a modules subdirectory there in which to put our drivers.Unfortunately experimentation with this device showed insufficient disk space in that directory structure to copy over the files, so we go with the alternate location /lib/modules.VTune automatically looks for several of these drivers in both /system/lib/modules and /lib/modules as their location can vary from device to device

  • Exit from your adb shell and then push the ko driver files from their directory on your host

    • < >

      adb push pax.ko /lib/modules

    • adb push sep3_15.ko /lib/modules

    • adb push socperf1_2.ko /lib/modules

    • adb push socwatch2_0.ko /lib/modules

  • Go ahead and load the pax and sep drivers on the device before running another Hostspot analysis.

    • adb shell

    • insmod /lib/modules/pax.ko

    • insmod /lib/modules/sep3_15.ko

    • < >

      Now you can verify that they were used by checking the ~/intel/amplsys/projects/<your project name>/<collection run>/data.0/ directory. Note that your first run (likely the r000ah run directory) indicates usage of the perf driver for collection as you can see from some of the filenames.Your next run should have some sep######.tb6 file.

    • Take another event collection just like in step 3 but while the collection is happening try doing something slightly different, such as jump around to different points in the video using the remote

    • Now you may take some time like in section 4 to review the results, notice that in addition to the “Welcome” tab your results show up in different tabs near the top of the screen with names for your results such as “r001hs” and “r002hs”.It is possible to switch back and forth between these tabs and look at the differences between these events, but that can become difficult.

    • Select “Compare Results” using either the icon which looks like a circle cut into two half circles byvertical stripe, or using the keyboard short-cut CTRL+ALT+O

    • Select your two runs of interest using the pull down menus for Result 1 and Result 2, then click on “Compare”

    • This may require closing the tabs of the specific results in some versions of VTune (but not in this one), and will open a new tab labeled something like “r001hs-r002hs” with some direct metric by metric comparison information shown for the two results as well as the difference.

    • Explore around, imagine how this might be useful for your specific application

  •  

     Power/Energy profiling using Intel Energy Profiler

     

     

    Building the root boot.img image:

    Setup build environment, and perform repo sync per instructions at:

    http://source.android.com/source/building.html

    While doing the repo init make sure to specify the appropriate branch as determined by the lookup table here: http://source.android.com/source/build-numbers.html#source-code-tags-and-builds

     Note: the IDF lab was done using branch android-5.1.1_r1 for build LMY47V, at the time the latest build available for the Nexus Player device

    After initial AOSP repo sync is finished but before running make:

    Checkout kernel source:

    git clone https://android.googlesource.com/kernel/x86_64.git

    cd x86_64

    git branch –a (see a list of branches available)

    git checkout android-x86_64-fugu-3.10-lollipop-mr1

    make fugu_defconfig

    NOW EDIT THE .config – Where CONFIG_MODULES is not set, change to  CONFIG_MODULES=y

    (There will be additional config options needing answers – I don’t recall answering YES to any of the additional prompts, but memory may be a fickle thing.)

    Make –j8

    cd ..

    Download all the proprietary stuff (mentioned in the source.android.com instructions under “Building for Devices” and located here https://developers.google.com/android/nexus/drivers ):

    wget https://dl.google.com/dl/android/aosp/asus-fugu-lmy47v-f7524060.tgz

    wget https://dl.google.com/dl/android/aosp/broadcom-fugu-lmy47v-8ce8ebda.tgz

    wget https://dl.google.com/dl/android/aosp/google-fugu-lmy47v-c77f7094.tgz

    wget https://dl.google.com/dl/android/aosp/intel-fugu-lmy47v-0bb60afb.tgz

    wget https://dl.google.com/dl/android/aosp/widevine-fugu-lmy47v-ee5d30ed.tgz

    NOW execute the ‘extract-*.sh’ scripts which came from the tarballs

    Build the bootimage:

    source build/envsetup.sh

    lunch aosp_fugu-userdebug

    export TARGET_PREBUILT_KERNEL=<AOSP_PATH>/x86_64/arch/x86/boot/bzImage

    make bootimage –j8

    boot.img should be located in <AOSP_PATH>/out/target/product/fugu/

     

    Building the SEP and SoC Watch drivers:

    SoC Watch driver build:

    Download the available and desired version of SoC Watch (included in your distribution of Intel System Studio in the targets/system_studio_target.tgz zip file).

    Follow the instructions in the included User Guide pdf document (usually section 2.2, “Building the Kernel Modules”).

    GOTCHA#1: Make sure to specify the kernel-build-directory correctly when prompted while building the soc_perf_driver.  Kernel-build-directory will be the <AOSP_SRC>/x86_64/ directory you created while building the kernel.

    GOTCHA#2: When building the socwatch_driver make sure to include the –s option with the path to the Module.symvers file in the soc_perf_driver/src/ directory created during the soc_perf_driver build step.

    SEP driver build:

    Very similar to the SoC Watch driver build.  Necessary files are included in the VTune Amplifier component of Intel System Studio in the /opt/intel/vtune_amplifier_for_systems/sepdk directory.  Simply cd into that directory and run the ./build-driver script, making sure to provide the appropriate path to the kernel-build-directory in order to get the security signature correct.  This should create all the drivers needed, however it may be necessary to go into the pax and vtsspp subdirectories and run their respective build-driver scripts to ensure that those drivers get built.  The first should create a sepx_xx.ko where the x’s are replaced by the specific version of the driver (such as sep3_15.ko from our lab example), the pax directory should create a pax.ko file.

     

    • Energy Analysis with the socwatch collector is a much more manual process involving running the collector manually on the device through an adb shell, or through the use of a specially designed app to run the collector

    • Install the socwatch collector onto the device from the host.  Navigate to the SoC Watch directory and run the install script ./socwatch_android_install.sh

      • Note: SoCWatch collector can be obtained from your installation of Intel System Studio by unzipping the system_studio_target.tgz file located in the Targets sub-directory of the Intel System Studio install directory.  This unzipped directory will contain both the referenced install script (for both Windows and Linux) as well as a User Guide in pdf format.

    • Shell to the device, setup the run environment and load the driver modules

      • adb root

      • adb shell

      • cd /data/socwatch

      • . ./setup_socwatch_env.sh  (you may also run source ./setup_socwatch_env.sh as the idea is to apply all of the script environment settings to the current shell)

      • insmod /lib/modules/socperf1_2.ko

      • insmod /lib/modules/socwatch2_0.ko

    • Now get ready to run a collection, navigate as desired using the device remote depending upon what you wish to profile (get ready to launch your app, or leave it in screen saver if you’re profiling the device as idle)

    • Now run a socwatch collection, you may look at several of the possible options with the socwatch –h command.Here is an example which will run a collection for 30 seconds and save the results in the /data/socwatch/results/ directory.

      • Note that each run you will want to use a different name for the results, to avoid overwriting previous results and possibly adding some confusion with multiple results existing in the same file.

      • socwatch –m –f cpu –f sys –t 30 –r vtune –o ./results/test1

      • Now check the results directory and you should find three files, test1.csv test1.sw2 and test2.pwr.The csv file is a comma separated value file for use in third party analyzers, the pwr file is the input file for VTune, and the sw2 is the raw output file.

        • Note: If you were running socwatch 1.x then there would be no pwr file and you would directly import the sw1 file into VTune.

    • Exit from the device shell, and pull the results into your SWResults directory

      • < >

        cd ~/IDFLab/SWResults

      • adb pull /data/socwatch/results/test1.pwr

    • Load the results in VTune.

      • In VTune select “Import Results” on the Welcome tab or the corresponding icon at the top of the VTune window, or use the keyboard shortcut CTRL+ALT+N

      • Under “Import a directory” select browse and select the ~/IDFLAB/SWResults/ directory with the file you just pulled from the device.Then click Import.

        • Note: This was only necessary due to the specific pre-production versions of software we are using for this lab.For any version you will have which includes a copy of SoCWatch it will be able to import the single individual file with the “import a single file” option and then select the specific sw1 or pwr file of interest (sw1 files are imported from SoCWatch version 1.x, pwr files are imported from SoCWatch 2.0)
    • The results will be processed and then displayed much in the same way the performance analysis is displayed.Notice you still have the Summary tab, but you now have CPU C/P States, core Wake-ups, Correlate Metrics, and the selected viewpoint is “Platform Power Analysis viewpoint” rather than “Hotspots viewpoint”.Histogram information on the summary screen now shows CPU frequency and Core sleep state rather than showing CPU Usage.

      • Note: More tabs with more data will be available depending upon the specific –f feature options used during the collection.

 

Notes for setting up Ubuntu to work for the lab host system

Create a file: /lib/udev/rules.d/51-android.rules this will allow adb to access the device

  •   SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666"

          

    apt-get install android-tools-adb android-tools-fastboot

        Or NOT, having some trouble with android-tools-fastboot.  Seems to work when using SDK/platform-tools/fastboot  and adb as provided by the Android SDK, so may stick with that.

     

    JDK:

       Apt-get install openjdk-7-jdk  

    Or

       Apt-add-repository ppa:webupd8team/java

       Apt-get update

       Apt-get install oracle-jdk7-installer

     

    Need ia32-libs

       Apt-get install lib32z1

     

    ~/.bashrc edit

    #AndroidDev PATH
    
    export PATH=$PATH:/home/username/sdk/tools

     

     

    Legal Stuff:

    Intel, VTune, and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

    *Other names and brands may be claimed as the property of others.

    © 2015 Intel Corporation

Targeting Android* Apps on x86- and ARM*-based devices with Visual Studio* 2015

$
0
0

Download PDF

Android APKs can support seven different architectures as defined by the presence of .so files (native libraries) in the lib/<ABI> folders in the APK. Where <ABI> corresponds to the supported architectures, that is, on Android: armeabi, armeabi-v7a, x86, mips, arm64-v8a, mips64, x86_64.

All the architectures are automatically supported in case there is no .so files inside an APK, but that’s not the case with Visual Studio* 2015 projects. APKs from Visual Studio* 2015 Android* application projects generate CPU-specific APKs, whether they’re C# (Xamarin) or Visual C++ projects.

It’s a good practice to support all the architectures Android can run on, from a single APK. If it makes the APK too big or if it’s simply not possible to do so with a specific toolchain, it’s also possible for an application to have multiple APKs, each targeted to different architecture, on the Play* Store.

You must follow one simple rule for properly packaging and distributing multiple APKs: Version codes have to differ and be preferably ordered this way:

x86_64 versionCode > arm64-v8a > mips64 > x86 > mips > armeabi-v7a > armeabi

The reason for this rule is that the Play Store will always distribute the APK that has the highest version code, from the ones that are compatible with the client device. x86(_64) devices may be able to run ARM APKs too, so the highest version codes have to go to the x86_84 and x86 APKs in order for the right APKs to be distributed onto the devices that can run them better.

For Visual C# (Xamarin) projects

In debug mode, the .so files for all the architectures are embedded by default. That may give you the impression that everything is fine while you’re developing, but in fact, in release mode only armeabi libs are integrated by default.

To change that, open your application properties, and under Android Options, Advanced, tick all the architectures you want to support:

Application properties and Android Options

When you run a release build, the output will be an APK containing libs for all the selected architectures:

APK containing libs for all the selected architectures

If you want to trim down the size of this APK, you can enable the build to generate one APK per architecture (the version codes will be correctly handled by default):

Enable the build to generate one APK per architecture

To see how to upload these multiple APKs to a single application on the Play Store you need to follow the steps described at the end of this article.

For Visual C++ projects

Visual C++ projects are enabled by default for two targets: ARM (armeabi-v7a) and x86.

Visual C++ projects are enabled by default for two targets

However, building for x86 or ARM generates an APK containing only x86 or ARM .so files. This is fine, but these APKs have the exact same versionCode, the one set in AndroidManifest.xml. That means they can’t both be uploaded to the Play Store for the same application.

You can fix this by making Visual Studio 2015 generate both ARM and x86 APKs with different version codes by adding a custom ant rule.

Create a file named “custom_rules.xml” with this content:

<project name="custom_rules"><available file="libs/x86" property="x86Dir.exists"/><available file="libs/armeabi-v7a" property="armDir.exists"/><target name="-pre-build-x86" if="x86Dir.exists" unless="armDir.exists"><echo>prefixing version code with 5 (for x86 ABI).</echo><replaceregexp file="AndroidManifest.xml" match="android:versionCode.*([0-9]+).*"
        replace='android:versionCode="5\1"'/></target><target name="-pre-build-arm" if="armDir.exists" unless="x86Dir.exists"><echo>prefixing version code with 3 (for armeabi-v7a ABI).</echo><replaceregexp file="AndroidManifest.xml" match="android:versionCode.*([0-9]+).*"
        replace='android:versionCode="3\1"'/></target><target name="-pre-build" depends="-pre-build-x86,-pre-build-arm" /></project>

And put it next to the build.xml file, at the root of the Packaging project:

Root of the Packaging project

Once this is done, the version codes will be prefixed with a 5 for x86 APKs and a 3 for ARM APKs. This way the generated APKs can be uploaded straight to the Play Store, as described in the next section.

Publishing Multiple APKs to the Play Store

Go to the APK upload page and click “Switch to advanced mode” if you need to:

Switch to advanced mode

Then, upload your APKs with different ABI support and version codes. They should appear like on the APK management screen, with a summary of their differences and version codes:

APK management screen

If something isn’t right, you can use aapt from the Android build tools to check which versionCode and native-code are supported by an APK:

>C:\Android\sdk\build-tools\23.0.0-preview\aapt.exe dump badging App1.apk
package: name='com.xhallade.test versionCode='81' versionName='1.0' platformBuildVersionName='5.1.1-1819727'
…
native-code: 'x86_64'>

If you want to do the same directly from an Android device and check what .so files are getting installed at the same time, you can use Native Libs Monitor.

References

Processor Trace Sample of System Debugger within Intel® System Studio 2016

$
0
0

Overview

Intel® System Debugger 2016 is the complete system debug solution provides deep insight into memory and system configuration.

Key features of Intel® System Debugger 2016:

  • JTAG debug for Intel® Atom™, Core™, Xeon® & Quark™ SoC-based platforms
  • EFI/UEFI Firmware, bootloader debug, Linux* OS awareness
  • Dynamically loaded Linux kernel module debug
  • In depth visualization of memory configuration, system state and register sets
  • LBR & Intel® Processor Trace On-Chip instruction trace support
  • JTAG debug & instruction trace to Microsoft* WinDbg* kernel debugger
  • System Trace: System-wide hardware and software event trace

Intel® Processor Trace is the hardware based low overhead code execution logging on instruction level and provides a powerful and deep insight into past instruction flow combined with interactive debug.

Key features of Intel® Processor Trace:

  • Low-overhead execution tracing feature
  • Capturing information about software execution
  • Reconstruct the exact program flow

More Details are in the PDF file attached. (Please click link below.)

PDF FILE: Intel® System Studio – System Debugger – Processor Trace Sample

It consists of:

Overview of Intel® System Debugger and Processor Trace

    Details on Intel® System Debugger and Processor Trace

    Intel® Processor Trace Decoder Flow

Intel® System Debugger and Processor Trace Sample

    Test Environment

    Configurations

    Intel® Processor Trace Sample

Example: Intel® Processor Trace and Call Stack Saved in XDB via command console.

 

Multi-OS Engine: Known Issues

$
0
0

Runtime
Apple iOS* API Bindings
Integration with Android Studio
Layout Editor
Local build
Remote build
Installation
UI Binding Generator


The known issues apply to Multi-OS Engine update 1 (version 1.0 build 285)

Runtime 

  • The only class loader the runtime supports is the bootstrap class loader. It constructs NoClassDefFoundError exceptions without detailed messages.
  • The runtime is derived from Android* ART and inherits most Java packages it implements. The preloaded-classes.txt file, which resides in the installation directory, contains the list of the implemented Java packages:
    • To use Java packages that are not on the list add them as external dependencies for your project.
    • If external dependencies for your project implement classes on the list, the build will fail (the dex2oat tool will fail with an error message like “dex2oat ... Check failed: method != NULL”).
  • The runtime does not contain an implementation of JDBC Driver.

Apple iOS* API Bindings 

  • Using methods with Ptr<? extends ObjCObject> in applications targeting Mac OS X* host can lead to crash with null pointer exception if you working with pointers returned from native, not created yourself.
  • If a ‘Division by 0’ exception occurs after an incorrect NatJ initialization, start working with NatJ by creating an Obj-C class that implements a UIApplicationDelegate interface.
     
  • Missed NatJ annotations or misprints are not checked by the build system or NatJ initializer. Manually written methods with inaccuracies in annotation can lead to exceptions in runtime and undefined behavior.
     
  • Double pointer to primitive types as a return value from methods of binded objects is not supported.

Integration with Android Studio 

  • Multi-OS Engine samples require setting the active JDK version to 1.8 manually in Android Studio. “Invalid source release: 1.8” error will occur if this isn’t done. To resolve this issue, go to Android Studio* to File -> Project Structure -> SDK Location -> JDK location and specify the path to JDK 1.8.
  • When the debugger is not closed properly, it leaves the device in the state which will not allow you to restart and use the debugging again. This is true even if you reboot the device. One workaround is to debug projects from XCode on the device. This will reset the state.
  • When you add “Intel MOE Module” to your project, it is always added to the root directory of the project, regardless of the project directory you have chosen.
  • If you manually installed a previous version of iOS Simulator* (for example iOS Simulator* 8.3 to the system which had already installed iOS SDK* 8.4), the build project may fail with error “SDK 8.3 not found”. The workaround is to explicitly specify the installed iOS SDK* version in the build configuration.
  • IPA build (“Export IPA for Application” from Android Studio* “Build” menu) may fail immediately after you import a project. The workaround is to press the “Project” tab located on the left side of Android Studio. After that IPA export will be successful.
  • Removing the storyboard file can cause the following build error: “Could not find a storyboard named “MainUI” in NSBundle”. The problem will disappear after running build again.

Layout Editor 

  • For the correct rendering of widgets, you must have Android SDK* with API level 9 or higher installed.
  • Constraints can be conflicted for difficult UI written in iXML. XCode cannot manage conflict situations with constraints. As a result, generated constraints do not match with XCode constraints.

Local build 

  • If Gradle Daemon is enabled, the build may fail with an error message like the following: “Could not find “/../SharedFrameworks/DVTFoundation.framework”. You can fix this by disabling Gradle Daemon: remove “org.gradle.daemon=true” line from the ~/.gradle/gradle.properties file.

Remote build 

  • Build may fail with the “User interaction is not allowed” error. In this case, you may have to grant the “codesign” tool permissions to access some specific resources. For details, refer to Getting Started tutorials at resources given in the Customer Support section of this document.

Installation 

  • In rare cases, Multi-OS Engine plugins for Android Studio* will not be installed automatically. It can occur if you use a pre-release version of the Android Studio* or when Multi-OS Engine plugins could not be loaded previous time and Android Studio* disabled the plugins.
    After installation, please verify that two plugins “Intel INDE MOE Plugin” and “Intel INDE MOE Layout Editor” are enabled in the Preferences-> Plugins menu of Android Studio*. If you cannot find them there, please install them manually using “Install plugin from disk” button from “<MOE install directory>/intellij_plugins” directory.
  • If you log in to a Mac OS X* system with a “root” account, Android Studio* will not see the INTEL_MULTI_OS_ENGINE_HOME environment variable. As a result, Multi-OS Engine plugins for Android Studio* will not function. Please use a regular user account to work with the Multi-OS Engine capability.

UI Binding Generator 

  • Unstable work of UI binding generation feature. With correct .xib; .storyboard; .m; .h files UI binding generation procedure may require more than one attempt.
  • For successfully UI binding generation, all necessary files (.storyboard, .xib, .h, .m) should place in xcode project directory. In current version this feature do not support reference on files in Xcode project.
  • Generation UI binding for existing Java View Controller leads to that existing outlets and actions(in Java View Controller) stop working. The cause is difference in declarations of existing and generated outlets and actions.

  • Workaround steps:
    1. Add annotation ‘@Property’ in Java code for all generated outlets
    2. Add implementation in Java code for all generated actions
    3. Exclude native source files (with implementation of view controllers) from the build procedure.

Intel® System Studio 2016 - What's New

$
0
0

What's New in Intel® System Studio 2016

  • Support for new platforms based on Airmont, Intel® Quark™, Edison and SoFIA by various Components.
  • Intel® C++ Compiler:
    • Enhanced C++11 feature support
    • Enhanced C++14 feature support
    • FreeBSD* support
  • Intel® VTune Amplifier for Systems:
    • Basic Hotspots, Locks and Waits and hardware event-based stack sampling collection supported for RT kernel and RT applications for Linux* targets
    • Hardware event-based stack sampling collection supported for kernel-mode threads
    • Support for Intel® Atom™ x7 Z8700 & x5 Z8500/X8400 processor series (Cherry Trail) including GPU analysis
    • KVM guest OS profiling based on the Linux* Perf tool
    • Analysis of applications in a virtualization environment (KVM) for Linux* kernels  (version 3.2 and higher) and QEMU (version 1.4 and higher)
    • Remote event-based sampling analysis on SoFIA  leveraging an existing sampling driver on the target
  • Intel® Threading Building Blocks (Intel® TBB):
    • Several C++11 improvements
    • Added 64-bit Android* support
  • Intel® Integrated Performance Primitives (Intel® IPP):
    • Extended optimization for Intel® Atom™ processors in the Computer Vision and Image Processing functions
    • Added optimization for Intel® Quark™ processors to the Cryptography functions
  • Intel® Math Kernel Library (Intel® MKL):
    • New ?GEMM_BATCH and (C/Z)GEMM3M_BATCH functions for performing multiple independent matrix-matrix multiply operations
    • New C-language version of the Intel® MKL reference manual
  • Intel® System Debugger:
    • Support for new platforms based on Airmont microarchitecture: Moorefield (Z35XX), Cherrytrail (Z8700), Braswell (N3700)
    • New supported targets: 6th Generation Intel® Core™ Processor Family, Intel® 100 Series Chipset.
  • For 6th Generation Intel® Core™ Processor Family :
    • Intel® Debug Extensions for WinDbg* with Intel® Processor Trace support and JTAG debug support
    • System Trace support for Intel® Trace Hub
    • Intel® Debugger for Heterogeneous Compute
    • The debugger supports 64-bit host OS systems only and requires a 64-bit Java* Runtime Environment (JRE) to operate. See System Debugger release notes for more details.
  • The installation directories structure has changed. Several components link to common directories which are shared with other Intel® Software Development Products. 

Get Help or Advice

Getting Started?
Click the Learn tab for guides and links that will quickly get you started.
Support Articles and White Papers – Solutions, Tips and Tricks

Resources
Documentation
Training Material

Support

We are looking forward to your questions and feedback. Please don't hesitate to escalate any questions you have or issues you run into. We thank you for helping us to continuously improve Intel® System Studio

Intel® Premier Support – (registration is required) - For secure, web-based, engineer-to-engineer support, visit our Intel® Premier Support web site. Intel Premier Support registration is required. Once logged in search for the product name Intel® System Studio.

Please provide feedback at any time:

Intel® System Studio - Solutions, Tips and Tricks

$
0
0

Intel® System Studio Release Notes and Getting Started Documents

$
0
0

This page provides the current Release Notes and Getting Started Documents for Intel® System Studio 2016.

To get product updates, log in to the Intel® Software Development Products Registration Center.

For questions or technical support, visit Intel® Software Products Support.

Contents

 

Current Release Notes

Intel® System Studio 2016 for Linux* and Android*(1)

(1) Android*, Linux*, Embedded Linux*, Yocto Project*, Wind River* Linux*

Studio ComponentLinux* Host Windows* Host

What's New

What's new?

What's new?

Intel® System Studio (full product)

Version 2016

Version 2016

Intel® C++ Compiler

Version 16.0

Version 16.0

Intel® Math Kernel Library

Version 11.3

Version 11.3

Intel® Integrated Performance Primitives

Version 9.0

Version 9.0

Intel® Threading Building Blocks

Version 4.4

Version 4.4

Intel® VTune™ Amplifier for Systems

Version 2016

Version 2016

Intel® Energy Profiler

Version 2016

Version 2016

Intel® Inspector for Systems

Version 2016

Version 2016

Intel® System Studio System Analyzer,Frame Analyzer and Platform Analyzer

Version 2015 R1

Version 2015 R1

Intel® System Debugger

Version 2016

Version 2016

GDB - The GNU* Project Debugger

Version 7.8.1

Version 7.8.1

Intel® System Studio 2016 for Windows*

Studio ComponentWindows* Host

What's New

What's new?

Intel® System Studio for Windows* (full product)

Version 2016

Intel® C++ Compiler

Version 16.0

Intel® Math Kernel Library

Version 11.3

Intel® Integrated Performance Primitives

Version 9.0

Intel® Threading Building Blocks

Version 4.4

Intel® VTune™ Amplifier for Systems

Version 2016

Intel® Energy Profiler

Version 2016

Intel® Inspector for Systems

Version 2016

Intel® System Studio System Analyzer, Frame Analyzer and Platform Analyzer for Windows*

Version 2015 R1

Intel® System DebuggerVersion 2016

Older Release Notes

Intel® System Studio

Linux* Host Windows* Host
 Version 2015 Update 3Version 2015 Update 3
 

Version 2015 Update 2

Version 2015 Update 2

 

Version 2015 Update 1

Version 2015 Update 1

 

Version 2015

Version 2015

 

Version 2014 Update 2

Version 2014 Update 2

 

Version 2014 Update 1

Version 2014 Update 1

 

Version 2014

Version 2014

 

Version 2013 Update 2

 

 

Version 2013 Update 1

 

 

Version 2013

 

 

Intel® System Studio 2015

Getting Started Guide

Studio Componentfor Linux* and Android*
(Linux* Host)
for Linux* and Android*
(Windows* Host)
for Windows*

Intel® System Studio

Getting Started Guide

Getting Started Guide

Getting Started Guide

Intel® C++ Compiler for Linux* and Android* targets

Intel® C++ Compiler Getting Started Guide

Intel® C++ Compiler Getting Started Guide

 

Intel® Integrated Performance Primitives

Getting Started with Intel® Integrated Performance Primitives
Building Android* NDK Applications with Intel® IPP

Getting Started with Intel® Integrated Performance Primitives

Getting Started with Intel® Integrated Performance Primitives

Intel® Math Kernel Library

Using Intel® Math Kernel Library

Using Intel® Math Kernel Library

Using Intel® Math Kernel Library

Intel® VTune™ Amplifier for Systems

Getting Started Guide

Getting Started Guide

Getting Started Guide

Intel® Inspector for Systems

Intel® Inspector for Systems Getting Started Guide

Intel® Inspector for Systems Getting Started Guide

Intel® Inspector for Systems Getting Started Guide

Intel® System Studio System Analyzer

Intel® System Studio System Analyzer Getting Started Guide

Intel® System Studio System Analyzer Getting Started Guide

Intel® System Studio System Analyzer Getting Started Guide

Intel® System Debugger

Intel® System Debugger Quickstart Guide

Intel® System Debugger Quickstart Guide

 

Intel-enhanced GNU* GDB

GNU* GDB Getting Started Guide
GNU* GDB Quickstart Guide

GNU* GDB Getting Started Guide
GNU* GDB Quickstart Guide

 

 

Intel® System Studio 2015

User Guide

Studio ComponentLinux* HostWindows* Host

Intel® System Studio

User Guide

User Guide

Intel® Math Kernel Library

User's Guide for Intel® Math Kernel Library

User's Guide for Intel® Math Kernel Library (Linux* Target)
User's Guide for Intel® Math Kernel Library (Windows* Target)

Intel® VTune™ Amplifier for Systems

Sampling Enabling Product User's Guide

Sampling Enabling Product User's Guide

Intel® Energy Profiler

SoC Watch Tool User's Guide

SoC Watch Tool User's Guide

 

WakeUp Watch Tool for Android* User's Guide

WakeUp Watch Tool for Android* User's Guide

Graphics Performance Analysis Tools

Intel® System Studio System Analyzer

Intel® System Studio System Analyzer, Frame Analyzer and Platform Analyzer

Intel® System Debugger

Use Cases for the Intel® System Debugger

Use Cases for the Intel® System Debugger

 

Intel® System Debugger User's Guide

Intel® System Debugger User's Guide

SVEN SDK

SVEN SDK User Guide

SVEN SDK User Guide

 

SVEN Trace Viewer User Guide

SVEN Trace Viewer User Guide

GDB - The GNU* Project Debugger

Debugging with GDB

Debugging with GDB

Intel® XDK FAQs - Debug & Test

$
0
0
Q1: What are the requirements for Testing on Wi-Fi?
  1. 1) Both Intel XDK and App Preview mobile app must be logged in with the same user credentials.
  2. 2) Both devices must be on the same subnet.

Note: Your computer's Security Settings may be preventing Intel XDK from connecting with devices on your network. Double check your settings for allowing programs through your firewall. At this time, testing on Wi-Fi does not work within virtual machines.

Q2: How do I configure app preview to work over Wi-Fi?

1) Ensure that both Intel XDK and App Preview mobile app are logged in with the same user credentials and are on the same subnet

2) Launch App Preview on the device 

3) Log into your Intel XDK account 

4) Select "Local Apps" to see a list of all the projects in Intel XDK Projects tab 

5) Select desired app from the list to run over Wi-Fi  

Note: Ensure the app source files are referenced from the right source directory. If it isn't, on the Projects Tab, change the 'source' directory so it is the same as the 'project' directory and move everything in the source directory to the project directory. Remove the source directory and try to debug over local Wi-Fi.

Q3: How do I clear app preview cache and memory?

[Android*] Simply kill the app running on your device as an Active App on Android* by swiping it away after clicking the "Recent" button in the navigation bar. Alternatively, you can clear data and cache for the app from under Settings App > Apps > ALL > App Preview. 

[iOS*] By double tapping the Home button then swiping the app away. 

[Windows*] You can use the Windows* Cache Cleaner app to do so.

Q4: What are the Android* devices supported by App Preview?

We officially only support and test Android* 4.x and higher, although you can use Cordova for Android* to build for Android* 2.3 and above. For older Android* devices, you can use the build system to build apps and then install and run them on the device to test. To help in your testing, you can include the weinre script tag from the Test tab in your app before you build your app. After your app starts up, you should see the Test tab console light up when it sees the weinre script tag contact the device (push the "begin debugging on device" button to see the console). Remember to remove the weinre script tag before you build for the store. 

Q5: What do I do if Intel XDK stops detecting my Android* device?

When Intel XDK is not running, kill all adb processes that are running on your workstation and then restart Intel XDK as conflicts between different versions of adb frequently causes such issues. Ensure that applications such as Eclipse that run copies of adb are not running. You may scan your disk for copies of adb: 

[Linux*/OS X*]:

$ sudo find / -name adb -type f 

[Windows*]:

> cd \> dir /s adb.exe

For more information on Android* USB debug, visit the Intel XDK documentation on debugging and testing.

Q6: My third party plugins do not show up on the debug tab. How do I debug an app that contains third party plugins?

If you are using the Debug, Emulate or Test tabs you will not see any third-party plugins. At the moment, the only way to debug an app that contains a third-party plugin is to build it and debug the built app installed on your device. We are working on a solution to work with third-party plugins, but it is still in development. 

[Android*]

1) For Crosswalk* or Cordova for Android* build, create an intelxdk.config.additions.xml file that contains the following lines: 

<!-- Change the debuggable preference to true to build a remote CDT debuggable app for --><!-- Crosswalk* apps on Android* 4.0+ devices and Cordova apps on Android* 4.4+ devices. --><preference name="debuggable" value="true" /><!-- Change the debuggable preference to false before you build for the store. --> 

and place it in the root directory of your project (in the same location as your other intelxdk.config.*.xml files). Note that this will only work with Crosswalk* on Android* 4.0 or newer devices or, if you use the standard Cordova for Android* build, on Android* 4.4 or greater devices.

2) Build the Android* app

3) Connect your device to your development system via USB and start app

4) Start Chrome on your development system and type "chrome://inspect" in the Chrome URL bar. You should see your app in the list of apps and tabs presented by Chrome, you can then push the "inspect" link to get a full remote CDT session to your built app. Be sure to close Intel XDK before you do this, sometimes there is interference between the version of adb used by Chrome and that used by Intel XDK, which can cause a crash. You might have to kill the adb process before you start Chrome (after you exit the Intel XDK). 

[iOS*]

Refer to the instructions on the updated Debug tab docs to get on-device debugging. We do not have the ability to build a development version of your iOS* app yet, so you cannot use this technique to build iOS* apps. However, you can use the weinre script from the Test tab into your iOS* app when you build it and use the Test tab to remotely access your built iOS* app. This works best if you include a lot of console.log messages.

[Windows* 8]

You can use the test tab which would give you a weinre script. You can include it in the app that you build, run it and connect to the weinre server to work with the console.  

Alternatively, you can use App Center to setup and access the weinre console (go here and use the "bug" icon).  

Another approach is to write console.log messages to a <textarea> screen on your app. See either of these apps for an example of how to do that:  

Q7:  Why does my device show as offline on Intel XDK Debug?
“Media” mode is the default USB connection mode, but due to some unidentified reason, it frequently fails to work over USB on Windows* machines. Configure the USB connection mode on your device for "Camera" instead of "Media" mode.
Q8: What do I do if my remote debugger does not launch?

You can try the following to have your app run on the device via debug tab:  

  • Place the intelxdk.js library before the </body> tag
  • Place your app specific JavaScript files after it
  • Place the call to initialize your app in the device ready event function
Q9: Why do I get an "error installing App Preview Crosswalk" message when trying to debug on device?

You may be running into a RAM or storage problem on your Android device; as in, not enough RAM available to load and install the special App Preview Crosswalk app (APX) that must be installed on your device. See this site (http://www.devicespecifications.com) for information regarding your device. If your device has only 512 MB of RAM, which is a marginal amount for use with the Intel XDK Debug tab, you may have difficulties getting APX to install.

You may have to do one or all of the following:

  • remove as many apps from RAM as possible before installing APX (reboot the device is the simplest approach)
  • make sure there is sufficient storage space in your device (uninstall any unneeded apps on the device)
  • install APX by hand

The last step is the hardest, but only if you are uncomfortable with the command-line:

  1. while attempting to install APX (above) the XDK downloaded a copy of the APK that must be installed on your Android device
  2. find that APK that contains APX
  3. install that APK manually onto your Android device using adb

To find the APK, on a Mac:

$ cd ~/Library/Application\ Support/XDK
$ find . -name *apk

To find the APK, on a Windows machine:

> cd %LocalAppData%\XDK> dir /s *.apk

For each version of Crosswalk that you have attempted to use (via the Debug tab), you will find a copy of the APK file (but only if you have attempted to use the Debug tab and the XDK has successfully downloaded the corresponding version of APX). You should find something similar to:

./apx_download/12.0/AppAnalyzer.apk

following the searches, above. Notice the directory that specifies the Crosswalk version (12.0 in this example). The file named AppAnalyzer.apk is APX and is what you need to install onto your Android device.

Before you install onto your Android device, you can double-check to see if APX is already installed:

  • find "Apps" or "Applications" in your Android device's "settings" section
  • find "App Preview Crosswalk" in the list of apps on your device (there can be more than one)

If you found one or more App Preview Crosswalk apps on your device, you can see which versions they are by using adb at the command-line (this assumes, of course, that your device is connected via USB and you can communicate with it using adb):

  1. type adb devices at the command-line to confirm you can see your device
  2. type adb shell 'pm list packages -f' at the command-line
  3. search the output for the word app_analyzer

The specific version(s) of APX installed on your device end with a version ID. For example: com.intel.app_analyzer.v12 means you have APX for Crosswalk 12 installed on your device.

To install a copy of APX manually, cd to the directory containing the version of APX you want to install and then use the following adb command:

$ adb install AppAnalyzer.apk

If you need to remove the v12 copy of APX, due to crowding of available storage space, you can remove it using the following adb command:

$ adb uninstall com.intel.app_analyzer.v12

or

$ adb shell am start -a android.intent.action.DELETE -d package:com.intel.app_analyzer.v12

The second one uses the Android undelete tool to remove the app. You'll have to respond to a request to undelete on the Android device's screen. See this SO issue for details. Obviously, if you want to uninstall a different version of APX, specify the package ID corresponding to that version of APX.

Q10: Why is Chrome remote debug not working with my Android or Crosswalk app?

For a detailed discussion regarding how to use Chrome on your desktop to debug an app running on a USB-connected device, please read this doc page Remote Chrome* DevTools* (CDT).

Check to be sure the following conditions have been met:

  • The version of Chrome on your desktop is greater than or equal to the version of the Chrome webview in which you are debugging your app.

    For example, Crosswalk 12 uses the Chrome 41 webview, so you must be running Chrome 41 or greater on your desktop to successfully attach a remote Chrome debug session to an app built with Crosswalk 12. The native Chrome webview in an Android 4.4.2 device is Chrome 30, so your desktop Chrome must be greater than or equal to Chrome version 30 to debug an app that is running on that native webview.
  • Your Android device is running Android 4.4 or higher, if you are trying to remote debug an app running in the device's native webview, and it is running Android 4.0 or higher if you are trying to remote debug an app running Crosswalk.

    When debugging against the native webview, remote debug with Chrome requires that the remote webview is also Chrome; this is not guaranteed to be the case if your Android device does not include a license for Google services. Some manufacturers do not have a license agreement with Google for distribution of the Google services on their devices and, therefore, may not include Chrome as their native webview, even if they are an Android 4.4 or greater device.
  • Your app has been built to allow for remote debug.

    Within the intelxdk.config.additions.xml file you must include this line: <preference name="debuggable" value="true" /> to build your app for remote debug. Without this option your app cannot be attached to for remote debug by Chrome on your desktop.
Q11: How do I detect if my code is running in the Emulate tab?

In the obsolete intel.xdk apis there is a property you can test to detect if your app is running within the Emulate tab or on a device. That property is intel.xdk.isxdk. A simple alternative is to perform the following test:

if( window.tinyHippos )

If the test passes (the result is true) you are executing in the Emulate tab.

Q12: Never ending "Transferring your project files to the Testing Device" message from Debug tab; results in no Chrome DevTools debug console.

This is a known issue but a resolution for the problem has not yet been determined. If you find yourself facing this issue you can do the following to help resolve it.

On a Windows machine, exit the Intel XDK and open a "command prompt" window:

> cd %LocalAppData%\XDK\> rmdir cdt_depot /s/q

On a Mac or Linux machine, exit the Intel XDK and open a "terminal" window:

$ find ~ -name global-settings.xdk
$ cd <location-found-above>
$ rm -Rf cdt_depot

Restart the Intel XDK and try the Debug tab again. This procedure is deleting the cached copies of the Chrome DevTools that were retrieved from the corresponding App Preview debug module that was installed on your test device.

One observation that causes this problem is the act of removing one device from your USB and attaching a new device for debug. A workaround that helps sometimes, when switching between devices, is to:

  • switch to the Develop tab
  • close the XDK
  • detach the old device from the USB
  • attach the new device to your USB
  • restart the XDK
  • switch to the Debug tab
Q13: Can you integrate the iOS Simulator as a testing platform for Intel XDK projects?

The iOS simulator only runs on Apple Macs... We're trying to make the Intel XDK accessible to developers on the most popular platforms: Windows, Mac and Linux. Additionally, the iOS simulator requires a specially built version of your app to run, you can't just load an IPA onto it for simulation.

Q14: What is the purpose of having only a partial emulation or simulation in the Emulate tab?

There's no purpose behind it, it's simply difficult to emulate/simulate every feature and quirk of every device.

Q15: Not everyone can afford hardware for testing, especially iOS devices; what can I do?

You can buy a used iPod and that works quite well for testing iOS apps. Of course, the screen is smaller and there is no compass or phone feature, but just about everything else works like an iPhone. If you need to do a lot of iOS testing it is worth the investment. A new iPod costs $200 in the US. Used ones should cost less than that. Make sure you get one that can run iOS 8.

Q16: Is testing on Crosswalk on a virtual Android device inside VirtualBox good enough?

When you run the Android emulator you are running on a fictitious device, but it is a better emulation than what you get with the iOS simulator and the Intel XDK Emulate tab. The Crosswalk webview further abstracts the system so you get a very good simulation of a real device. However, considering how inexpensive and easy Android devices are to obtain, we highly recommend you use a real device (with the Debug tab), it will be much faster and even more accurate than using the Android emulator.

Q17: Why isn't the Intel XDK emulation as good as running on a real device?

Because the Intel XDK Emulate tab is a Chromium browser, so what you get is the behavior inside that Chromium browser along with some conveniences that make it appear to be a hybrid device. It's poorly named as an emulator, but that was the name given to it by the original Ripple Emulator project. What it is most useful for is simulating most of the core Cordova APIs and your basic application logic. After that, it's best to use real devices with the Debug tab.

Back to FAQs Main

Intel® XDK FAQs - General

$
0
0
Q1: How can I get started with Intel XDK?

There are plenty of videos and articles that you can go through here to get started. You could also start with some of our demo apps that you think fits your app idea best and learn or take parts from multiple apps.

Having prior understanding of how to program using HTML, CSS and JavaScript* is crucial to using Intel XDK. Intel XDK is primarily a tool for visualizing, debugging and building an app package for distribution.

You can do the following to access our demo apps:

  • Select Project tab
  • Select "Start a New Project"
  • Select "Samples and Demos"
  • Create a new project from a demo

If you have specific questions following that, please post it to our forums.

Q2: Can I use an external editor for development in Intel® XDK?

Yes, you can open your files and edit them in your favorite editor. However, note that you must use Brackets* to use the "Live Layout Editing" feature. Also, if you are using App Designer (the UI layout tool in Intel XDK) it will make many automatic changes to your index.html file, so it is best not to edit that file externally at the same time you have App Designer open.

Some popular editors among our users include:

  • Sublime Text* (Refer to this article for information on the Intel XDK plugin for Sublime Text*)
  • Notepad++* for a lighweight editor
  • Jetbrains* editors (Webstorm*)
  • Vim* the editor
Q3: How do I get code refactoring capability in Brackets*, the code editor in Intel® XDK?

You will have to add the "Rename JavaScript* Identifier" extension and "Quick Search" extension in Brackets* to achieve some sort of refactoring capability. You can find them in Extension Manager under File menu.

Q4: Why doesn’t my app show up in Google* play for tablets?

...to be written...

Q5: What is the global-settings.xdk file and how do I locate it?

global-settings.xdk contains information about all your projects in the Intel XDK, along with many of the settings related to panels under each tab (Emulate, Debug etc). For example, you can set the emulator to auto-refresh or no-auto-refresh. Modify this file at your own risk and always keep a backup of the original!

You can locate global-settings.xdk here:

  • Mac OS X*
    ~/Library/Application Support/XDK/global-settings.xdk
  • Microsoft Windows*
    %LocalAppData%\XDK
  • Linux*
    ~/.config/XDK/global-settings.xdk

If you are having trouble locating this file, you can search for it on your system using something like the following:

  • Windows:
    > cd /
    > dir /s global-settings.xdk
  • Mac and Linux:
    $ sudo find / -name global-settings.xdk
Q6: When do I use the intelxdk.js, xhr.js and cordova.js libraries?

The intelxdk and xhr libraries are only needed with legacy build tiles. The Cordova* library is needed for all. When building with Cordova* tiles, intelxdk and xhr libraries are ignored and so they can be omitted.

Q7: What is the process if I need a .keystore file?

Please send an email to html5tools@intel.com specifying the email address associated with your Intel XDK account in its contents.

Q8: How do I rename my project that is a duplicate of an existing project?

Make a copy of your existing project directory and delete the .xdk and .xdke files from them. Import it into Intel XDK using the ‘Import your HTML5 Code Base’ option and give it a new name to create a duplicate.

Q9: How do I try to recover when Intel XDK won't start or hangs?
  • If you are running Intel XDK on Windows* it must be Windows* 7 or higher. It will not run reliably on earlier versions.
  • Delete the "project-name.xdk" file from the project directory that Intel XDK is trying to open when it starts (it will try to open the project that was open during your last session), then try starting Intel XDK. You will have to "import" your project into Intel XDK again. Importing merely creates the "project-name.xdk" file in your project directory and adds that project to the "global-settings.xdk" file.
  • Rename the project directory Intel XDK is trying to open when it starts. Create a new project based on one of the demo apps. Test Intel XDK using that demo app. If everything works, restart Intel XDK and try it again. If it still works, rename your problem project folder back to its original name and open Intel XDK again (it should now open the sample project you previously opened). You may have to re-select your problem project (Intel XDK should have forgotten that project during the previous session).
  • Clear Intel XDK's program cache directories and files.
    On a [Windows*] machine this can be done using the following on a standard command prompt (administrator not required):
    > cd %AppData%\..\Local\XDK
    > del *.* /s/q
    To locate the "XDK cache" directory on [OS X*] and [Linux*] systems, do the following:
    $ sudo find / -name global-settings.xdk
    $ cd <dir found above>
    $ sudo rm -rf *
    You might want to save a copy of the "global-settings.xdk" file before you delete that cache directory and copy it back before you restart Intel XDK. Doing so will save you the effort of rebuilding your list of projects. Please refer to this question for information on how to locate the global-settings.xdk file.
  • If you save the "global-settings.xdk" file and restored it in the step above and you're still having hang troubles, try deleting the directories and files above, along with the "global-settings.xdk" file and try it again.
  • Do not store your project directories on a network share (Intel XDK currently has issues with network shares that have not yet been resolved). This includes folders shared between a Virtual machine (VM) guest and its host machine (for example, if you are running Windows* in a VM running on a Mac* host). This network share issue is a known issue with a fix request in place.

Please refer to this post for more details regarding troubles in a VM. It is possible to make this scenario work but it requires diligence and care on your part.

  • There have also been issues with running behind a corporate network proxy or firewall. To check them try running Intel XDK from your home network where, presumably, you have a simple NAT router and no proxy or firewall. If things work correctly there then your corporate firewall or proxy may be the source of the problem.
  • Issues with Intel XDK account logins can also cause Intel XDK to hang. To confirm that your login is working correctly, go to the Intel XDK App Center and confirm that you can login with your Intel XDK account. While you are there you might also try deleting the offending project(s) from the App Center.

If you can reliably reproduce the problem, please send us a copy of the "xdk.log" file that is stored in the same directory as the "global-settings.xdk" file to mailto:html5tools@intel.com.

Q10: Is Intel XDK an open source project? How can I contribute to the Intel XDK community?

No, It is not an open source project. However, it utilizes many open source components that are then assembled into Intel XDK. While you cannot contribute directly to the Intel XDK integration effort, you can contribute to the many open source components that make up Intel XDK.

The following open source components are the major elements that are being used by Intel XDK:

  • Node-Webkit
  • Chromium
  • Ripple* emulator
  • Brackets* editor
  • Weinre* remote debugger
  • Crosswalk*
  • Cordova*
  • App Framework*
Q11: How do I configure Intel XDK to use 9 patch png for Android* apps splash screen?

Intel XDK does support the use of 9 patch png for Android* apps splash screen. You can read up more at http://developer.android.com/tools/help/draw9patch.html on how to create a 9 patch png image. We also plan to incorporate them in some of our sample apps to illustrate their use.

Q12: How do I stop AVG from popping up the "General Behavioral Detection" window when Intel XDK is launched?

You can try adding nw.exe as the app that needs an exception in AVG.

Q13: What do I specify for "App ID" in Intel XDK under Build Settings?

Your app ID uniquely identifies your app. For example, it can be used to identify your app within Apple’s application services allowing you to use things like in-app purchasing and push notifications.

Here are some useful articles on how to create an App ID for your

iOS* App

Android* App

Windows* Phone 8 App

Q14: Is it possible to modify Android* Manifest through Intel XDK?

You cannot modify the AndroidManifest.xml file directly with our build system, as it only exists in the cloud. However, you may do so by creating a dummy plugin that only contains a plugin.xml file which can then be add to the AndroidManifest.xml file during the build process. In essence, you need to change the plugin.xml file of the locally cloned plugin to include directives that will make those modifications to the AndroidManifext.xml file. Here is an example of a plugin that does just that:

<?xml version="1.0" encoding="UTF-8"?><plugin xmlns="http://apache.org/cordova/ns/plugins/1.0" id="com.tricaud.webintent" version="1.0.0"><name>WebIntentTricaud</name><description>Ajout dans AndroidManifest.xml</description><license>MIT</license><keywords>android, WebIntent, Intent, Activity</keywords><engines><engine name="cordova" version=">=3.0.0" /></engines><!-- android --><platform name="android"><config-file target="AndroidManifest.xml" parent="/manifest/application"><activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" android:label="@string/app_name" android:launchMode="singleTop" android:name="testa" android:theme="@android:style/Theme.Black.NoTitleBar"><intent-filter><action android:name="android.intent.action.SEND" /><category android:name="android.intent.category.DEFAULT" /><data android:mimeType="*/*" /></intent-filter></activity></config-file></platform></plugin>

You can check the AndroidManifest.xml created in the apk, using the apktool with the command line:  

aapt l -M appli.apk >text.txt  

This adds the list of files of the apk and details of the AndroidManifest.xml to text.txt.

Q15: How can I share my Intel XDK app build?

You can send a link to your project via an email invite from your project settings page. However, a login to your account is required to access the file behind the link. Alternatively, you can download the build from the build page, onto your workstation, and push that built image to some location from which you can send a link to that image. 

Q16: Why does my iOS build fail when I am able to test it successfully on a device and the emulator?

Common reasons include:

  • Your App ID specified in the project settings do not match the one you specified in Apple's developer portal.
  • The provisioning profile does not match the cert you uploaded. Double check with Apple's developer site that you are using the correct and current distribution cert and that the provisioning profile is still active. Download the provisioning profile again and add it to your project to confirm.
  • In Project Build Settings, your App Name is invalid. It should be modified to include only alpha, space and numbers.
Q17: How do I add multiple domains in Domain Access? 

Here is the primary doc source for that feature.

If you need to insert multiple domain references, then you will need to add the extra references in the intelxdk.config.additions.xml file. This StackOverflow entry provides a basic idea and you can see the intelxdk.config.*.xml files that are automatically generated with each build for the <access origin="xxx" /> line that is generated based on what you provide in the "Domain Access" field of the "Build Settings" panel on the Project Tab. 

Q18: How do I build more than one app using the same Apple developer account?

On Apple developer, create a distribution certificate using the "iOS* Certificate Signing Request" key downloaded from Intel XDK Build tab only for the first app. For subsequent apps, reuse the same certificate and import this certificate into the Build tab like you usually would.

Q19: How do I include search and spotlight icons as part of my app?

Please refer to this article in the Intel XDK documentation. Create an intelxdk.config.additions.xml file in your top level directory (same location as the other intelxdk.*.config.xml files) and add the following lines for supporting icons in Settings and other areas in iOS*.

<!-- Spotlight Icon --><icon platform="ios" src="res/ios/icon-40.png" width="40" height="40" /><icon platform="ios" src="res/ios/icon-40@2x.png" width="80" height="80" /><icon platform="ios" src="res/ios/icon-40@3x.png" width="120" height="120" /><!-- iPhone Spotlight and Settings Icon --><icon platform="ios" src="res/ios/icon-small.png" width="29" height="29" /><icon platform="ios" src="res/ios/icon-small@2x.png" width="58" height="58" /><icon platform="ios" src="res/ios/icon-small@3x.png" width="87" height="87" /><!-- iPad Spotlight and Settings Icon --><icon platform="ios" src="res/ios/icon-50.png" width="50" height="50" /><icon platform="ios" src="res/ios/icon-50@2x.png" width="100" height="100" />

For more information related to these configurations, visit http://cordova.apache.org/docs/en/3.5.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens.

For accurate information related to iOS icon sizes, visit https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html

NOTE: The iPhone 6 icons will only be available if iOS* 7 or 8 is the target.

Cordova iOS* 8 support JIRA tracker: https://issues.apache.org/jira/browse/CB-7043

Q20: Does Intel XDK support Modbus TCP communication?

No, since Modbus is a specialized protocol, you need to write either some JavaScript* or native code (in the form of a plugin) to handle the Modbus transactions and protocol.

Q21: How do I sign an Android* app using an existing keystore?

Uploading an existing keystore in Intel XDK is not currently supported but you can send an email to html5tools@intel.com with this request. We can assist you there.

Q22: How do I build separately for different Android* versions?

Under the Projects Panel, you can select the Target Android* version under the Build Settings collapsible panel. You can change this value and build your application multiple times to create numerous versions of your application that are targeted for multiple versions of Android*.

Q23: How do I display the 'Build App Now' button if my display language is not English?

If your display language is not English and the 'Build App Now' button is proving to be troublesome, you may change your display language to English which can be downloaded by a Windows* update. Once you have installed the English language, proceed to Control Panel > Clock, Language and Region > Region and Language > Change Display Language.

Q24: How do I update my Intel XDK version?

When an Intel XDK update is available, an Update Version dialog box lets you download the update. After the download completes, a similar dialog lets you install it. If you did not download or install an update when prompted (or on older versions), click the package icon next to the orange (?) icon in the upper-right to download or install the update. The installation removes the previous Intel XDK version.

Q25: How do I import my existing HTML5 app into the Intel XDK?

If your project contains an Intel XDK project file (<project-name>.xdk) you should use the "Open an Intel XDK Project" option located at the bottom of the Projects List on the Projects tab (lower left of the screen, round green "eject" icon, on the Projects tab). This would be the case if you copied an existing Intel XDK project from another system or used a tool that exported a complete Intel XDK project.

If your project does not contain an Intel XDK project file (<project-name>.xdk) you must "import" your code into a new Intel XDK project. To import your project, use the "Start a New Project" option located at the bottom of the Projects List on the Projects tab (lower left of the screen, round blue "plus" icon, on the Projects tab). This will open the "Samples, Demos and Templates" page, which includes an option to "Import Your HTML5 Code Base." Point to the root directory of your project. The Intel XDK will attempt to locate a file named index.html in your project and will set the "Source Directory" on the Projects tab to point to the directory that contains this file.

If your imported project did not contain an index.html file, your project may be unstable. In that case, it is best to delete the imported project from the Intel XDK Projects tab ("x" icon in the upper right corner of the screen), rename your "root" or "main" html file to index.html and import the project again. Several components in the Intel XDK depend on this assumption that the main HTML file in your project is named index.hmtl. See Introducing Intel® XDK Development Tools for more details.

It is highly recommended that your "source directory" be located as a sub-directory inside your "project directory." This insures that non-source files are not included as part of your build package when building your application. If the "source directory" and "project directory" are the same it results in longer upload times to the build server and unnecessarily large application executable files returned by the build system. See the following images for the recommended project file layout.

Q26: I am unable to login to App Preview with my Intel XDK password.

On some devices you may have trouble entering your Intel XDK login password directly on the device in the App Preview login screen. In particular, sometimes you may have trouble with the first one or two letters getting lost when entering your password.

Try the following if you are having such difficulties:

  • Reset your password, using the Intel XDK, to something short and simple.

  • Confirm that this new short and simple password works with the XDK (logout and login to the Intel XDK).

  • Confirm that this new password works with the Intel Developer Zone login.

  • Make sure you have the most recent version of Intel App Preview installed on your devices. Go to the store on each device to confirm you have the most recent copy of App Preview installed.

  • Try logging into Intel App Preview on each device with this short and simple password. Check the "show password" box so you can see your password as you type it.

If the above works, it confirms that you can log into your Intel XDK account from App Preview (because App Preview and the Intel XDK go to the same place to authenticate your login). When the above works, you can go back to the Intel XDK and reset your password to something else, if you do not like the short and simple password you used for the test.

Q27: How do I completely uninstall the Intel XDK from my system?

See the instructions in this forum post: https://software.intel.com/en-us/forums/topic/542074. Then download and install the latest version from http://xdk.intel.com.

Q28: Is there a tool that can help me highlight syntax issues in Intel XDK?

Yes, you can use the various linting tools that can be added to the Brackets editor to review any syntax issues in your HTML, CSS and JS files. Go to the "File > Extension Manager..." menu item and add the following extensions: JSHint, CSSLint, HTMLHint, XLint for Intel XDK. Then, review your source files by monitoring the small yellow triangle at the bottom of the edit window (a green check mark indicates no issues).

Q29: How do I manage my Apps in Development?

You can manage them by logging into: https://appcenter.html5tools-software.intel.com/csd/controlpanel.aspx. This functionality will eventually be available within Intel XDK after which access to app center will be removed.

Q30: I need help with the App Security API plugin; where do I find it?

Visit the primary documentation book for the App Security API and see this forum post for some additional details.

Q31: When I install my app onto my test device Avast antivirus flags it as a possible virus, why?

If you are receiving a "Suspicious file detected - APK:CloudRep [Susp]" message it is likely due to the fact that you are side-loading the app onto your device (using a download link or by using adb) or you have downloaded your app from an "untrusted" store. See the following official explanation from Avast:

Your application was flagged by our cloud reputation system. "Cloud rep" is a new feature of Avast Mobile Security, which flags apks when the following conditions are met:
  1. The file is not prevalent enough; meaning not enough users of Avast Mobile Security have installed your APK.
  2. The source is not an established market (Google Play is an example of an established market).
If you distribute your app using Google Play (or any other trusted market) your users should not see any warning from Avast.
Q32: How do I add a Brackets extension to the editor that is part of the Intel XDK?

The number of Brackets extensions that are provided in the built-in edition of the Brackets editor are limited to insure stability of the Intel XDK product. Not all extensions are compatible with the edition of Brackets that is embedded within the Intel XDK. Adding incompatible extensions can cause the Intel XDK to quit working.

Despite this warning, there are useful extensions that have not been included in the editor and which can be added to the Intel XDK. Adding them is temporary, each time you update the Intel XDK (or if you reinstall the Intel XDK) you will have to "re-add" your Brackets extension. To add a Brackets extension, use the following procedure:

  • exit the Intel XDK
  • download a ZIP file of the extension you wish to add
  • on Windows, unzip the extension here: %LocalAppData%\Intel\XDK\xdk\brackets\b\extensions\dev
  • on Mac OS X, unzip the extension here: /Applications/Intel\ XDK.app/Contents/Resources/app.nw/brackets/b/extensions/dev
  • start the Intel XDK

Note that the locations given above are subject to change with new releases of the Intel XDK.

Q33: Why does my app or game require so many permissions on Android when built with the Intel XDK?

When you build your HTML5 app using the Intel XDK for Android or Android-Crosswalk you are creating a Cordova app. It may seem like you're not building a Cordova app, but you are. In order to package your app so it can be distributed via an Android store and installed on an Android device, it needs to be built as a hybrid app. The Intel XDK uses Cordova to create that hybrid app.

A pure Cordova app requires the NETWORK permission, it's needed to "jump" between your HTML5 environment and the native Android environment. Additional permissions will be added by any Cordova plugins you include with your application; which permissions are includes are a function of what that plugin does and requires.

Crosswalk for Android builds also require the NETWORK permission, because the Crosswalk image built by the Intel XDK includes support for Cordova. In addition, current versions of Crosswalk (12 and 14 at the time this FAQ was written)also require NETWORK STATE and WIFI STATE. There is an extra permission in some versions of Crosswalk (WRITE EXTERNAL STORAGE) that is only needed by the shared model library of Crosswalk, we have asked the Crosswalk project to remove this permission in a future Crosswalk version.

If you are seeing more than the following five permissions in your XDK-built Crosswalk app:

  • android.permission.INTERNET
  • android.permission.ACCESS_NETWORK_STATE
  • android.permission.ACCESS_WIFI_STATE
  • android.permission.INTERNET
  • android.permission.WRITE_EXTERNAL_STORAGE

then you are seeing permissions that have been added by some plugins. Each plugin is different, so there is no hard rule of thumb. The two "default" core Cordova plugins that are added by the Intel XDK blank templates (device and splash screen) do not require any Android permissions.

BTW: the permission list above comes from a Crosswalk 14 build. Crosswalk 12 builds do not included the last permission; it was added when the Crosswalk project introduced the shared model library option, which started with Crosswalk 13 (the Intel XDK does not support 13 builds).

Back to FAQs Main

Viewing all 554 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>