Package Details: archon 2.1.0-9

Git Clone URL: (read-only)
Package Base: archon
Description: Execute Android APKs
Upstream URL:
Licenses: custom, Apache
Submitter: prurigro
Maintainer: syncrtl64
Last Packager: syncrtl64
Votes: 38
Popularity: 0.003048
First Submitted: 2014-09-26 11:25
Last Updated: 2016-07-03 13:13

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

prurigro commented on 2015-01-11 12:09

Updates in 1.2-6:
* Version 2.0.0 is now selected for x86_64 (other archs are still at v1.2)
* A new prepare() function has been added to increase application font size by 1.2 times (the default font size is too small when run on my configuration, though let me know if this isn't the same for everyone and I'll look at other options)
* The ARChon folder is now installed to the /opt directory as per
* The /usr/bin/archon script has been cleaned up and improved a bit, as well as updated to reflect the new ARChon location in /opt
* Support for arm and armv6h has been dropped after reading that the v1.2-ARM branch is built to support Chromebooks (armv7h)
* The license files in /usr/share/licenses/archon are now symbolic links rather than copies

If anyone knows of a better way than the hack I've used to provide v1.2 for armv7h+i686 and v2.0.0 for x86_64, I'd be interested in hearing what that would be :)

PedroHLC commented on 2015-01-11 11:44

@prurigro: I haven't yet be able to use archon, it only shows me an android splash screen and closes it self in any apk I use.
I believe this package should just build and install the archon as a chromium extension as described in ; while yours installer/manager app ( should be moved to another package - that's how ArchLinux packages generally works.
Also, is chromeos-apk really a archon dependency, or only from your manager??

prurigro commented on 2015-01-11 08:32

@ricardomv: Hmm, I haven't had to do that myself (just tested with the latest chromeos-apk and both -a and --archon seem to do the same thing)- How come you needed to change the flag? (Is whatever it fixes more subtle than simply being the difference between working and not?)

prurigro commented on 2015-01-11 08:27

@PedroHLC: I ended up getting busy after we talked last, and then had a bit of trouble deciding on the best direction to do things once time was a bit more free again. I figured I'd start by updating and cleaning up the current logic, then play around a bit to see where to go from there... One thing I've been finding is that a lot of applications haven't been saving their settings, and I'm not sure if that's because of how things are configured or because of an issue upstream with archon (I'm running into this with the 2.0 version for x86_64 only too)- have you run into this and/or found a solution to the issue?

ricardomv commented on 2014-12-31 08:16

had to edit /bin/archon to get it working changed line :17 "chromeos-apk --archon ..." to "chromeos-apk -a ..."

PedroHLC commented on 2014-12-30 13:03

Still waiting (your github project || at least a gist)...

prurigro commented on 2014-12-15 02:06

@Allister.Hood: can you test this latest update, which no longer attempts to strip anything? I'm not sure why the i686 repo has x86_64 nacl in it on that note...

Alister.Hood commented on 2014-12-08 14:55

Something isn't quite right, because it spits out a bunch of messages like this on i686:
strip:./usr/share/archon/_platform_specific/nacl_x86_64/ File format not recognized

prurigro commented on 2014-10-29 00:35

Another improvement I'd like to make but haven't found a solution for yet is to find a way for the font to be configured, or at least resized. I'd be interested if you have any ideas as to how that might be done.

I might make this info a github project btw, so ideas and issues can be better tracked, instructions can be more clear than they currently are, and to open tbe doors to collaboration.

prurigro commented on 2014-10-29 00:28

I like the sound of most of those suggestions. Doing something more along the lines of an installation would definitely feel less like a toy than it does in its current state, and it would mean the installer could manually generate proper .desktop files with the apk's icon file and the correct path too, not to mention that it wouldn't need to worry about keeping track of app versions, since installing again could just replace the current one (since this wouldn't be happening regularly). I couldn't figure out what was creating the generated .desktop files btw, which is why I'd added that hack that removes them in the script, assuming it was likely chromium which would be a huge pain to patch, but of you know them to be originating from chrome-apk, or of a flag that can be passed to chromium to skip that step, I'd be happy to have a proper fix :) Let me take a look at all this when I get home. Cheers for the kindred interest!