I edit the system app(homescreen) in the gaia folder,
and flash the device,
but it doesn't work, not thing change at all.
I've already try it on the simulator,
it runs as well.
Could somebody tell me how to make the changes apply to the real device ?
thanks.
So there is two ways you can do it. If all you want is change the homescreen, you can now create a homescreen app and set it as the homescreen in Settings (push via the app manager like any app). There is a nice example here.
If you want to flash the gaia homescreen to your phone, there is a couple of things you need to do:
Update the phone to the correct version (nightly if you're editing master, 1.4 if you're editing upstream/v1.4 branch). This is because gaia & gecko version are tightly coupled.
Enable Remote debugging in Settings
Verify that you can talk to the phone via the app manager
In the terminal, run adb root and adb remount to make sure you have to right permissions (this is probably where it goes wrong)
In the gaia directory run: make reset-gaia
This should flash all of gaia now. If you continue editing you can make incremental changes to homescreen and push them via:
APP=homescreen make install-gaia && adb shell stop b2g && adb shell start b2g
If this doesn't work, please write the output of make reset-gaia to a log file and add it as a comment to your question.
Related
An article on Chrome OS that I read here:
https://medium.com/#JamesCridland/review-five-months-with-a-chromebook-for-web-development-writing-and-more-8adf36b4a061
says:
"Update: Above, I mention that I use SSH and vi to do my programming work. And I did. Except I don’t any more. It turns out that one of the newer updates added direct SFTP access into the Files app (the equivalent of Explorer or Finder), so that my development box appears simply as another drive on my Chromebook. And Caret is an excellent programmer’s editor. So now I have a proper programmer’s editor (as well as the SSH terminal I need to put those changes live)."
Ok. But, when I go into Chrome OS's files app, the apparent way 'mount' my equiv of his
'development box' is via 'add new services', which is launching a webstore-app named 'SFTP' (whose icon is a blue folder outline with "SFTP" on it). i,e.:
https://chrome.google.com/webstore/detail/sftp-file-system/gbheifiifcfekkamhepkeogobihicgmn?hl=en
(My equiv of his 'development box' I'm assuming to be my web-server at bluehost.com, where I currently use Firefox's FireFTP extension, on Win-10.)
I can't get this 3-stars webstore 'SFTP' app (authored by someone from Japan) to authenticate me into my bluehost acc't. So, now I'm wondering whether
this 'SFTP' app is even the right thing to have installed, due to all the one- and two-star showstopper reviews. One typical review by a guy named Tim says:
"It's a nice try, but I really wish someone who knows what they're doing would make this service. It looks like it works but if you drill down more than a few folders deep on the remote filesystem, operations slow to a crawl."
Similarly, the two clients ('sFTP client' and 'sFTP client Lite) also have such low ratings, that my gut says that Google has failed to deliver a robust web-developer infrastructure.
Come on Google...you need to implement this stuff under your own logo.
Am I missing something???
Probably should advertise this functionality better :), but the Secure Shell App supports mounting via SFTP so it will appear in the Files app.
Steps to use:
Install Secure Shell Chrome extension.
Launch the extension (look for it in the bar to the right of the omnibox/browser URL bar -- it'll have a black terminal icon).
Enter the connection details to create a new profile.
Give it a description like "user#foo.com".
Instead of clicking "Connect" in the bottom right, click "Mount".
Authenticate with the server (keys/pass/whatever).
Once it finishes, it'll now be visible in the Files app.
If you suspend/resume the system or otherwise logout/reboot, you'll need to relaunch Secure Shell, select the saved profile, and then click "Mount" again. We probably should make this a bit smoother, but that's how it works currently.
No, not an answer yet...just more wishlist stuff:
Ok, more recent info about the Firefox browser's "FireFTP" addon:
It no longer works on the (new) std Firefox browser, as of a couple of
weeks ago when version 57.0 was released. (No biggie tho...a goggle revealed
a new-to-me browser called 'Waterfox' and it nicely supports FireFTP and the
other addons that Firefox dropped support for.)
So a bit more research yielded only yet more 'mumble-mode' confusion: it revealed that FireFTP is open source...located here:
https://github.com/mimecuvalo/fireftp
(So I submitted a new 'issue' there and asked about porting it to Chrome.)
I'm desperate, and recently test-drove Google's new Pixelbook.
(Sigh...nothing inspirational came of that...I give it one-thumb-down rating.
Here's my notes from that experience:
------------ Review notes of Pixelbook: ----------------------
Google didn’t think to include a USB-C to USB-A adapter. (A $2 item. e.g.)
https://www.amazon.com/Remax-USB3-1-Female-Adapter-Silver/dp/B01MCSRSKN/
That was my 'showstopper'...like a few other reviewers said...it's not well
thought out / matured. To me it feels more like a gimmick, than a product.
At a minimum, it rates my newest hashtag: #NRFPT (not ready for prime time).
I found no obvious way to disable the touchpad, when using a mouse.
In fact, no other reviewers expressed interest in using a mouse. (???)
Lastly, my favorite kind of Android apps are 'widgets', and I see no signs
that it has occurred to Google to allow Chrome-OS's desktop/background to
host any widgets.
Ok, I'm still in mumble-mode...and still in search of a FTP/SFTP GUI client for
the Chrome browser / Chrome-OS that is the quality of FireFTP.
Enable Linux(beta) on your chromebook. Then you can do whatever you want like on others linux machine.
A simple sftp connection command
sftp [user#]host
Enable linux and mount with sshfs
sudo apt install sshfs
then
sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 user#xxx.xxx.xxx.xxx:/remotedir localdir
or with key auth
sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,IdentityFile=~/.ssh/id_rsa user#xxx.xxx.xxx.xxx:/remotedir localdir
These will reconnect after resuming from sleep
I have my work computer which is a Windows 10 Pro and my laptop is a Windows 10 Home. Working on the same project on both: push and pull to Git. Learning React through Udemy. Both computers using Chrome. Both using Bash on Ubuntu on Windows with latest updates. Both using ConEmu for the console. Both npm -v = 3.10.10. Both node -v = 6.11.2. Hardware is different obviously, but not sure that is relevant and worth listing.
Anyway, this starter project I am playing around with, when I make changes to it and npm start is running, you can see activity in the console, hit refresh in the browser, and any changes made will be reflected.
On the laptop, this process does not work. Make change, save, no activity in console, refresh in browser does not reflect the changes. Have to restart npm start for changes to be reflected. A little irritating to say the least.
Anyway idea what might cause this? Really haven't come across anything in my Googling efforts.
If you are using npm in WSL2.0 for development, please refer the last point in this-
https://create-react-app.dev/docs/troubleshooting/#npm-start-doesnt-detect-changes
While WSL1.0 doesn't use a VM, WSL2.0 does use a lightweight VM, so adding
CHOKIDAR_USEPOLLING=true
in a .env file in the project directory fixed the problem.
On a sidenote, you might wanna take a look at this
Client side
To ensure client side changes aren't being cached, you can open devtools > Network, and check "Disable cache". After enabling this, you won't have anything in the cache as long as devtools is open.
Alternatively, you can use incognito / private browsing mode to prevent the cache from holding on to things.
Server side
I'm sure you've realized that it's a pain to restart your server every time you want to see your code update. There are several tools that will detect file changes and handle restarting the server automatically.
PM2
Nodemon
Forever
I just add file .env and inside FAST_REFRESH=false.
For me, working in Windows, WSL2 caused this not to work. Running npm start in Command Prompt, not WSL solved this issue for me.
I'm having an issue in my React environment where I must restart ('npm start') my server every time I want to view an update in the browser. Others seem to be able to simply refresh the browser without the need to restart their servers.
For instance, if I make an update in one of the React Components I can't simply refresh the web page, I have to restart the entire server.
Any suggestions how to fix this issue so I don't need to restart every time?
This problem was fixed once I moved my application out of my Dropbox directory.
Once I moved the application out of the Dropbox directory I no longer needed to manually restart the server when I made any edit to a React component. Note that the application does work just fine and auto-refresh using Google Drive
(linked to the cloud) or a general non-cloud linked folder on my HD.
I was getting the same problem using Visual Studio Code. When I made changes nothing was showing up. VC gave me a hint by saying
"Visual Studio Code is unable to watch for file changes in this large workspace"
so I found these instructions which solved the problem. Could be related.
When you see this notification, it indicates that the VS Code file watcher is running out of handles because the workspace is large and contains many files. The current limit can be viewed by running:
cat /proc/sys/fs/inotify/max_user_watches
The limit can be increased to its maximum by editing /etc/sysctl.conf and adding this line to the end of the file:
fs.inotify.max_user_watches=524288
The new value can then be loaded in by running sudo sysctl -p. Note that Arch Linux works a little differently, See Increasing the amount of inotify watchers for details.
Check out Create-React-App by Facebook. It has all the essential tools you'll need when developing React apps.
I use a combination of Webpack to bundle the js code and Nodemon for server restart. They both have watch functionality so they can watch the code to see if anything has changed.
Seems to be an norm from my research.
From this diagram I understand that the last step of the bootup process has the window manager launching the Gaia home screen.
I want to experiment and change the the first app that is booted and whatever launches when the home button is pressed, but I have not been able to figure out exactly where is that the homescreen app first launched.
Any pointers would be greatly appreciated.
There is a setting called homescreen.manifestURL that points to the manifest URL of the application that is used as homescreen. You can grep this string to know where exactly it's used.
This setting is set at build time in build/settings.js. You can try to change it there.
You can also install a separate homescreen app (see https://github.com/KevinGrandon/firefoxos-homescreen-boilerplate for a boilerplate for a homescreen -- I'm not sure how uptodate it is) and enable it from the Settings app. It has a "role": "homescreen" property in its manifest.
Maybe that's more of a Linux question than an Adobe Air one, but there you go: I have an AIR 2 app that does auto-update in the background, with no need for user interaction. It uses Air's own ApplicationUpdater framework (the one that doesn't require a UI) - all goes well until the package gets downloaded and needs to be installed - at that point, the Air Installer prompts for SUDO password and won't proceed without some user interaction.
Is there any way to circumvent/avoid that?
I solved this by adding a rule to the sudoers file (/etc/sudoers)
<username> ALL=(root) NOPASSWD: /tmp/air.*/setup
This rule can enable the update to all users
ALL ALL=(root) NOPASSWD: /tmp/air.*/setup
Note that it could lead to some security issues but I think if you are going to use this as a Linux Kiosk it's going to work.
You could do that by rolling your own updating mechanism. Is not really that difficult, if you plan it correctly you don't even need to close the app.
We did so for an internal project, where we use git. Since I guess you can't rely on Git being available on the user's machine, you could check out the server, download a zip file, uncompress it and replace the contents of your app.
AIR doesn't sign or checksum the files it installs, you can safely replace them and re-load the app without problems.
HTH,
J