Possible?
I think to do this I need to upgrade the AIR runtime on the Fire to 3, but the version in the app store won't install. I can't create an AIR apk that is both captive runtime and debug that I know of, so the debug version of the app has to run on the AIR runtime installed. Since the Fire comes with 2.7, 3.x apps won't run in debug mode.
Has anyone managed to get AIR 3 running on a Fire without using captive runtime?
To update AIR on your KF you have to get root privileges. Also keep in mind that android build on KF doesn't have any copy command (it cut off). So the best way I found is to flash your KF with modified (pre-rooted) stock version and then install new air.
Get pre-rooted stock version (I took it here). IMPORTANT: it installs via TWRP, google how to install TWRP on KF.
Put downloaded .zip and air_runtime.apk (latest AIR version) in the root of KF.
Reboot in Recovery mode (TWRP should load)
Flash this version.
On your PC open cmd and run "adb shell" (make sure you see your device in list when run "adb devices" otherwise check drivers).
Run "su" (if you downloaded secure version).
In shell go to sdcard ("ls" to get list of files/folders and "cd folder_name" to get into) and run "install air_runtime.apk /system/app/air_runtime.apk" (I think you can just run "install /sdcard/folder_with_air/air_runtime.apk /system/app/air_runtime.apk").
(7a. If it tells you that can't install because of file already exist, run the following two commands: "mount -o remount rw /system" (mount 'system' with read/write rights) and "mv /system/app/air_runtime.apk /system/app/air_runtime.bak" (rename air_runtime.apk into air_runtime.bak). Then repeat step 7.)
In KF just run (install) air_runtime.apk (use any file explorer, e.g. download ES File Explorer from Amazon).
Check AIR version in Applications.
That's all. Looks a bit complex, but in real it takes about 4-5 mins for me to update AIR (BUT I have TWRP already installed).
Hope it helps.
UPD. After your Kindle updates itself (version 6.3.1 currently the latest) you'll lose you SU privileges. AIR also will be rolled back to 2.7. You can prevent KF auto-updates (search on xda how to do it) or flash actual pre-rooted version (it gives you several months without problems).
Related
I have installed NetBSD 6.1.5 with full installation setting. However, when I run startx it says no screens could be found. So i tried "X -configure" and then "X -config ~/xconfig.conf.new" and I was brought to a very generic screen with a black x crosshair, but I was unable to exit this using the suggested ctrl+alt+backspace, so I had to force power off and check if my keyboard was recognized in the conf file generated, which it was. I have installed xdm, xterm, Xorg, and other X programs.
I am not familiar with setting up desktop environments from scratch. I am a newb who is used to Ubuntu esque installers doing that stuff for me.
Would someone be able to walk me though the installation or point me to a link which explains a step by step process?
What happens if you rename your xorg.conf.new to /etc/X11/xorg.conf? Does startx or xdm work then?
Are you running this inside a VirtualBox or other emulator?
I have NetBSD on a Thinkpad T420 which I occasionally boot into Windows, and I've setup VirtualBox to be able to run the same NetBSD install when I'm in Windows. The key difference in the xorg.conf file is in the Device section:
Section "Device"
Driver "vesa"
EndSection
Also I've found the free version of http://mobaxterm.mobatek.net/ very handy - I use it to ssh into the virtual NetBSD box and then run X apps and have them display on the Windows desktop.
Final note - you might want to look out for the NetBSD-7 RC1 which should be out 'Real Soon Now', as there are some very handy improvements, including better support for most modern display hardware :)
I found that running startx from any directory with a .xinitrc file gives strange behavior in amd64 6.1.5 and 6.1.4. Delete (or rename) any .xinitrc files and try
xinit /path/to/windowmanager
Please read Chapter 9 of NetBSD Guide:
http://www.netbsd.org/docs/guide/en/chap-x.html
Section 9.9 discusses installing various Desktop Managers/Environments.
It turns out that I could run "X -config xorg.conf.new" as root on host and then ssh using putty to manually launch windows.
http://zzsethzz.blogspot.de/2013/02/install-chromium-upgrade-it-to-chrome.html
According this tutorial, I should remove all HDDs I do not want to install chromium OS to during install. I wanted to try this guide on my imac using an external SSD for chromeos. Obviously, removing the HDD isn't an option. Will the chromiumOS installer format my mac drive too, if I don't remove it?
AS the writer of that tutorial I can hopefully help you. When you install Chromium OS to begin with you can specify where to install to if you know your unix commands well enough. and then from there you can update to Chrome OS once you have your external working for you.
To find out what your hard drive is when connected, open a terminal (you may need to use a developer terminal) and use the command "fdisk -l" This will list your hard drives. for example /dev/sda1 etc...
Your install command would be "Install /Dev/sda1" but replace the dev part with whatever your hard drive was listed as. If you need further help email me at admin#xiaorishu.co.uk
Every time I open GitHub for Mac it asks me to "add a new helper tool" and prompts me for my password. Every time I enter my password (I am an admin on this computer) but I see no noticeable changes afterwards and the prompt comes back every time I reopen GitHub. (See attached photo for the prompt window.)
I am running OSX Yosemite Version 10.10 on a Late 2012 Mac Mini (2.5 GHz Intel Core i5).
Unsure if this is related but I am running GitHub version "Reactive Barbecue (186)". According to the GitHub for Mac release notes this is NOT the newest version, but when I select "Check for updates" it says I have the latest version. Would a fresh install of GitHub solve this? This is more of a nuisance and doesn't noticeably impede my work.
I use GitHub daily for XCode pushes with my coworkers. They all use MacBook Airs and OSX Yosemite but do not have the same issue as me.
I was also having this problem.
Cause? Maybe GitHub.app was confused by multiple git installations: XCode's Command Line Tools and Homebrew's copy (a newer version and includes bash completion).
Running the shell command git credential-osxkeychain returned a "usage" line, so a helper was installed despite that message.
Fix: Downloading and running GitHub Desktop successfully installed its helper. I think GitHub Desktop.app is the new name for GitHub.app, so apparently they fixed the bug by now.
BTW: They wrote "If you're using GitHub for Mac or Windows, the upgrade is automatic.", but their automatic upgrade didn't fix this problem nor switch to "GitHub Desktop.app".
The only solution I found so far was to delete the GitHub for Mac application. Then I re-downloaded the app (the most recent version 193 "Big Feels").
It then gave me a popup saying I needed to uninstall the old version since OSX now comes with Git commands by default (or something like that?). Clicking "Uninstall now" made the app crash so I had to select "Uninstall later". This is sort of only a fix for the symptom since GitHub could keep telling me to uninstall every time I open it, but at least it says I have the most recent version now.
Use AppCleaner and nuke it. Reinstall.
I seem to be having issues with integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.
With xcode 6 running remotely via SSH the simulator time-out, when I run locally it succeeds.
Command
xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform=iOS Simulator,name=iPhone 5s' -derivedDataPath ./Build clean test
2014-08-19 10:46:36.591 xcodebuild[33966:381f] iPhoneSimulator: Timed out waiting 120 seconds for >simulator to boot, current state is 1.
Testing failed:
Test target BGO_Tests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1
Tested with recent Xcode 6 beta 6
Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).
Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:
xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."
Prelaunching
I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:
# First get the UDID you need
xcrun instruments -s
# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>
# and wait some time....
sleep 5
# Then launch your unit tests
xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>'
Old post
This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.
Apple follow up regarding Bug ID# 18001199:
The context provided by LaunchDaemons is not supported for running GUI
applications. The SSH service, and the default setup for Jenkins, are
both implemented as LaunchDaemons. In earlier versions of Xcode 5
xcodebuild could run tests on the iOS simulator in this context, but
that was never a supported configuration, and as you have noted that
is no longer working as of Xcode 6.
Unlike LaunchDaemons, LaunchAgents provide a context where you can run
GUI applications - if the user is logged in at the time, with a window
server / Aqua session. Converting your Jenkins configuration from
being a LaunchDaemon to being a LaunchAgent would avoid the reported
issue. You can also use launchd for running tests on the iOS simulator
from a SSH session, either by crafting a LaunchAgent and manually
loading / starting that, or by using "launchctl submit”.
Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.
As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.
If connecting with JNLP still does not solve it, try the solution mentioned in this comment.
i.e.: Run these on command line:
DevToolsSecurity -enable
sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"
security authorizationdb write system.privilege.taskport is-developer
See References here and here.
I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.
I ended up solving this on Xcode 5 by doing the steps here, essentially running:
sudo security authorizationdb write system.privilege.taskport allow
This will eliminate one class of these authentication popups. You’ll also need to run:
sudo DevToolsSecurity -enable
However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.
I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.
I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.
Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.
I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.
That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.
I finally managed to find a good simple solution. JNLP was causing numerous issues with our jenkins server.
Workaround for SSH timeout via https://corner.squareup.com/2015/07/ios-build-infrastructure.html
"Mavericks (10.9) and Yosemite (10.10) determine if a process can access accessibility hooks via the parentage of the accessing process. By putting launchd in the list of allowed processes, processes launched via SSH or Jenkins have access to the accessibility hooks across the system. To do this you can modify the TCC database, per this gist. A reboot is required to make the change take effect."
#!/bin/bash
# This will add lauchd to the list of allowed processes for accessibility access
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)"
# This outputs the rows in the TCC database
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'
echo "Restart is required for these changes to take effect"
Update 8/02/2016
This is now fixed in Xcode 7.2.1 ("Command line tool ‘xcodebuild test’ will no longer time out waiting for Simulator.app to launch")
I've seen this error before, one possibility is that since you probably downloaded the Xcode6 Beta from the internet (not the appstore as its not available yet), the machine you are trying to run it on will show a pop up asking you if you really want to open this app as its from the internet.
The same will happen when xcodebuild tries to launch the iPhone simulator app.
One thing you might want to try is to share screen with the machine and click "Open" in that pop up.
If that still doesn't work, I would try to:
Reset the Content & Settings of the simulator
Reboot the machine and make sure no simulator is running on start up (you can just choose not to re-open any app when restarting)
I am trying to run up an app in release mode on my Nokia N8. When it builds the phones asks me if i want to install it. i press yes and install it to the mass memory. This happens with out a hitch. Then it asks me to install Qjson.sis i choose the same mass memory drive and then it starts to install. This is when i get a message that reads "Update Error"
this happens when i install it to both the mass memory and the system memory. Any suggestions? im running win7 with the latest qt creator. The N8 is running PR1.0 not the newer PR1.1
The most likely answer is that the QJSON executable (.dll) is already installed on the device, but under a different package and/or UID.
Best way to get around this is to re-build QJSON with a different UID, and ensure the new UID is appended to the executable name (e.g. qjson_0x20030000.dll). In this way you can avoid update errors.