search

crosswalk-project / DEPRECATED-crosswalk-apk-generator

A generator for Crosswalk Android application packages. NOTE: This project is not being actively maintained. You will have better luck using the crosswalk-app-tools (https://github.com/crosswalk-project/crosswalk-app-tools).
Apache License 2.0
16 stars 12 forks source link

Support Crosswalk manifest.json #6

Open townxelliot opened 10 years ago

townxelliot commented 10 years ago

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:

kenchris commented 10 years ago

Just use what is here: http://w3c.github.io/manifest/ :)

Custom stuff can be prefixed with xwalk_ for now

townxelliot commented 10 years ago

My preference would be to support a --manifest option, but remove any other options where they overlap with what's in manifest.json as per @kenchris' link.

For instance, the orientation of the app is currently set via an --orientation option to the CLI tool, which in turn sets an orientation property in AndroidManifest.xml; while manifest.json can have a default_orientation field with the same purpose.

I don't want to support --orientation as well as allow a default_orientation property in manifest.json - it's going to be a mess, and they are potentially going to conflict with each other.

So I suggest we just support manifest.json, and remove "hacks" for properties which are in the "official" Crosswalk manifest.json file.

This would at least mean removing:

We would probably need to retain --app-url however.

This would force a user to build from manifest.json, not from an HTML file. Though it also means that if Crosswalk doesn't support a manifest property properly, stuff won't work in the generated apk. So we may want to agree which version of the spec we are supporting when.

I would resist putting any xwalk-specific fields in manifest.json, and instead continuing to rely on a build config JSON file and/or environment variables and/or command line options to support the extra properties we need. Most of these are irrelevant to an application manifest anyway: for example, where the Android SDK is, which architecture we're building for, which Android API level to target, where Java source for extensions is.

baleboy commented 10 years ago

LGTM. I'm not sure how, but make_apk manages to work without setting the Android SDK path, so it would be nice if the same could be achieved here.

kenchris commented 10 years ago

Sounds good to me

@baleboy what is up with the sun glasses? I heard it is snowing in .FI

baleboy commented 10 years ago

@kenchris you gotta believe

townxelliot commented 10 years ago

@baleboy make_apk.py tracks up from the android binary to figure out where the main SDK directory is.

However, bear in mind that crosswalk-apk-generator is intended to be bare bones, and is best thought of as a library. Which doesn't mean that we can't add auto-detection to tools layered on top of it. It's just that auto-detection can sometimes be a bit magical and difficult to debug if it goes wrong, so I prefer to make explicit which resources we're using at this level.

grunt-crosswalk (the real end-user tool) is probably a better place for auto-detecting the Android SDK (though in that case you still have to remember to add android to your path).

Having said that, we do auto-detect which Android platform versions a user has in crosswalk-apk-generator, as this was causing endless problems, so I begrudgingly let the magic in for that.

baleboy commented 10 years ago

@townxelliot ok, thanks for the explanation

townxelliot commented 10 years ago

@kenchris is the whole of the manifest spec supported in Crosswalk 4? or just in 5?

davidmaxwaterman commented 10 years ago

grunt-crosswalk (the real end-user tool) is probably a better place for auto-detecting the Android SDK (though in that case you still have to remember to add android to your path).

Yes, it does this.

kenchris commented 10 years ago

@townxelliot it depends as the manifest spec changed a bit and what the current spec supports is not fully aligned (but that doesn't matter if we move to use your tool :-)). Examples are the starturl and icons.

Permissions (not in the spec) and csp (being added to the spec by @anssiko as we speak) are in CW4 and later.

We probably want to add a xwalk_permissions until that part gets standardized (will happen in another spec for packaged apps and work on that is not started yet)

townxelliot commented 10 years ago

I think we should definitely support the new manifest spec, but as far as my experiments have demonstrated, most of the elements in the spec linked to above don't actually work yet:

So we would still need to translate the manifest properties into a working Android manifest. Is that what we're suggesting here? I was assuming I could build an app and include manifest.json, then I wouldn't have to set properties in AndroidManifest.xml for orientation, fullscreen etc. or set app.launch.local_path in manifest.json. But it looks like I will still have to do that anyway.

Doing a translation could be problematic for properties which can have multiple values in the manifest spec but only one property in AndroidManifest.xml (e.g. orientation and display). Orientation can probably be handled easily enough (regex "portrait" or "landscape"), but I'm not sure how we'd translate the allowable display modes values except for "fullscreen".

I'd probably also have to generate my own Crosswalk-compatible manifest.json from any user-specified standards-compliant manifest.json, otherwise the manifest which ended up in the app would lack the useful working properties (app.launch.localpath for instance). Those properties would have to be prefixed with 'xwalk' in the standards-based manifest, then translated to "real" working properties in the Crosswalk-compatible manifest which went into the app.

townxelliot commented 10 years ago

Considering a bit more, I think I'll implement support for a manifest.json, but will only expect it to have the properties which are currently supported by Crosswalk. Any custom properties will just be specified on the command line as they are already.

Once a fuller standardised manifest is supported by Crosswalk, I can "switch off" the AndroidManifest.xml customisations to support orientation and fullscreen.

kenchris commented 10 years ago

The things is not that we don't support the things, but that they are supported with slighly different syntax (like different name). Like the "start_url": "..." is currently supported as "app": { "launch": { "locak_path": "..." } }

Yes, this should all be fixed but we just havent gotten around to it. I would suggest that you implement using the syntax as defined by the spec.

baleboy commented 10 years ago

I think the tool should work with the exact same manifest as make_apk. If fixes are needed, they should be applied to both places. Otherwise we are going to end up with two different manifests for different tools.

kenchris commented 10 years ago

Yes, we should fix make_apk as well. But it does not make sense to implement the make_apk manifest now in this tool as we know it will be changed. If you want let's discuss this on irc.

townxelliot commented 10 years ago

manifest.json is a Crosswalk-specific manifest, not a manifest specific to make_apk.py. It doesn't make sense to use a manifest.json file with the new format, as Crosswalk (in its current state) will mostly ignore it, as none of its properties are supported.

As far as crosswalk-apk-generator goes, the only field relevant from the manifest currently supported by Crosswalk is "name" (which is also shared by the new format manifest anyway).

So what I'm suggesting is that the current mechanisms for setting the Android manifest properties (orientation, fullscreen) are retained for now This means we just keep the command-line options for --orientation and --fulscreen in the apk generator. And we just copy manifest.json into the apk (so we don't care what's in it, apart from the name).

Once the Crosswalk manifest matches the new manifest spec,, we can dispense with the apk generator properties which set values for orientation and fullscreen in AndroidManifest.xml, as we won't need them any more. (Crosswalk will manage its own display and orientation and won't need Android to do it).

I don't want anyone to be distracted by the fact that I mention an app.config.json file, which is just unfortunately named for historical reasons. Really, this is a build configuration file, not a manifest, and is never distributed with the application. It's just a convenient way to set up some stuff so we can make an apk. My intention is to merge App and Env so you have a "BuildConfig" object. Once it's called that, hopefully it will be clear that it has little to do with the App, and everything to do with how it is packaged into an apk file.

I probably will change how icon works, hopefully so it looks more like the new manifest format. Though mapping from the new manifest to Android resource directories probably won't be natural or obvious.