I'm prepping an application for submission to the Windows Store that utilises the Bing Maps API - as such, the app has to be compiled to target specific architectures. Whilst there is a guide to submission, it's not clear how to submit both Arm and x86 configurations of the same app. Is it even possible, or will there have to be in the store twice?
When you select the option to create your app package from the Visual Studio Store menu, you get a choice to select the package architecture. There are 4 options: Neutral, x86, x64, ARM.
If you select Neutral, then it builds a single package for "Any CPU" that you can upload to the Store. If you select x86, x64 and ARM, it will build a package for each of these configurations, and you will have to upload the corresponding packages for the architectures you wish to support.
Additionally, if you're building to submit to the Store, make sure to always select Release for each of the selected architectures.
There are cases where some references don't support building using a Neutral architecture. The Microsoft Visual C++ Runtime Package is an example.
Taken from here:
The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details
of the various runtimes and compilers.
JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are
platform neutral, and you can write once to run on x86/x64/ARM.
C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro
style apps using C# or Visual Basic can be compiled once to run on
x86/x64/ARM.
C++ is close to the metal, and compiled to the machine language for
the platform that you’re targeting. This offers developers full
control, but also requires that they specify the hardware where the
app will be supported.
The essence of it is that pure .net or pure html/js will run on any architecture without problems. If you want C++ then you will need to compile your app once for each supported architecture. My understanding is that you can create an app package which contains installers for multiple architectures in this case.
The post here has some good details on packaging your app for multiple architectures. Here are a few highlights:
7.In the Select the packages to create and the solution configuration mappings section, select the check box for each build configuration
for which you want to create a package.
The build configurations grid lists the possible platform
architectures of the package (that is, Neutral, ARM, x64, and x86). In
each row, a combo box displays the combination of the current Solution
Configuration and Architecture choices that are relevant for that
row’s architecture. The check box for the default platform is set to
the current, active project platform. The combo box for the Neutral
row show the Solution Configuration combinations that contain AnyCPU
as the project’s platform. If no Solution Configuration combination is
relevant, the entire row for that platform is unavailable for
selection. One package is produced for each configuration that you
specify.
8.For each build configuration that you specified, choose the Solution Configuration that you want to build.
When you package an app for the Store, you can specify Release or any
custom solution configuration that you’ve created.
A package will be created for each build configuration that you
specified.
From here we get this:
7.Click Packages to upload your app's packages.
And finally from the previous link:
Signing and publishing
After your app passes the certification testing, its packages are
digitally signed to protect them against tampering after they have
been released. When this phase begins, you cannot cancel your
submission.
Note It might take some time for your app's listing to appear in
search results. This is normal. Also, you can't change a release date
after you submit the app to the Windows Store, but you can cancel the
release, update the release date, and re-submit.
Overview: During the build process you specify all architectures you want your app to work for and it creates a package for each. During the submission process you select all the packages you built for that app. When submitting you app this way only one version will show up in the store.
If you build just a HTML5/javascript Windows Store app, it work on all version (ARM, x86 and x84)
If you create something web with bing api. No worry about what platform doesn't work.
Answer is here: http://developer.android.com/google/play/publishing/multiple-apks.html
TLDR:
Go to your Google Play app developer console
Choose your app
Select APK on the left
Turn on Advanced Mode
Upload your ARM apk
Upload your x86 apk
Google will figure out the rest
Related
(Using C++) How would software developers make a profitable program to distribute? Would they used pre-compiled binaries within the project directory or something? Just learning wxWidgets and I want to make an application to put on a website.
#pizzadog,
The answer depends on the target platform.
If you are on Windows, you create a binary and use a special software to create a distribution.
If you are on *nix - the answer depends whether you want to allow the end-user to compile the software. If you do - you put the link to the source on the site and create a documentation on how to build it. If you don't - you create a special rules file depending on the *nix distribution you are targeting.
If you are on Mac - you put the application bundle for download and clearly state what is the minimal OSX version the program will run.
HTH.
i have a separate build-flow that can produce .out files for the MT3620/M4 core using the same gcc-arm compiler.... for reasons beyond the scope of this question, it's not practical for me to migrate this build-flow into cmake....
once i generate the .out file, my thinking was to simply envelop it within a project structure identical to the samples -- with an conforming app_manifest.json file.... from here, i could effectively run just the final step of the cmake build -- which generates the image package....
before i go down this path, is there anything obvious i'm missing here????
As of today you will need to decide to install Azure Sphere SDK Preview for Visual Studio or Azure Sphere SDK Preview for Windows (You cannot install both SDKs on the same PC.)
To develop applications, however, you need to set up your development environment and possibly install additional tools. The Azure Sphere SDK for Windows supports development with the CLI only. If you've installed this version of the SDK, you'll need to install CMake and Ninja on your PC.
If you plan to develop real-time capable applications (RTApps), you might need to install a compiler for the embedded processor and set up hardware to display output from the app.
Both Quickstarts "Build an RTapp on cmd" and "Build an RTApp with Visual Studio" require that you use CMake at some stage and those are the supported methods.
Update: New documentation improvements will be done soon to address the option of using a different build system to cmake and "yes" it should work as you suggest.
I recently finished an application based on Titanium, Javascript, HTML, CSS. I have only been a web designer to date so I have little experience in distributing applications. I was accustomed to the TiDev Community deploying app, which prepared the app for download and made it available for download at a given link.
But tidev community is no longer supported, so I use TideSDK Developer to package the app, which doesnt do all the hard work the other one did so nicely.
I am obviously a complete rookie to this.
Could anyone outline the steps I would need to take to go from the bundled application folder I have now (put together by TideSDK Developer), to a link that will allow customers to download and install the app or online? I know there is an issue with packaoging the app for platforms other than your own, and that appcelerator is working on a solution to this I think. I also realise I would probably have to pay to host the download online. Any guidance would be greatly appreciated.
You must use the tidebuilder.py script. to compile a installation package. To compile a binary for a Mac, you must run the script on a Mac, to compile a binary for windows, you must be on a windows box etc.
There is some documentation on how to use it here per platform. The command is very simple and works.
Once you have your application file (DMG for OSX or a MSI for Windows) then just distribute it however you see fit, email, putting it on your web server, whatever works for you.
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.
Our C++/QT desktop application for Mac, Windows and Linux needs an installer. I'd rather we have a single installer for all three platforms. I do know it's a bit tricky, I guess what I wanted ask is if a framework already exists for that (Java maybe?).
I'd really like to avoid having to write three different installers.
The link that Kyle mentions is pretty comprehensive, but I wanted to provide a bit more of information about InstallBuilder for Qt (Disclaimer, I am one of the developers) since most of the cross platform installation programs referenced there are Java-based. This requires bundling a JRE, etc. and adds a significant overhead that is not required with a Qt-based installer, like ours. It is able to generate wizard-like executable installers for all platforms from a single project file as well as native packages such as DEB and RPM. If you ship your software in DVDs, you can create a single multi-platform DVD that shares data across platforms but still have native launchers.
Having said this, since your application is Desktop-oriented, for the particular case of OS X if it does not require complex installation you may be better off creating a .app file and package it inside a DMG. Users can then drag the file directly to the Applications folder.
Finally, I wanted to mention that InstallBuilder is commercial, but we offer free licenses for open source projects and discounts for small development firms.
IzPack rocks: http://izpack.org. It is truly crossplatform, very lightweight, easy to master, and produces excellent results.
After fully integrating both Izpack and InstallBuilder into our builds (using Windows, OSX, and Ubuntu 14 build servers for testing purposes), I will say I believe InstallBuilder is well worth the money (and free for open source projects according to wojciechka).
Izpack is a bit slow, a bit large if you need to package a JVM, and has an amateurish user interface. Version 5 (release candidate 3) was also not generating uninstallers properly. That said, as long as you use a 4.x version and require a JVM anyway, it may be enough for your needs. The extension interface is not terribly easy to deal with, but is almost infinitely flexible. The Windows installers do not register with the Control Panel uninstaller list.
InstallBuilder has a great, fast UI in the produced installers and has a serviceable UI for creating installers. The XML is pretty easy to deal with, too. Downloads are about as small as possible. It also includes nice hooks for doing all sorts of custom stuff easily. The only slightly annoying thing I ran into was that the Windows server required that I manually add some configuration to set executable bits on the other systems' packages (other systems didn't require this configuration).
Note: I was using the three-platform version of standard InstallBuilder (not InstallBuilder for QT).