crosswalk-project / deprecated-crosswalk-apk-generator Goto Github PK

Since Promises are supported in Crosswalk natively, make use of them in examples, rather than using callbacks.

When validating the environment, the Finder currently looks for files and fails if they aren't found. However, what the Finder looked for and where it looked for it isn't shown; neither is a decent explanation of what was found (e.g. if the Finder failed because multiple candidate files were found, or if it failed because no candidate was found).

This needs some improvement, to make it easier for users to debug when things go wrong.

Now that we've removed logging almost altogether, we need to come up with a replacement for it (it's too quiet now).

Suggest we have a logger which can toggle between more than two levels of verbosity (was: "lots" or "a ridiculous amount", see #38), so we can cover at least the following (in increasing order of verbosity):

1. User can see that the build is still continuing (e.g. spinner).
2. User can see which step the build is at (e.g. "step 1 of 7").
3. User can see what's happening at the current step and which files are being affected (e.g. "building Java resource file X from directory Y").
4. User can see the commands which are being run (e.g. "running command XXX took N seconds".

We might want to combine or ignore some of these (e.g. do 1, ignore 2, do 3+4).

Architecturally, it might make sense to have a central hub we can publish events to; then add listeners to the hub which log the events (to the console, a file etc.).

We currently require that the androidAPIVersion is specified, and default to '19.0.0'. However, this default is no good if the user doesn't have the tools for that Android SDK version installed.

Perhaps, we could instead infer the most-recent Android API version the user has, and use that. Though we might want to put a lower bound on which versions are acceptable.

While building the web apps, one problem I have to keep dealing with is to select the 'final' apk from the 3 that are generated in outDir - usually I do 'ls -1 build/*.apk | grep -v signed'.

I find it would be preferable to put all the working files in different place, perhaps to be determined but a --temp arg?

hai all,

My question is,There is any possible way to add the cordova plugin in crosswalk https://crosswalk-project.org/documentation/getting_started/run_on_android.html using python script.

Add support for generating an apk from a Crosswalk manifest via a --manifest option

Issue by DonnaWuDongxia from Tuesday Jan 07, 2014 at 11:09 GMT

Path to the libs are changing between different versions of xwalk, for example:

crosswalk-2.31.27.5-x86/xwalk_app_template/native_libs/libs/x86/libxwalkcore.so
crosswalk-4.32.64.0-x86/xwalk_app_template/native_libs/x86/libs/x86/libxwalkcore.so

crosswalk-4.32.64.0-x86/xwalk_app_template/libs/xwalk_app_runtime_java.jar
crosswalk-2.31.27.5-x86/xwalk_app_template/libs/xwalk_app_runtime_client_java.jar

But xwalk-apk-generator tries to find these libs in some hard-coded path. Then errors are throw when we use unmatched xwalk.

Can an explanation be added to the readme? I'm curious as this seems like the more natural existence for xwalk v python.

I'm getting by fine with other options, but... curious. =]

xwalk_android_dl --channel canary doesn't download the latest canary, I assume because of the change in the download folders. I used crosswalk-apk-generator 0.0.13 from NPM.

Issue by townxelliot from Monday Jan 13, 2014 at 14:05 GMT

See http://developer.android.com/guide/topics/manifest/manifest-element.html for the list.

It should be possible for these to be set for the app, to enable a developer to version their Crosswalk application on the Play store (versionCode is particularly important) or otherwise customise its behaviour.

Alternatively, allow a developer to set their own manifest template location via an app config option.

Environment

• OS: Mac OSX
• Node.js: 0.10.26
• crosswalk-apk-generator: from npm 0.0.15
• crosswalk template: 6.35.131.7
• JDK: 1.7
• Android SDK platforms installed: 19
• Phone Android: 4.4.2

Steps

• CLI

xwalk_apkgen -a <android-sdk> -x <xwalk-dir> --app-url <some-url> --name MyApp --pkg com.my.name --version 0.1 --arch arm

• The package can be correctly generated in build/MyApp.arm.apk
• When installed and launched on my phone, the app crashes without any useful message

Python scripts with same parameters can generate correct apk for my phone.

It seems there are several java versions and it's not clear which one the developer needs to install.

Note that I don't seem to have the Java JDK installed, even though I've been successfully(?) generating apks for a while...I do have both /opt/java/64/jre1.7.0_25/ and /usr/lib/jvm/java-7-oracle/, and I'm not sure if these suffice[0]. I suppose it is the need to set $JAVA_HOME that has me looking into this, since I don't have that set in my environment.

So, it leaves me a bit confused. I recognise that setting up java is not really in the scope, but still....

Max.

[0] welcome.html files suggests it is JavaTM Standard Edition Runtime Environment

I am trying to build and run a webrtc application using crosswalk apk generatore
I am able to build it but when I try to run it on the device, it fails to detect that the shared library is installed. Am I doing something wrong or failing to specify an option?
I did install via adb on the device "adb install /build/crosswalk-5.32.90.0-arm/apks/XWalkRuntimeLib.apk" before installing and running the built shared apk.

content of the json file build_orcafeb.json
{
"version": "2.0.0",
"permissions": ["ACCESS_NETWORK_STATE", "INTERNET", "ACCESS_WIFI_STATE", "CHANGE_WIFI_STATE", "CHANGE_NETWORK_STATE", "WRITE_EXTERNAL_STORAGE", "CAMERA", "WAKE_LOCK", "RECORD_AUDIO", "MODIFY_AUDIO_SETTINGS", "VIBRATE", "RECEIVE_BOOT_COMPLETED", "WRITE_SETTINGS", "DISABLE_KEYGUARD", "READ_CONTACTS", "WRITE_CONTACTS", "READ_PHONE_STATE", "PROCESS_OUTGOING_CALLS", "CALL_PHONE", "RAISED_THREAD_PRIORITY", "SYSTEM_ALERT_WINDOW"]
}

rm -rf orcafeb;mkdir -p orcafeb
bin/xwalk_apkgen --androidSDKDir /Users/username/android-sdk-macosx
--xwalkAndroidDir build/crosswalk-5.32.90.0-arm/xwalk_app_template
--appRoot projects/orcafeb
--appLocalPath index.html
--name "OrcaFeb"
--package "com.alu.orcafeb"
--nativeLibs "build/crosswalk-5.32.90.0-arm/xwalk_app_template/native_libs/armeabi-v7a/libs/armeabi-v7a/libxwalkcore.so"
--enable-remote-debugging
--arch arm
--mode shared
--icon projects/icon.png
--outDir orcafeb
--app-config build_orcafeb.json

If however I give the following options, the apk compiles fine and works fine but it is using the less desirable embedded mode

rm -rf orcafeb;mkdir -p orcafeb
bin/xwalk_apkgen --androidSDKDir /Users/anand/android-sdk-macosx
--xwalkAndroidDir build/crosswalk-5.32.90.0-arm/xwalk_app_template
--appRoot projects/orcafeb
--appLocalPath index.html
--name "OrcaFeb"
--package "com.alu.orcafeb"
--nativeLibs ""
--enable-remote-debugging
--arch arm
--mode embedded
--icon projects/icon.png
--outDir orcafeb
--app-config build_orcafeb.json

Issue by townxelliot from Wednesday Jan 22, 2014 at 10:07 GMT

The current make_apk.py script has a --manifest option which lets you use a manifest to configure the options for the output apk.

xwalk-apk-generator has this partially, but the following would need to be investigated:

• We use a different format to set the icons for an App instance (we use the Android *dpi values as keys, rather than pixel sizes, as is done in the Crosswalk manifest).

The simplest approach would probably be to use the Crosswalk pixel sizes as keys ("96", "128" etc.), then map those into the correct dpi output apk's res/drawable-* directories.

• We'd need to see what make_apk.py does with manifest.json once it's processed: is it just included in the apk file, or do its values need to be used to set options in the manifest etc.? My guess is the latter (only app.launch.local_path is supported, for example, so presumably that's being used to set --app-local-path).

• install crosswalk-apk-generator with npm
• download current crosswalk release with xwalk_android_dl
• build web app with xwalk_apk_gen and all mandatory parameters in command line

The error below is produced.

xwalk_apkgen --appRoot . --appLocalPath index.html --name Three --package com.balenet.three --androidSDKDir ~/devel/adt-bundle-mac-x86_64-20131030/sdk/ --xwalkAndroidDir crosswalk-4.32.76.5-x86 --version 1.0

*** STARTING BUILD

*** CHECKING ENVIRONMENT...

*** APPLICATION:
{ name: 'Three',
sanitisedName: 'Three',
pkg: 'com.balenet.three',
icon: '',
fullscreen: true,
theme: 'Theme.Holo.Light.NoActionBar.Fullscreen',
permissions:
[ 'ACCESS_FINE_LOCATION',
'ACCESS_NETWORK_STATE',
'CAMERA',
'INTERNET',
'MODIFY_AUDIO_SETTINGS',
'RECORD_AUDIO',
'WAKE_LOCK',
'WRITE_EXTERNAL_STORAGE' ],
appUrl: null,
appRoot: '.',
appLocalPath: 'index.html',
remoteDebugging: false,
jars: [],
javaSrcDirs: [],
extensions: null,
version: 1,
orientation: null }

*** ENVIRONMENT:
{ java: 'java',
javac: 'javac',
ant: 'ant',
jarsigner: 'jarsigner',
sourceJavaVersion: '1.5',
targetJavaVersion: '1.5',
arch: null,
androidSDKDir: '/Users/baleboy/devel/adt-bundle-mac-x86_64-20131030/sdk/',
androidAPILevel: 19,
dx: '/Users/baleboy/devel/adt-bundle-mac-x86_64-20131030/sdk/build-tools/android-4.4/dx',
aapt: '/Users/baleboy/devel/adt-bundle-mac-x86_64-20131030/sdk/build-tools/android-4.4/aapt',
anttasksJar: '/Users/baleboy/devel/adt-bundle-mac-x86_64-20131030/sdk/tools/lib/ant-tasks.jar',
androidJar: '/Users/baleboy/devel/adt-bundle-mac-x86_64-20131030/sdk/platforms/android-19/android.jar',
zipalign: '/Users/baleboy/devel/adt-bundle-mac-x86_64-20131030/sdk/tools/zipalign',
xwalkAndroidDir: 'crosswalk-4.32.76.5-x86',
xwalkRuntimeClientJar: 'crosswalk-4.32.76.5-x86/xwalk_app_template/libs/xwalk_app_runtime_java.jar',
xwalkApkPackageAntFile: 'crosswalk-4.32.76.5-x86/xwalk_app_template/scripts/ant/apk-package.xml',
xwalkAssets: null,
xwalkEmbeddedJar: null,
xwalkCoreResources:
{ resDirs: [ 'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/xwalk_core_java/res_grit/' ],
libs: [ 'crosswalk-4.32.76.5-x86/xwalk_app_template/libs_res/runtime/' ],
pkg: 'org.xwalk.core' },
chromiumContentResources:
{ resDirs:
[ 'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/content_java/res_crunched/',
'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/content_java/res_v14_compatibility/',
'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/content_java/res_grit/' ],
libs: [ 'crosswalk-4.32.76.5-x86/xwalk_app_template/libs_res/content/' ],
pkg: 'org.chromium.content' },
chromiumUiResources:
{ resDirs:
[ 'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/ui_java/res_crunched/',
'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/ui_java/res_v14_compatibility/',
'crosswalk-4.32.76.5-x86/xwalk_app_template/gen/ui_java/res_grit/' ],
libs: [ 'crosswalk-4.32.76.5-x86/xwalk_app_template/libs_res/ui/' ],
pkg: 'org.chromium.ui' },
nativeLibs: null,
keystore: 'crosswalk-4.32.76.5-x86/xwalk_app_template/scripts/ant/xwalk-debug.keystore',
keystoreAlias: 'xwalkdebugkey',
keystorePassword: 'xwalkdebug' }

*** LOCATIONS:
{ destDir: '/Users/baleboy/src/threejs/build',
buildJars: [],
jars: [],
assets: [],
resources: {},
nativeLibs: [],
classesDir: '/Users/baleboy/src/threejs/build/classes',
dexFile: '/Users/baleboy/src/threejs/build/classes.dex',
resPackageApk: '/Users/baleboy/src/threejs/build/Three.ap_',
unsignedApk: '/Users/baleboy/src/threejs/build/Three-unsigned.apk',
signedApk: '/Users/baleboy/src/threejs/build/Three-signed.apk',
finalApk: '/Users/baleboy/src/threejs/build/Three.apk',
resDir: '/Users/baleboy/src/threejs/build/res',
assetsDir: '/Users/baleboy/src/threejs/build/assets',
extensionsJsDir: '/Users/baleboy/src/threejs/build/assets/3351e4f0-1395564934779-1xwalk-extensions',
extensionsConfig: '/Users/baleboy/src/threejs/build/assets/extensions-config.json',
srcDir: '/Users/baleboy/src/threejs/build/src',
javaPackageDir: '/Users/baleboy/src/threejs/build/src/com/balenet/three',
androidManifest: '/Users/baleboy/src/threejs/build/AndroidManifest.xml',
defaultDrawableDir: '/Users/baleboy/src/threejs/build/res/drawable',
drawableDirs:
{ xhdpi: '/Users/baleboy/src/threejs/build/res/drawable-xhdpi',
hdpi: '/Users/baleboy/src/threejs/build/res/drawable-hdpi',
mdpi: '/Users/baleboy/src/threejs/build/res/drawable-mdpi',
ldpi: '/Users/baleboy/src/threejs/build/res/drawable-ldpi' } }

*** BUILDING APPLICATION IN /Users/baleboy/src/threejs/build
shell.js: internal error
Error: ENAMETOOLONG, name too long '/Users/baleboy/src/threejs/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets/build/assets'
at Object.fs.mkdirSync (fs.js:642:18)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:57:8)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)
at cpdirSyncRecursive (/usr/local/lib/node_modules/crosswalk-apk-generator/node_modules/shelljs/src/cp.js:72:7)

The current output is typically like the following :

>>>>>>> Generating R.java file with aapt
>>>>>>> Generating R.java file with aapt
>>>>>>> Generating R.java file with aapt
>>>>>>> Generating R.java file with aapt
>>>>>>> Compiling classes with javac
>>>>>>> Making intermediate apk for resources in /home/davidmaxwaterman/z/webapps/webapps-mancala/build/Mancala.arm.ap_
>>>>>>> Compiling .class files with dx to generate .dex file in /home/davidmaxwaterman/z/webapps/webapps-mancala/build/classes.dex
>>>>>>> Creating unsigned apk in /home/davidmaxwaterman/z/webapps/webapps-mancala/build/Mancala-unsigned.arm.apk
>>>>>>> Creating signed apk /home/davidmaxwaterman/z/webapps/webapps-mancala/build/Mancala-signed.arm.apk
>>>>>>> Aligning apk file /home/davidmaxwaterman/z/webapps/webapps-mancala/build/Mancala.arm.apk
* DONE
    output apk path is /home/davidmaxwaterman/z/webapps/webapps-mancala/build/Mancala.arm.apk

I realise such statements are perhaps meaningful for someone developing or debugging the generator, but in general use I think they are almost meaningless. Their only utility, imo, is that they show progress. I'd almost prefer no output until 'DONE', and perhaps a generic '|-/' spinner or '%' to show progress. I guess it would make sense if the output was in the form of steps that the user would have to take if they were doing this manually, and phrased as such, even so far as saying 'step 1 of 7: ...' - that'd almost be educational :)
Anyway, it'd be nice to hide any output behind a 'debug', 'verbose', or 'quiet' property.
To satisfy the need for debugging, I kind of liked npm's behaviour where it dumps a log file. Having said that, npm does output some redundant info to stdout/err that tempts the user to not look in the dump file - I'd prefer to simply say - "Something's gone wrong. Please see crosswalk-apk-generator.log."
Anyway, those are my thoughts...not sure about existing logging libraries that can do this sort of thing.

Issue by townxelliot from Monday Feb 03, 2014 at 10:50 GMT

The --query option should show all channels with all versions for each channel/arch if no channel and/or arch is specified.

It seems that the FetchJs doesn't support proxies :

https://github.com/andris9/fetch/issues/6

I guess it'll be quite a bit of work to fix this.

Issue by townxelliot from Tuesday Jan 28, 2014 at 15:02 GMT

As per crosswalk-project/crosswalk@27892bf

If the outDir is set to be inside the appRoot, a nasty recursive copying error can occur.

We should have a check which ensures that the outDir is not a subdirectory of appRoot.

Issue by townxelliot from Tuesday Jan 28, 2014 at 15:01 GMT

While developing the grunt task, I noticed that VersionsFetcher was giving quite a cryptic error message when I asked it to download a version that didn't exist. Specifically, it was an arm stable release, and there aren't any (at the time of writing).
I had a look at improving how it fails, but I couldn't quite figure out the promises. This is so this issue isn't forgotten.

The App/Env split seems to get more and more arbitrary as we go along, and there's not really any need for it. Suggest we replace it with a BuildConfig object instead, which combines all the properties from both in one place.

(We could consider moving the xwalkPieces and androidPieces into separate objects with if the BuildConfig object gets too massive.)

Also suggest that we fix the relationships between Env/App and other components:

• Remove Env object from the BuildTools constructor (nasty sort-of circular dependency anyway).
• Remove AppSkeleton object from the Env constructor.
• Move the Env.build() method to a Builder object, which orchestrates between BuildTools and AppSkeleton.
• Pass a BuildConfig to the Builder.build() method.

This makes BuildConfig entirely declarative. It also gets rid of some incestuous object relations (e.g. BuildTools is created by Env, but needs Env passed to its constructor). It potentially also makes the Builder reusable (it doesn't have a BuildConfig as part of its state, but has that passed to its build() method).

At the moment, if there's a runtime error, the failed download file is left in place. We should attempt to clean this up.

eg :

$ xwalk_android_dl -a arm |& ts
Mar 20 13:30:27 fetching xwalk-android using parameters:
Mar 20 13:30:27   architecture = arm
Mar 20 13:30:27   channel = beta
Mar 20 13:30:27   version = 4.32.76.5
Mar 20 13:30:27   url = https://download.01.org/crosswalk/releases/android-arm/beta/crosswalk-4.32.76.5-arm.zip
Mar 20 13:30:27 starting download of https://download.01.org/crosswalk/releases/android-arm/beta/crosswalk-4.32.76.5-arm.zip
Mar 20 13:30:28 
Mar 20 13:30:28 /home/davidmaxwaterman/z/crosswalk-apk-generator/node_modules/q/q.js:126
Mar 20 13:30:28                     throw e;
Mar 20 13:30:28                           ^
Mar 20 13:30:28 TypeError: Object #<Socket> has no method 'clearLine'
Mar 20 13:30:28     at ConsoleLogger.replace (/home/davidmaxwaterman/z/crosswalk-apk-generator/src/console-logger.js:58:18)
Mar 20 13:30:28     at /home/davidmaxwaterman/z/crosswalk-apk-generator/src/archive-fetcher.js:88:19
Mar 20 13:30:28     at _progressed (/home/davidmaxwaterman/z/crosswalk-apk-generator/node_modules/q/q.js:817:51)
Mar 20 13:30:28     at /home/davidmaxwaterman/z/crosswalk-apk-generator/node_modules/q/q.js:843:24
Mar 20 13:30:28     at /home/davidmaxwaterman/z/crosswalk-apk-generator/node_modules/q/q.js:612:17
Mar 20 13:30:28     at flush (/home/davidmaxwaterman/z/crosswalk-apk-generator/node_modules/q/q.js:108:17)
Mar 20 13:30:28     at process._tickCallback (node.js:415:13)

I'm guessing this is the progress output...perhaps it doesn't make sense when output is directed through a pipe? Note that my real usage is that xwalk_android_dl is part of a script, and I was redirecting the output of the whole script through ts so I could see how long each part takes.

Perhaps it could do with a 'quiet' option?

Issue by townxelliot from Tuesday Jan 28, 2014 at 15:02 GMT

As per crosswalk-project/crosswalk@2176efc

Issue by townxelliot from Tuesday Jan 28, 2014 at 15:01 GMT

Issue by townxelliot from Wednesday Jan 22, 2014 at 09:55 GMT

At the moment, the xwalk_apkgen tool is tailored to a particular Crosswalk Android version (currently: 4.*). This means that it breaks if you try to use it with a different version. (This is because, by design, we try to be selective for the sake of speed, and don't scan for files or include all the .jar or .so files in xwalk_app_template; but this makes the tool brittle if the structure of xwalk_app_template changes.)

There are three ways we could cope with this:

1. Release different versions of the tool for different Crosswalk Android versions, and make it fail noisily if an unsupported version is used. This is the quick but dirty approach.
2. Modify the tool to support different Crosswalk Android versions. This would need some kind of map adding to Env.configure() so we can find the right components from Crosswalk Android, depending on the version being used. This would need more coding, but be more flexible and cleaner.
3. Scan for files rather than try to selectively locate them. This is the current make_apk.py approach. This would be slower and more flexible, but could introduce errors (e.g. if there are files in the xwalk_app_template which should not be in the apk file).

hi

I'm trying to use crosswalk to create simple application for android , I used all Crosswalk instruction to create it , in the section "Building a Crosswalk application " after python make_apk.py I get an error:

There doesn't exist aapt in C:\Development\adt-bundle-windows-x86_64-20140702\sdk.
There doesn't exist aapt.com in C:\Development\adt-bundle-windows-x86_6-20140702\sdk.

Use aapt.exe in C:\Development\adt-bundle-windows-x86_6-20140702\sdk.

I try to move aapt.exe in different folder with no success.

my configurazione on Windows 7:
Android:
[ ] Tools
[x] Android SDK Platform-tools 20
[x] Android SDK Build tools 18.0.1
[ ] Android 4.3 (API 18)
[x] SDK Platform

thanks

Issue by DonnaWuDongxia from Tuesday Jan 07, 2014 at 11:09 GMT

Path to the libs are changing between different versions of xwalk, for example:

crosswalk-2.31.27.5-x86/xwalk_app_template/native_libs/libs/x86/libxwalkcore.so
crosswalk-4.32.64.0-x86/xwalk_app_template/native_libs/x86/libs/x86/libxwalkcore.so

crosswalk-4.32.64.0-x86/xwalk_app_template/libs/xwalk_app_runtime_java.jar
crosswalk-2.31.27.5-x86/xwalk_app_template/libs/xwalk_app_runtime_client_java.jar

But xwalk-apk-generator tries to find these libs in some hard-coded path. Then errors are throw when we use unmatched xwalk.

After installing crosswalk-apk-generator with npm, the "xwalk_apkgen" command example here:

https://www.npmjs.org/package/crosswalk-apk-generator

fails because the 'version' field is missing though it seems to be mandatory. It would be better if it were optional (as in make_apk)

xwalk_apkgen --androidSDKDir
--xwalkAndroidDir
--appRoot
--appLocalPath

If a download fails (e.g. you asked for a file which doesn't exist), the download file is still produced (albeit empty or unusable) and no error reported.

If the initial HTTP request fails, the output file should be removed and the error reported.

Issue by DonnaWuDongxia from Tuesday Jan 07, 2014 at 11:17 GMT

When I finally get all the environments correct. compile error encounterred:

Error: command
javac -g -d /home/donna/work/wrt/xwalk-apk-generator/build/classes -source 1.5 -target 1.5 -Xlint:unchecked -Xlint:deprecation -classpath /home/donna/adt-bundle/sdk/platforms/android-17/android.jar:/home/donna/Downloads/crosswalk-2.31.27.5-x86/xwalk_app_template/libs/xwalk_app_runtime_client_java.jar /home/donna/work/wrt/xwalk-apk-generator/build/src/me/myname/myapp/My_appActivity.java /home/donna/work/wrt/xwalk-apk-generator/build/src/me/myname/myapp/R.java /home/donna/work/wrt/xwalk-apk-generator/build/src/org/chromium/content/R.java /home/donna/work/wrt/xwalk-apk-generator/build/src/org/chromium/ui/R.java /home/donna/work/wrt/xwalk-apk-generator/build/src/org/xwalk/core/R.java
returned bad code 1
Error output was:
warning: [options] bootstrap class path not set in conjunction with -source 1.5
/home/donna/work/wrt/xwalk-apk-generator/build/src/me/myname/myapp/My_appActivity.java:10: error: package org.xwalk.app does not exist
import org.xwalk.app.XWalkRuntimeActivityBase;
^
/home/donna/work/wrt/xwalk-apk-generator/build/src/me/myname/myapp/My_appActivity.java:12: error: cannot find symbol
public class My_appActivity extends XWalkRuntimeActivityBase {
^
symbol: class XWalkRuntimeActivityBase
/home/donna/work/wrt/xwalk-apk-generator/build/src/me/myname/myapp/My_appActivity.java:16: error: cannot find symbol
super.onCreate(savedInstanceState);
^
symbol: variable super
location: class My_appActivity

Issue by townxelliot from Tuesday Jan 28, 2014 at 15:02 GMT

These would help filter out noise from dependent objects etc. which are currently shown on the console; we only want to see the properties which are being set by the scripts.

The name of the jar file for embedded mode changed from:

xwalk_core_embedded.dex.jar

to

xwalk_runtime_embedded.dex.jar

This prevents embedded mode packaging from working. This needs to be fixed in Env, when looking for Android "pieces".

However, we can't just change the name of the jar file we're looking for, as this will prevent crosswalk-apk-generator from working with version 4 of Crosswalk Android. So we should probably shelve this until we get a chance to look at multi-version support (#5) again.

I noticed that I now have to specify an architecture. That seems right for building an apk, but I also have to specify it for the downloader and that doesn't seem quite right, so I thought I'd question it here.

The directory structure has changed, and the template downloads now include both architectures.

Issue by townxelliot from Tuesday Jan 28, 2014 at 15:03 GMT

(to wrap a Crosswalk app around a remote website)

My web app needs to access the internet and when I used the generator to build the app and run it, it reported Access-Control-Allow-Origin error. It seems it could get around by
setAllowUniversalAccessFromFileURLs(true). Don't know whether there is a configuration param to allow cross-domain access?
The following ticket seemed to disable the Cross-Origin request by default. How can I enable that?
crosswalk-project/crosswalk#791

Issue by townxelliot from Monday Feb 03, 2014 at 20:50 GMT

See around https://github.com/crosswalk-project/crosswalk/blob/master/app/tools/android/make_apk.py#L167 (MakeVersionCode function).

And see http://software.intel.com/en-us/blogs/2012/11/12/how-to-publish-your-apps-on-google-play-for-x86-based-android-devices-using for why it's important.

The output apk filename always includes the architecture string ("x86" or "arm") even when building a shared mode apk. It shouldn't.

Suggest we just have APP.apk for architecture-independent apks.

Ref:

https://www.npmjs.org/package/crosswalk-apk-generator

The text :

the pre-requisites required to build an Android package

links to :

null:null#pre-requisites

which gives an error (on FF at least).