[b2g] FirefoxOS Mapping [was: Dogfooding Results]
On 12/17/14 10:00 AM, Matěj Cepl wrote: On 17/12/14 03:07, Adrian Custer wrote: ... 'curating' data is a common term for checking data, fixing errors, finding mismatches, and generally not using a raw data dump but doing some work with the data before use. Reports generally from people using OSM data is that the data need work before use. This is IMHO very very much dependent on the location. ... OSM provides maps of the similar quality to Google, and everything else (namely Nokia Maps) are distant distant second. You may be mixing two different ideas: overall data quality versus specific data errors. Curating involves making sure that small errors don't ruin the rest of the data; it is not a data gathering effort at all nor a comment on the overall data quality of a data set. Sometimes a single small street is connected in a strange way to a major autoroute or even to a train track or something similar and that tiny error leads to huge visual or algorithmic problems. Curating involves inspecting the data and correcting these tiny errors that have big impacts. This ends up being critical when doing routing, or address matching, or other advanced mapping stuff and sometimes even in simply rendering the data. The OSM terms: http://wiki.openstreetmap.org/wiki/Tile_Usage_Policy Oh, tiles ... tiles are not data I meant, Right. There are two different things going on. First is a simple map widget that shows tiles. Second is getting a blob of actual data and being able to render or to do analysis on that data. The first is vastly easier than the second. However, both require a web service willing to furnish FirefoxOS devices in general with either tiles or prepared data---a non-trivial investment. and yes if OSM mapping app would be part of FxOS, then it is probably (and rightfully, IMHO) expected from Mozilla to have its own servers. But that should be covered IMHO just by providing hardware and administration of FLOSS software on it, so not much development needs to be involved, hopefully. And also this starts to be consideration once the app is widely deployed. I don’t think anybody limits https://marketplace.firefox.com/app/osm-viewer or https://marketplace.firefox.com/app/lantea-maps Well actually this is why things like Mapbox and providers of data and javascript widgets other than Google exist. Without prior agreement, HTML widgets, and especially web apps, are not supposed to hit the OSM tile servers. Other providers allow this if you sign up and register and ... but their code is generally not free software and the limits on use sometimes conflict with something users want to do, like store tiles for offline use. As for the apps you mention, lantea-maps for some reason is using the OSM tile servers directly, which may or may not be legal. I suspect osm-viewer is doing the same, though have not seen its source code. Both are probably under the radar enough not to matter. As I said, I don’t think there is anything wrong in saying that, but your statement read to me like “OSM mapping cannot be done, because we don’t have a way how to share data with other apps”. If I misunderstood you, then I am sorry for confusion. Cool. Now we are getting somewhere. This is *not* what I was saying at all. Rather, I am saying something along the lines of: For FirefoxOS to rock, it needs a good mapping app provided by default, one that works offline as well as online. In order for such an app to happen, some work will be required to curate data, set up servers (first tiles, then data), and develop code. (The gathering data step can, thankfully, be skipped since OSM is a suitable source of data.) In a general solution aiming to make FirefoxOS rock, if Mozilla were to take on this role, it could ensure a free of charge and free of registration barriers access to map data for all apps on the device, along with free software code able to evolve and grow. A modular approach to that work would think in terms of two functions on the FirefoxOS device: one part to manage data (select a region, download data from the service, store the relevant data, serve the data either raw or rendered to the data using code, and erase data no longer needed), another part to use the data for some 'mapping' purpose, presumably, in a first instance, for a map viewer and geolocator. These can be part of the same 'app' but are two very different sets of actions. A modular approach to the work, would split these two functions. This naturally leads to the ability to offer map data as an inherent functionality available to all other web apps on the device. This allows third-parties to build on the work and develop alternative apps which gives mapping room to grow. That is, a well built, modular mapping app can transcend being an app to being a map engine for the platform. One issue to this approach is that it does require a different IPC
Re: [b2g] Dogfooding Results
Matěj, On 12/16/14 2:02 PM, Matěj Cepl wrote: The map data obviously must be collected by someone and OSM data are suitable for use, though perhaps only once curated at some level. Sorry, I just don’t understand this sentence. “only once curated” ??? -ENOPARSE 'curating' data is a common term for checking data, fixing errors, finding mismatches, and generally not using a raw data dump but doing some work with the data before use. Reports generally from people using OSM data is that the data need work before use. However, for users to get the data, they can not simply hit the OSM servers due to usage terms of that project. Again, I really don’t know what you are talking about. Could you please elaborate? Obviously it would be better not to be a free rider and chip in to the OSM project some resources if Mozilla uses their servers (or to use some caching server), but otherwise legally I don’t think there is any reason not to use OSM servers. Or is there? The OSM terms: http://wiki.openstreetmap.org/wiki/Tile_Usage_Policy Then, for a good user experience (not duplicating storage and memory use), you *really* don't want different apps each storing its own copy of the map data; I smell overengineering … I think it is not crazy to expect that most people will use just one mapping application. AFAIK, Android doesn’t have any such mechanism either and OSMAnd works just fine. My conclusion arose from thinking hard about these issues as I was coding a mapping app. As I considered how the various issues could be resolved, and found the best resolution I could imagine, and then considered how to maximize the benefit of that work for the benefit of all users and developers, I reached a different conclusion from yours. If all one wants is a single mapping app, then there are lots of shortcuts one could use. If one wants to bring mapping to FirefoxOS in general, then one might reach different conclusions. So yes, my thinking may well be 'overengineering' from your point of view. From mine, it seems like smart, modular design and maximizing effectiveness of the work and resources going into the project. There is actually a current active thread on the list looking for exactly the kind of IPC system that I see being needed for sharing maps; that confirms to me that this full 'over' engineering will come to the platform eventually. A well designed app would be built for that future. Unfortunately, the amount of work required for such an app makes it unlikely to happen. Since there is no obvious way to monetize this work, it is doubly unlikely. Again, how is the situation different from OSMAnd? OSMand seems to be selling an app to finance the servers for the download data (and artificially limiting the 'free' app to ensure some revenue). I also vaguely remember there being a libosmand API that gave other android apps access to the data stored by osmand to allow broad re-use of offline map data. ~adrian P.S. your response does not read as coming from someone who undertook a serious effort to read what I said and attempted to understand what I was trying to express. That makes responding to you much less fun than it could be. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Boot.img for Hamachi.
On 9/20/14 10:48 AM, A. Crespo wrote: Hi, Could you share a working boot.img for the Hamachi device with me, please? It's a matter of live or death (well, almost). Best regards! ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Hey, bummer you are having issues. Getting a set of working images to use as last resort backup is unfortunately both the place to start and a very hard step to take. I am sure you have seen: http://k.japko.eu/alcatel-otf-hackers-guide-1.html which explains a lot. If you read between the lines, you can figure out how to sideload one of the images below (possibly after opening it to tweak the root access flag and then closing it) from the fastboot state. There are some images available here: http://vegnuxmod.wordpress.com/hamachi-alcatel-otf/ I have been running the 1.2 image since feb/march with good results (and all the bugs in that version). The other images may work but I have had mixed experiences with them: many don't boot, some boot but don't have radio, ... If you do the Facebook thing, they now have a group: http://vegnuxmod.wordpress.com/2014/08/22/unete-a-nuestro-grupo-en-facebook/ where you could participate. They may have more recent images or other advice. Another project seems to be: http://update.boot2gecko.org/hamachi/1.4.0/nightly/ with variations on the path for different versions. These images, however, have not worked for me. There are also partial images here: ftp://ftp.mozilla.org/pub/b2g/nightly/latest-mozilla-central-hamachi/ though I think without the boot.img and the binary blobs. Unfortunately, this is one OS project in which no one in the lead seems to take on the responsibility to publish a solid set of working, rooted images to help hackers get started. That means hacking is really dangerous since you can't even really start by creating proper backups. Well, you *can* but it might take you a long time to figure out how and get it done. I think I ended up using a rooted image which booted but had no functional radio to pull the original image from my phone. Then I used a smattering of Android and UNIX tools to open it, tweak it, and close it back up. It all took a long time to figure out. Once you do get a set of working, rooted images: boot, system, userdata, recovery, KEEP THEM. Recovering to fastboot on Hamachi has always worked and then you can sideload the first three and keep going from there. Good luck and happy hacking, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Where the f** is app manager?
On 8/18/14 6:01 AM, Jan Jongboom wrote: We realize that in all docs we write and demo's we gave we tell people to use the App Manager and now its gone from nightly? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Ha! EXACTLY my reaction. It's still there. The homepage of my nightly points to about:app-manager and I am happily still using App Manager. The WebIDE is not yet up to snuff. When it works it's great, and I am sure, for all sorts of reasons, is the path of the future. But for the here and now, App Manager is the way to go. (I forget the details, either syncing didn't work or debugging was flakey.) Dropping the working for the new with no transition is BULL$*@! The developers were asked nicely when this first hit if they could allow both during a transition period. That has not happened. Such it goes. courage, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Where the f** is app manager?
On 8/18/14 11:03 AM, Julien Wajsberg wrote: Just a note that you're all using Nightly here. Nightly is where no-transition changes happen, so that we can test new things in the wild. And sometimes we disable them after some days, or when it goes to aurora, or when it goes to beta. So, yeah, we used to say to use Nightly for Firefox OS development (because this is how we keep up with the changes) but obviously this also comes with such disagreements. To enable/disable webide, you can have a look to about:config, and look for the pref devtools.webide.enabled. Please report anything that you dislikes about WebIDE by filing bugs, before or instead of disabling it. That's basically your duty when using Nightly :) Maybe we should have a separate pref to enable/disable App manager so that we can have both side by side? My fear is that users don't use WebIDE at all once they disable it... - -- Julien On 8/18/14 2:49 PM, Paul Rouget wrote: Marek Raida wrote: Well, I agree heartily on this. We need ate least some level of stability, this is too turbulent... ... stability, in Firefox Nightly? Please file bugs if WebIDE doesn't meet your requirements. Much approach better would be leave AppManager as as - probably add some hint that from now one try IDE - but remove it sounds bad practice to me... You can always access the app manager by loading about:app-manager. Hey WebIDE and App-Manager developers, do you really not understand why it was such a bad idea to *replace* the menu entry for App Manager rather than *add* a new entry for WebIDE? That our points of view differ so dramatically on this issue suggests a need to address our differences. I am having a hard time figuring out your point of view. You are apparently writing tools for us to use to write great Firefox OS apps and make the platform kick a**. However, you do not seem focused on our needs. First, you make a change with little concern for our workflow and day to day work. Then, when faced with push back like this thread, your instincts are to answer with self-justification rather than trying to figure out what the user need actually was and why friction arose. The transition could have been a delight. You could have announced the tool, given us access to it, helped us discover and learn to use it and listened to feedback. All the while we would have been productive with whichever tool was working for us. Instead, in using a no-transition approach, you were essentially saying Hey, it doesn't matter that your in the middle of something potentially complicated like muddling your way through derivatives of cartographic projections, today, before you do anything else, you have to drop everything and learn to use our new tool just to get your code running on your device. From my point of view, that lacks respect. REALLY. I did not like it. The puzzling thing is that your approach was totally, completely, absolutely unnecessary. Had it been neccessary, and accompanied by an 'Sorry folks but we are having to do a no-transition upgrade on the app tool that will land next week. Find out more ...' one could have understood. But it turns out it was totally unnecessary and it caused a few hours of confusion, angst, failed reversion attempts and pain until I re-discovered the magic 'about:app-manager' URL. So, you all need to decide on your priority: is it writing your tool or helping Firefox OS developers get work done? From that decision, lots will follow naturally. Okay, I'm tired of this thread but to clear up some issues. NO ONE IS ASKING YOU TO KEEP WORKING ON APP-MANAGER, to fix its bugs, to not build WebIDE. We all expect you have great reasons for your start from scratch approach to the tool. Great, go for it. I look forwards to using it when it is stable and noticeably better than App-Manager. Also, we are all enthusiasts and will move to WebIDE sooner rather than later; Julien's 'fear' seems groundless to me. Asking us to file bugs is fine; using it as an excuse for your no-transition is bullshit. We file bugs (though given the lack of follow up on Mozilla's end, that is starting to suck too). I just spent an hour trying to isolote and file a bug in Nightly's handling of canvas size. I'll get around to filing bugs on WebIDE someday, but not today, I have work to get through. Okay? And please, never ask me to drop everything to use a tool that will probably break and file bugs when I have my own work to do. Nightly if we are going to be productive using it, can not be a 'Mozilla does whatever the fuck it wants'. Nightly, first and foremost is the latest browser code. That's how we get bug fixes for browser issues, maybe even issues we have just filed. So your developer tools in nightly should play nice with letting me reliably and safely use the latest browser code. Yes, per the shared understanding of Nightlies, you are *allowed* to do no-transition
Re: [b2g] accessing the real SD card via DeviceStorage on newer devices
Hello,
Thanks for the explanation!
Now I think I understand it, it seems the API is using the same magic
string, 'sdcard' for two different purposes. First it is the name of a
storageType, used in navigator.getDeviceStorage/s( storageType ). Then
it is also the storageName of the default internal storage:
const st = navigator.getDeviceStorage('sdcard'); //the storageType
const sn = st.storageName; //sn could be 'sdcard', the storageName
Unfortunate.
If the API were ever to evolve this should be resolved but until then we
will have to fix the docs to prevent confusion. Probably the storageType
should be called 'file' since it is storage for arbitrary files as
against for 'music' or 'photo' types and the storageName is 'sdcard' for
all.
Actually, would it be possible to add the 'file' storageType so we could
deprecate the 'sdcard' storageType and drop it in the future?
cheers,
~adrian
On 8/8/14 10:17 PM, Dave Hylands wrote:
There may be multiple storage areas.
You can call navigator.getDeviceStorages(type) to get back an array
of all of storage areas.
Each storage area will have a name, retrievable using .storageName
attribute.
If there is more than one storage area, then the internal one will be
named 'sdcard' and the physical storage are will be called something
else (sometimes, it's extsdcard, sometimes its sdcard1).
navigator.getDeviceStorage() returns the storage area whose .default
attribute is true. This is controlled by the user in Settings-Media
Storage-Default media location (way down at the bottom). If you
call addNamed and pass in a relative path, then it will be stored on
the default storage area. The onsuccess callback will get the fully
qualified name (for example /sdcard/filename) where the file was
actually stored.
The names of files on the sdcard storage area will be
/sdcard/path/filename, and the names of files on the sdcard1 storage
area will be /sdcard1/path/filename
Note that the /sdcard and /sdcard1 are storage names. Their actual
mount points on the system are determined via vold and/or
/system/etc/volume.cfg file). DeviceStorage transparently maps the
storageName into the actual mountPoint (so you don't need the mount
point if you're just accessing the files through device storage)
If you want to determine the mount point to examine the filesystem
from an adb shell, then you can determine the vold mount points by
using the command: adb shell vdc volume list (requires a root shell)
On the flame, you'll see something like: 110 0 sdcard /storage/sdcard
4 110 0 sdcard1 /storage/sdcard1 4 200 0 Volumes listed.
For volumes which aren't managed by vold (the sdcard volume on a
nexus 4/5 are examples of this), the mount point is found in
/system/etc/volume.cfg
With the engineering builds, there is a ds-test app
(gaia/dev_apps/ds-test) which I use for testing things on device
storage.
Dave Hylands
- Original Message -
From: Adrian Custer a...@pocz.org To: Moz dev-b2g list
dev-b2g@lists.mozilla.org Sent: Friday, August 8, 2014 5:06:41
PM Subject: [b2g] accessing the real SD card via DeviceStorage on
newer devices
Hey all,
is there a way to access the actual SD card on newer devices using
navigator.getDeviceStorage('')?
While older devices had /sdcard (or really /mnt/sdcard) to access
the external SD card, the trend seems to be to have that location
reference built in ROM and have a secondary location for the SD
card. For example, the TCP tablet has:
root@android:/ # df Filesystem Size Used Free Blksize /dev 797M 32K
797M 4096 /mnt/secure 797M 0K 797M 4096 /mnt/asec 797M 0K 797M
4096 /mnt/obb 797M 0K 797M 4096 /system 1G 172M 1G 4096 /cache 1G
102M 1G 4096 /data 126M 89M 36M 4096 /mnt/sdcard 9G 84M 9G 4096
/mnt/secure/asec 9G 84M 9G 4096 /mnt/extsd 29G 4G 25G 32768
where the /mnt/sdcard is some internal block of memory and the
/mnt/extsd is the 32GB SD card in the card slot.
Gaia seems to be aware of these two spaces and may be using them
for different purposes since I have :
root@android:/ # ls /mnt/sdcard/ DCIM Documents LOST.DIR ...
root@android:/ # ls /mnt/extsd/ DCIM LOST.DIR Music Pictures ...
although maybe I added the directories by hand to the external SD
card, I don't remember. The music app can access the music files on
the card though, not sure how.
The doc page
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getDeviceStorage
does not mention anything.
thanks for any info, ~adrian
___ dev-b2g mailing
list dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Proposal: Manage B2G.git scripts in a versioned repo
Hello, Thanks for putting work into the build system. On 8/5/14 4:51 PM, John Ford wrote: ...snip... My plan is to: 1) create b2g-scripts repository, containing the B2G.git/scripts directory 2) create b2g-tools repository, containing the B2G.git/tools directory 3) move all scripts in the root of B2G.git into b2g-scripts 4) use repo file copy operations (like we do for the root Makefile) to copy those scripts back into the root of the source tree 5) remove the device configuration part of config.sh 6) create a new script, config-device.sh in b2g-scripts that has the device configuration steps. 7) have config.sh call config-device.sh after the source tree is initialized ...snip... Please let me know if you have any thoughts on this issue. ...snip... In step 3, is there any chance the scripts could be segregated or at least given a name which suggests where they apply? The current B2G has scripts that run for backup, for the build, at runtime for performance and some I did not take the time to decipher. We would all benefit from having the purpose of the scripts self-evident either by their name or location. Why step 4? Why allow any scripts in the root of the workspace? Is this merely to avoid having to clean them up, because they 'belong' to other folk, or for some technical reason? Given that 'repo' is a tool to enable everyone to have a build system which is also a developer workspace, proper etiquette (and good working habits) would be to keep this directory CLEAN. Ideally, the working directory would go from 1. empty (or with a single bootstrap script) 2. filled with B2G contents 3. additionally with source code directories 4. additionally with build directories and then alternate between 3 (after a clean) and 4 (after a build) with edits to source all in the directories from steps 2 or 3. All files in the root directory would be a developer's own files they use for their own work. The B2G build system, built on repo, is totally complex and not yet documented; keeping the layout clean can only help. I would propose ruthlessly moving all the scripts into a b2g-scripts/unsorted/ directory and require those who use such scripts to give them some attention. This would include a clear name (as per the previous paragraph), proper copyright and licensing info, a link to documentation if any, and contact info for issues. Steps 5-7 begin a cleanup of the build scripts themselves a much bigger topic. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] accessing the real SD card via DeviceStorage on newer devices
Hey all,
is there a way to access the actual SD card on newer devices using
navigator.getDeviceStorage('')?
While older devices had /sdcard (or really /mnt/sdcard) to access the
external SD card, the trend seems to be to have that location reference
built in ROM and have a secondary location for the SD card. For example,
the TCP tablet has:
root@android:/ # df
Filesystem Size Used Free Blksize
/dev 797M32K 797M 4096
/mnt/secure797M 0K 797M 4096
/mnt/asec 797M 0K 797M 4096
/mnt/obb 797M 0K 797M 4096
/system 1G 172M 1G 4096
/cache 1G 102M 1G 4096
/data 126M89M36M 4096
/mnt/sdcard 9G84M 9G 4096
/mnt/secure/asec 9G84M 9G 4096
/mnt/extsd 29G 4G25G 32768
where the /mnt/sdcard is some internal block of memory and the
/mnt/extsd is the 32GB SD card in the card slot.
Gaia seems to be aware of these two spaces and may be using them for
different purposes since I have :
root@android:/ # ls /mnt/sdcard/
DCIM
Documents
LOST.DIR
...
root@android:/ # ls /mnt/extsd/
DCIM
LOST.DIR
Music
Pictures
...
although maybe I added the directories by hand to the external SD card,
I don't remember. The music app can access the music files on the card
though, not sure how.
The doc page
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getDeviceStorage
does not mention anything.
thanks for any info,
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Engineering Mode (aka service menu)
On 8/7/14 12:56 AM, Paul Theriault wrote: So to summarise the security requirements properties here: - Engineering mode will be disabled until the dialer (or other certified app) initiates the special web activity - Even with engineering mode enabled, only an app with the certified “engineering-mode” (or similar) permission can access the API which can be extended by the vendor I’d make a couple notes here: - There is no reason for side loaded apps to have this permission, and its present a very real threat of local privilege escalation, so we should explicitly prevent side loading apps which have access to these APIs (perhaps so long as the devtools.debugger.forbid-certified-apps pref is true, so engineering build phones can still access them). - The dialer should take observe lock state - we need to prevent enabling engineering mode from the dialer presented by the lockscreen ( i think your patch does this already though since it only changes the dialer, not the lockscreen dialer) We should also provide security guidance to Partners implementing engineering mode functionality to reduce the risk of security issues here. Does that sound reasonable? - Paul Hey Paul, you write 'there is no reason' and then think of a reason and provide an exception for that reason 'perhaps so long as'. This reveals you are trying to work quickly and so are not setting up a clear framework for thinking, presumably because you do not need to. For me this is difficult since I personally cannot reason this way when thinking about a 'very real threat'. Does the FirefoxOS team, or its security sub-group have a pre-defined set of users and their needs used for the security analysis of FirefoxOS? I would expect a list of strawman users whose conflicting needs are defined and agreed about, so that these needs can be reasoned about effectively, something like: Dad Jose --- Just a user, wants all the 'security' he can get Student Kate --- Builds apps, so needs to side load apps Developer Luna --- Needs root for debugging and flashing Engineer Mani --- needs root and low level engineering access HackerNuro --- wants full control i.e. j,k,l,m,n with (mostly) increasing levels of access needs. If there is such a list, I would be interested to read it so that I could contextualize these security discussions in the context of the impacts on these different classes of users. Thanks, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Show of fingers: Tracking multitouch issues on FFXOS and/or ZTE Open
Hey Gabriele, Good of you to spend the time to sample a wide range of devices. On 7/15/14, 6:20 AM, Gabriele Svelto wrote: 4) Hamachi (Alcatel ONETOUCH Fire), 2 fingers, when they're at the same Y coordinates the second finger disappears, to make things works once that happens it seems that the detection of the second finger goes down the drain. Keeping one finger on the screen and dragging the other vertically you can see the second finger being correctly detected until it reaches the same Y coordinate as the first one, then once you move away the second finger will be intermittently either detected or not. I'm running 1.2.0.0-prerelease and don't have that behaviour at all. I place my left index on the screen and keep it there. Then I drag my right index down the right hand side and the 'touch' box stays under my finger the whole way, even across the Y-axis position of the left index. Arrrgh! Double checking now before sending the mail, I can observe your behaviour too. So it sometimes works and sometimes does what you describe (for me). What a flakey, piece of !#$@!$@#$ (cheap and effective at the price) hardware/software. This looks more like a driver bug rather than a limitation of the touchscreen. Alright, I can live with that conclusion. Seems a pity to have bad code on semi-decent hardware. Overall the Hamachi hardware has been pretty good for a development phone; this flakey multitouch, an upside down canvas coordinate system, and no solid way to update the OS have been the only real impediments to productive use as a development device. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Show of fingers: Tracking multitouch issues on FFXOS and/or ZTE Open
On 7/15/14, 1:06 PM, synper...@aol.com wrote: So if this comes down to terrible driver, what happens? Is that in the hands of ZTE/Alcatel to fix, or what? Usability suffers very much with this bug IMO. At this point, all bugs are features; Hamachi is abandonware: neither the manufacturer (not Alcatel, which is just a licensed name) nor Mozilla are going to move the user experience forwards on the device. ZTE might have a different policy. The only way to code around this would be to write a touch handling library which could handle bad input. It would have to either be robust and unresponsive to problematic input or very smart and guess correctly as to what is really going on when getting bad input. (This is where I got stuck.) Otherwise, we can wait until the hardware improves. (I'm working these days with my web app bundled into an .apk and deployed onto a good android device). For FirefoxOS, since the current plan is to race to the price bottom, the majority of upcoming phones may have equally bad hardware/drivers for multi-touch input so waiting for better hardware might be a losing proposition---time will tell. The easy solution for now is 'Don't rely on good multitouch input!' in your apps. :~/ ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Show of fingers: Tracking multitouch issues on FFXOS and/or ZTE Open
On 7/14/14, 5:34 PM, synper...@aol.com wrote: Related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1038045 Basically, on my ZTE Open under FFXOS v2.1, multitouch only sort of works. What this means is that multitouch only registers discrete inputs when there is a large Y-Axis (taken from phone's normal portrait orientation) delta between the two fingers. If the Y-Axis delta approaches zero, FFXOS seems to average the location of the two inputs into some intermediate point. See this video for a demonstration of this behavior: http://youtu.be/n9cVHCBHuYY Furthermore, the ZTE Open under FFXOS v2.1 seems unable to register more than 2 discrete inputs, likely due to the above issue with the Y-Axis delta. This bug severely limits the number and kind of gestures the ZTE Open can support under FFXOS, and makes even the stock gestures usable in only very specific circumstances. For instance, as in this bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1037894 , the Pinch to Zoom gesture will ONLY work when the device is in Normal Portrait, or inverted Portrait orientation. Video of this behavior: https://www.youtube.com/watch?v=kgaUxMYGOvs So, what I'm asking for is if anyone would be willing to test out this app report back to me: https://marketplace.firefox.com/app/multitouch-detect I need three things: 1) Device Name FFXOS version 2) How many fingers (max) it could detect 3) Whether or not two fingers side-by-side (Y-Axis delta =ish 0) registers discrete or averaged input I'm curious if this is only a ZTE Open issue, or only a v2.1 master issue, or what, and Gabriele would like some further info/clarification on what devices/OS versions are impacted. Thanks all! ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Hey, Have not yet tried your app but I wrote something similar when I was working with multi-touch. On the Alcatel One Touch Fire (aka hamachi) device, my conclusion was that we were working with very limited hardware. While debugging my multi-touch library, it became apparent that a simple pinch would not be recognized correctly. As the fingers pinched, the device might decide that a finger had been removed, then that it had returned to the surface, then that it had been removed... It became apparent that providing a reliable experience on unreliable hardware was going to take a bunch of work. So I have left off that for lower hanging fruit. Also, on that device, multi-touch is limited to two. I have never seen a third touchstart event after two earlier touchstart events with no touchleave in between. I filed a bug wanting information about my code (i.e. if it were my code or my hardware) but have not yet gotten any help or comments on that bug. https://bugzilla.mozilla.org/show_bug.cgi?id=951163 Attached to the bug, you can find my test application that merely logs what events the app happens to receive as you move your fingers around. cheers and good luck, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Show of fingers: Tracking multitouch issues on FFXOS and/or ZTE Open
On 7/14/14, 6:45 PM, synper...@aol.com wrote:
On Monday, July 14, 2014 5:40:58 PM UTC-4, Adrian Custer wrote:
On 7/14/14, 5:34 PM, synper...@aol.com wrote:
Related to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1038045
Basically, on my ZTE Open under FFXOS v2.1, multitouch only sort
of works.
I need three things:
1) Device Name FFXOS version
2) How many fingers (max) it could detect
3) Whether or not two fingers side-by-side (Y-Axis delta =ish 0)
registers discrete or averaged input
Thanks for the info Adrian. That isn't my app, but merely the only
thing that showed up in the marketplace when I searched for
multitouch.
So it appears from what you're saying that the Hamachi acts similar
to the ZTE Open in terms of multi-touch detection. This could
indicate a software/driver issue, unless the two devices use the same
screen/controller.
Could you test it in the manner I do in the two videos to see if it
is the same Y-Axis delta issue that I see on the ZTE Open, or some
other issue entirely?
Thanks, Brett
Device: Hamachi (Alcatel One {sic} Touch Fire)
FxOS: Boot2Gecko 1.2.0.0-prerelease
Max fingers: 2
Y-axis issue: No
Two touch collapse to one when close issue: Yes
Failed to test on the InFocus F1 Tablet--it seems to have killed its
battery while being turned 'off'. Grrr.
Bundling my test app into an apk using mozilla-apk-cli, I can see that
my Samsung S4-mini picks up to 5 touch events at once.
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Hamachi build instructions
Hey Armen. The 'hamachi' build, in my experience, needs more supervision than merely relying on the build scripts can provide. The build can, depending on the compilation platform, silently skip fundamental steps. The probability of getting broken images is high and the build scripts do not do full backups before starting. So you will be failing a lot. Rather than modernize the build system, Mozilla has decided to simply abandon support for the phone. That's too bad because the phone is actually a pretty good development platform, with a lot of users in this country and revealing a host of issues related to low budget hardware. I upgraded to Firefox 1.2 so that I could work with the Firefox Browser App Manager while staying as close to the OS being sold on the street in this country. However, I have also succeeded in getting a partially functional boots of 1.3 and 1.4. I have never tried building more recent builds so others will have to communicate their experiences with those. To get good help for the collective wisdom on this list, you'll need to provide a bit more detail on what you are doing, notably the compilation OS on which you are working and the build you are attempting. It sounds like you are trying to build the default, master branch of Firefox OS, which I think is now version 2.1. Also, I presume, because you don't say, that you are on Gnu/Linux, say Ubuntu 14.04, rather than Osx/Darwin. First, if you need to recover from a broken build (because you don't have backups of the original images) then you might want a source of the four cannoical *droid images: boot.img system.img userdata.img recovery.img although flashing the recovery image is only needed if you want a better image than is provided by default. Also, I recommend you test the boot.img files by sideloading them first to see if they boot: that is boot into fastboot mode and then boot the image without flashing it: a good kernel will get you to the second stage splash image. The best source of pre-built images that I have worked with was: http://elsimpicuitico.wordpress.com/firefoxos/ but note that even there I ended up having to work systematically through the images to find one set that would work with all functions: booting kernel, functioning desktop, working cellular and gps. So you might have to download a few images to get things working. Alternatively, there appear to be images, possibly more recent, here: http://update.boot2gecko.org/hamachi/ but I have no experience with those. You'll need to learn to use the two canonical *droid tools 'adb' and 'fastboot'. I have found four different reactions to the images: the phone won't boot (bad boot.img), the phone will boot but the desktop won't appear (bad combo of gonk, gecko, gaia), the phone will boot and get to the desktop but radio stuff won't work, and the whole thing works. Getting a good boot.img was consistently the hardest thing for me. The boot.img needs to be a good build, be able to accept the binary blobs (which I suspect but am not sure are part of the system.img rather than part of the root disk in the boot.img), and be compatible with the gecko build in the system.img. This seems to be the hardest to get right. Beware that, if you are on Mac OS X, the build system will download the whole kernel source and then silently not build the kernel itself! Also, I don't really know when the build scripts go all the way to building image (.img) files and when they side step and flash the new filesystem directly on the running phone using 'adb'. It's all silently mysterious. Oh, and the Gonk layer seems to be evolving incompatibly between Firefox OS versions with no warning or info that I have been able to find. The builds of gecko will mostly let you know when they don't work and Gaia always 'builds' mostly because it does not really 'build' but just assembles the apps. I can't help you with newer versions of Firefox OS for Hamachi since I have not built them (working with 1.3 and 1.4 took too much time). Version 1.2 works with the App Manager and is close to what the devices come with originally so provides the best 'real world' development platform if you want to write apps for users buying that phone. Anyhow, keep at it, there is lots to learn. Google, in its infinite wisdom, pulled its documentation on Android so there is little good documentation of how things work. If you want to learn the build system, you will have to learn the repo tool (which gets the sources and allows developers to upload patches to several projects at once) and then the android NDK Makefile build system, the best explanation for which is in the O'Reilly book Embedded Android by Karim Yaghmour. Good luck with all this, ~adrian On 6/18/14, 6:47 PM, Armen Zambrano G. wrote: Hello, I've tried to update my Hamachi for the first time (I've updated a Keon many times before),
Re: [b2g] How to dual boot infocus tablet?
Hey Adit, good for you for being so brave... On 6/19/14, 6:21 AM, adit bharadwaj wrote: Hey cristian, Thnxx for the reply... I would be carefull. I knw there is no way to access the fastboot I too myslef tried to find it. adb reboot boot-fastboot got my tablet into fastboot mode. (none of the other equivalent 'reboot' commands worked though.) And even the app manager in firefox coudnt detect the device..any help on this?? Erm, yeah, there was an issue there. When in fastboot mode, Mac OS X does not see the USB device; however, glinux did, on the same hardware. I think 'lsusb' shows you the device and then you have to play with permissions to get access to it; and note the USB info is different in 'fastboot' mode and in 'adb' mode! Personally, I had to reboot into glinux to actually flash the images. I suspect the USB info sent out by the device is invalid so Mac OS X filters it out but glinux show it to you and does not care. Either that, or the USB connection of the tablet is flaky. I wonder how to flash the device if I make my own flatfish version. As adb cant detect the device?? And I ven the full factory image come der is no option to self update the device? So how to update it? Or we continue to use 1.4 till any alternative comes?? The tablet is built on an AllWinner System-on-a-Chip (SoC) which has a kick-ass feature that it will *by default* try booting from the sdcard first if it finds a zip bundle of the right name. So we could learn to hack the tablet simply by putting a zip bundle on the sdcard card ... maybe ... someday. Note I have not yet successfully built the boot.img and wasted lots of time getting a functional tablet once again so I have not yet tried this approach. cheers, ~adrian regards, Adit bharadwaj regards, adit On Wed, Jun 18, 2014 at 11:00 PM, Cristian Silaghi cristian.sila...@mozilla.ro wrote: I would recommend you to not try that. Because it is very possible to brick your device. I and other few guys we bricked our tablet when we tried to update tablet. And it seems it screwed something in the tablet. I've tried to fix tablet, but it seems there's something with the partitions. And there's tablets with no access to fastboot. Stay safe! At least till we get factory full images for tablet. Best Regards, Cristian Silaghi 2014-06-18 18:55 GMT+03:00 adit bharadwaj tidabharadwa...@gmail.com: Hello, I would like to knw how to dual boot my infocus tablet with both android and flatfish?? I want to knw how to flash the tablet with android image? I also want to how to flash the tablet to diffrent FxOs ?? regards, Adit bharadwaj ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] How to create release build for FxOS?
On 6/10/14, 8:41 AM, Johannes Bauer wrote: Now my phone is blackscreening again, as described in the [b2g] v1.2 to v1.4 update - black screen on Alcatel One Touch Fire (hamachi) thread. I thought that was a 1.4 issue, but it's not. Apparently it's a more general problem. Also seen a couple of days ago on a (then master) 2.0 build for the tablet (flatfish). The phone boots into Gonk (since adb works) but the screen is powered on but black. Can someone please look into this? If updating your phone bricks it every other time, this really should be blocker, shouldn't it? I've already provided a logcat (which apparently didn't show anything of interest). ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Build instructions and tutorials out of date / manifest files broken
Hey Chris, On 6/9/14, 7:56 AM, Chris Mills wrote: I’m in charge of Firefox OS documentation (and about a million other things) on MDN, so, while I can’t do anything about the building process itself, I can do something about the documentation. It is a lot easier to navigate than it used to be, but I’d love your help to improve it further. So one thing I have recently discovered is that the Android Open Source Project (AOSP) generally does not build its Linux kernel, which explains why many of the Firefox OS builds similarly do not build one. [Note that this may happen in two ways: for the Tablet, the sources are simply not downloaded; for the ALCATEL One Touch, the sources are downloaded but on Mac their build is disabled somehow (I have not yet figured out how.] So we need to sweep through *all* the documentation and clarify that B2G is actually not necessarily 'building to gecko' but 'building from HAL to Gecko'. If the docs advertize that we are 'Building Firefox OS', then they really have to explain how to build the whole OS. ...snip... 1. I’m not a build systems expert, and don’t have the time to constantly monitor changes in the build system, so I need someone to give me regular help on this. Yes, whomever is responsible for scheduling developers' time should dedicate an hour of the B2G hackers' work week to answering your questions. Collaboration is really about working until each person gets stuck and then passing the work to or getting help from the person who can unblock things; it is up to the Firefox OS work managers to ensure that can be true for all the different groups. Right now, those working on B2G owe you a good day's worth of explanation... Beyond this though, the build system needs love. It needs to be much clearer about what it is doing along the way. We should be able to tell: * what source code 'modules' it is planning to build * what source code 'modules' it has built * in what source code 'module' it has gotten stuck. When it fails right now, it is hard to figure out what it has done successfully, where exactly we have failed, and what it has not yet been done. I will eventually dig back into the Makefile system to see if such a documentation system is already built in or how we could add one, if it has not. ...snip... 2. Different devices have different requirements and foibles, and it is hard to find out what they all are without spending my entire life testing the build process across all devices. Again, I need some help here. It may be possible to check the docs periodically by holding build fests where we build starting from fresh installs (say in Virutal Machines) to check the instructions still work. A difficulty of the real world is that the build might require 3 different compilers and libraries, which means that ensuring each is available cleanly can be hard, let alone co-existing with other compilers the developer might have in use. So real developer systems will always be more fragile than the documentation can solve, hence again the need for help from the industrialized build system. ...snip... Adrian, your work on writing build docs sounds really interesting, and I’d love to find out more about this. It is trivial really; I merely want a long set of instructions which does what the build scripts do but one step at a time. I'd like eventually to do a full build by hand, starting with the device backup, then running 'make' on each separate project, in order, for each of: * the development tools for the host computer * the firefox OS pieces for the targeted device * the runtime tools for the host computer since right now the B2G stuff is building everything at once which does not teach me what it is doing. Once it is clear what the different parts of the build scripts are doing, it becomes easier to break them into byte size pieces and try to document each and make it robust. But, since for now I am working on this on my own, it will be a slow, long term project. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Build instructions and tutorials out of date / manifest files broken
Hello again, On 6/7/14, 9:47 PM, LazerUnicorns Developers wrote: Hey guys, I wanted to give you an update, I managed to root the device and inspect / reverse engineer the stuff that is going on there. good news! I'm currently trying to port autosign for Linux, so that you can ship ROMs with your own update.zip on SD card, which eases up installation pretty much. Very cool. 2. I have never built anything but gaia, as I can't get through the config.sh call. If you read that shell script and trace it out, it's essentially making a trivial config file (.config) and then doing massively heavy 'repo sync' which is downloading all the git repositories for all the projects (gigabytes). This second will fail a few times before the hundred or so repositories all get downloaded correct; you can run 'repo sync' again anytime to try again or to update the projects later. Btw, the 'repo' tool splits the source code repositories (.git directories) which it puts, by default, in $b2g_work_dir/.repo/projects/, from the working copies (i.e. the files) which you see in your B2G working directory. The 'manifest file' is also in the .repo/ directory. (So yes, the repo developers decided to store GIGABYTES in hidden directories; some people don't really understand. However, you *can* make .repo a symlink to a REPO/ directory to clarify for yourself what is happening.) Gaia itself was built successfully and flashed after the rooting process. As the master variant depends on the new Gecko API, I guess I have to built everything from scratch (navigator.mozInputMethod.removeFocus() seems to be not existing in the OEM Gecko variant, so all select fields are broken :P). 3. I couldn't fix the xml file myself. How can I fix the repo url? The URL is set in $b2g_work_dir/.repo/manifest.xml (note the dot in .repo) which is a symlink to $b2g_work_dir/.repo/manifests/$mydevice.xml. So backup and hack away to your heart's content. You set a remote name=... url=... block at the top of the file with the URL. You then, in the individual project .. block add two attributes: remote='$name_used_above' and revision=.. Take a look at hamachi.xml for an example. The problem is - as I never built anything yet - I have no idea where the repository has to be cloned to. repo takes care of that so you don't need to change anything. It uses git commands to put the git 'repository' in .repo/projects/ and the working copy (the files) in the $b2g_work_dir. Should it land in external/tinyxml2 or platform/external/tinyxml2? Again, leave in place what is there; you just add to xml attributes to the file. It's superconfusing, I have really no idea how to overwrite it correctly as the platform/external/tinyxml2 is listed nowhere as a remote inside the base-caf-jb.xml. If the remote= and revision= are not set, repo uses the defaults which are set globally for the manifest file. Please help. hope that helps, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] B2G 2.0 Release Milestones
Hello, Could you explain who is making these decisions and how these decisions are being made? On 4/30/14, 6:35 PM, Lawrence Mandel wrote: I'd like to share some changes to the release milestones for B2G 2.0. Our intention is This 'our' makes it sounds like there is some FirefoxOS project leadership group such as a project steering committee. However, I have not yet heard of this leadership group. Also, would it be possible for one of you in the leadership group to add this group of the Firefox OS organization to the wiki list: https://wiki.mozilla.org/FirefoxOS or https://wiki.mozilla.org/FirefoxOS/functionalteams which nominally try to outline the structural organization of the project? Thanks, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] software layer of provider lock by Firefox OS
Hey, On 4/19/14, 4:01 PM, Hydroid wrote: I have a locked alcatel one touch fire with firefox os and I have tried to unlock it. I flashed the system from 1.1 to 1.3 but it didnt work. So my problem: On what software layer is the phone locked? You are right that the 'lock' mechanism is below anything we have access to. The Alcatel has two CPUs with the first running a closed source OS and controlling, among other things, the cellular telephony chips. The second CPU runs linux/gonk and is what we can modify if we have a 'rooted' phone or access to the fastboot boot stage. I am not sure whether the 'locking' of the phone is a software thing or involves some modifiable ROM in a hardware chip. However, it requires low level interaction. There is a system to unlock the phone and many telephone shops claim to be able to get the right code to 'unlock' these phones but I have not yet been successful. If you try, beware that there is a hard coded limit on the number of unlock attempts you can make before you will need to get help from the various companies involved in selling you the hardware. Yeah, this is terrible. ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Never again will I buy a ZTE anymore.
On 4/12/14, 2:53 PM, Ernesto Acosta wrote: It is intolerable lack of communication that exists with ZTE. It is intolerable that offer little support to ZTE Open, to the point that they have not even given an official explanation of why updates have not gone. In social networks ZTE only promotes and supports for their Android phones. Now there's a comment on the net that says that ZTE will not give more support to ZTE Open. Honestly, never, I will buy another product from ZTE, at least FirefoxOS included. I stay with my ZTE Open because I have no choice, but the next think about buying a Geekphone or any other phone to go on sale FirefoxOS if they sell any. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Hey, Bummer that you are having a bad time with a Firefox OS device. I know that it is totally frustrating to have one's phone, our most intimate device, not feel reliable and not be a joy to use. The blame, however, does not lie solely, or perhaps even at all, with ZTE. My own feeling is that the blame for lack of communication, explanation, and support lies much closer to home. While I originally blamed the hardware providers like you are doing, I now believe that Firefox OS itself, and Mozilla, deserve the core of the blame. The fundamental irony of Firefox OS is that Mozilla builds the *only* operating system on which the Firefox browser runs where that Firefox browser CAN NOT BE UPGRADED! Building a Firefox OS where the browser (i.e. the entire Gecko layer, not the 'browser' app) could be updated by end users would solve most of your issues: you would get an up to date browser environment and would be able to install the new version of the core Gaia apps. Conversely, the current situation, where you can not even install security updates to Gecko, leaves you and all of us users, vulnerable to any security flaws discovered in the software. This situation is also terrible for app developers since we are going to have to code either to the lowest common system (Firefox 18 if I remember correctly) or to support the multiple browser versions on the different devices using duplicate code. The situation also sucks for Mozilla developers because they will not be getting their great work out to the largest possible audience. This is lose, lose, lose. This design flaw, as best as I can tell, is purely architectural; there appears to be no fundamental technical limitation which would prevent such updates to Gecko. (The technical limitation of support for new Web API which depend on operating system level code changes is real and would require an upgrade to the operating system itself which is more complex and may or may not involve device manufacturer support; however, those API represent a small issue compared to security updates, updates to the core HTML/CSS/Js execution environment, and updates to the main Gaia applications which ought to be as regular as updates to the Firefox browser on any other, i.e. 'desktop', OS.) The design flaw preventing Gecko upgrades on Firefox OS is Mozilla's; the lack of a response to that flaw is also Mozilla's. A good response to your issue would be to acknowledge it and explain the various ways in which it is being addressed. However, there is no one on the Firefox OS team who has taken on the responsibility to foster communication between end users and the project leadership. This is a failure of the the leaders of the project who should either be doing that work or delegating it to make sure it gets done. We end users can not simply solve this on our own: developing a clean architectural separation between Gaia and Gonk requires a complete knowledge of both the multiple code layers and of the Android+B2G build system, something that only the whole project, working together, can achieve. The (re)focus on fixing your issue is also the responsibility of the leadership. A good response to your issue would be for the leadership to make sure communication around the issue happened, a decision was made as to how to go about fixing the issue, and the project stayed focused on fixing that complex and central issue. Instead, the Firefox OS project seems to be a bunch of separate code teams, each doing great work building new features and better applications but leaving the core issues unaddressed. (I have a long email set to go out to the Board of the Mozilla Foundation on this issue of the lack of effective communication, leadership, and end-user focus in the Firefox OS project since the board members are the only ones that I know of who could assess the project to see if my analysis makes sense and deal with it if I am right; however, that letter is on hold until the CEO and board situation settles down.) This of course does not help you, an end user and probably a developer. I only encourage you to see that it is as
Re: [b2g] GPS/Wifi hybrid positioning
Hey all, Interesting news, coming from Andreas Gal on the dev-b2g list: On 3/24/14, 9:22 AM, Andreas Gal wrote: Support for the Mozilla Location Service is available in trunk builds I believe, and we will start using it in production devices soon as well. Thanks, Andreas Does this mean that a bunch of work has been done on MLS vetting the data quality and improving the error estimates to bring it up to production quality? What kind of analyses are being performed on the data to evaluate their quality? What kinds of algorithms are being developed to improve error estimates? I had not been aware that this kind of work was ongoing and thought that for now MLS was acting like a pretty dumb data repository and that the 'service' was offering exceedingly coarse positions with fixed error estimates at the kilometer scale. We must all know that there are many issues with the quality of the data accumulated so far. Similarly, we all surely know how horrible the experience is to be given a geospatial position which is grossly inaccurate; some will even have personal experience of the waste of time and endless walking that can result when being forced to rely on such data but being given grossly inaccurate positions. So I wonder how you are expecting to protect Firefox OS users from the current data quality and algorithmic analysis issues. My own work trying to grapple with this is only just getting to the point where I can think about analysis. I have a prototype stumbler app and am accumulating a systematic (but nonetheless problematic) data set of Montevideo, wherein all data are essentially gathered in the same way (at bike speed, at times of good satellite availability, with the same value for the maximum acceptable positioning error, ...). Since I am holding on to the data, as well as uploading it to OpenCellID and MLS, I will be able eventually to do real analysis of the results. Already, I have started wondering about problems in the data gathering of the Wifi base station locations. (I suspect, but have not yet confirmed, that the hardware and code behind the navigator.mozWifiManager API call are storing signals based on the periodic broadcast from wifi base stations but only dropping the base station after some timeout. I am seeing residence times of base stations in the data reported by the above API of around a full minute, a time within which I have moved far out of radio contact with the base station, far enough away that relating the later positions to the wifi base station makes for a crummy position estimate (~300meters of that error term alone). Confirming this and figuring out how to handle it will require a bunch of field work, something I am not yet sure how to do.) A solution might eventually be to eliminate the presence of a wifi for all positions beyond a certain distance (or time) from initial observation (or at a position or time based on some calculation involving initial observation and the evolution of signal strength), something which could even be done on the server eventually for already accumulated data. Are you already doing this kind of analysis? If so, how? Do you dump the database into PostGIS and do analysis there, or have you written your own geospatial algorithms? It would be interesting to have the discussion of the work you are doing to bring the whole system up to production quality on the https://mozilla-ichnaea.readthedocs.org/en/latest/calculation.html web page. That should probably include a discussion of all the different error terms you are considering in the position analysis and how multiple observations attenuate the different terms. Thanks for any info, ~adrian On Mar 24, 2014, at 12:16 PM, Adrian Custer a...@pocz.org wrote: On 3/24/14, 8:45 AM, Marek Raida wrote: Hello, could someone tell me please, if hybrid Wifi/aGPS positioning should work in FFOS 1.3? Accordingly to https://wiki.mozilla.org/B2G/Roadmap it was added to 1.2 (but strangely without any issue reference). I've spent a week running around town with Android device with mozStumbler turned on and acquired a lot of data (https://location.services.mozilla.com/leaders - user revelon ;-) , but still, getting position outside is painfully painfully slow, and inside of building nearly impossible (on device GP Revolution). Thank you for an answer/status, Marek ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Hey Marek, Glad you were productive stumbling. As I understand things, none of your data are exposed to the Firefox OS Geolocation call. The Firefox OS navigator.geolocation call works but still relies on the service of a third party (some Google service if I remember right). This means you won't see your data that way. However, the call should work on your phone, so I am not sure why it does not. Perhaps, that service does not have
Re: [b2g] GPS/Wifi hybrid positioning
On 3/24/14, 8:45 AM, Marek Raida wrote: Hello, could someone tell me please, if hybrid Wifi/aGPS positioning should work in FFOS 1.3? Accordingly to https://wiki.mozilla.org/B2G/Roadmap it was added to 1.2 (but strangely without any issue reference). I've spent a week running around town with Android device with mozStumbler turned on and acquired a lot of data (https://location.services.mozilla.com/leaders - user revelon ;-) , but still, getting position outside is painfully painfully slow, and inside of building nearly impossible (on device GP Revolution). Thank you for an answer/status, Marek ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Hey Marek, Glad you were productive stumbling. As I understand things, none of your data are exposed to the Firefox OS Geolocation call. The Firefox OS navigator.geolocation call works but still relies on the service of a third party (some Google service if I remember right). This means you won't see your data that way. However, the call should work on your phone, so I am not sure why it does not. Perhaps, that service does not have coverage of your area? Mozilla Location Services, which gets the Stumbler data, is not used for Firefox OS Geolocation. MozLocServ is still in data acquisition mode (although you can manually call the service to ask for its estimate of your position, but that has fixed and very poor error estimates). You can ask questions about MozLocSev on another list: dev-geolocat...@lists.mozilla.org where you might get more precise answers about how your uploaded data are being processed and used. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Status of Firefox OS?
Hello all, Yesterday was an important milestone for Firefox OS, according to: https://wiki.mozilla.org/Release_Management/B2G_Landing#Versions_and_Scheduling including: * my handset's operating system reaching 'End-of-life' * v1.3.0 reaching 'code freeze' * v1.4.0 reaching 'functional complete' although it might be that this wiki page is irrelevant. Over the last two decades, my experience in the world of free software has been that projects reaching important milestones put out announcements to the affected communities about the status of things, the plans, and other relevant information through which developers, users, document writers, the press, and the interested public can remain informed about the project. Similar milestones have come and gone since November without such announcements. Could someone in the know please explain what is going on? Thank you. ~adrian P.S. Answers to some of the following questions would be useful: Does Firefox OS ever actually declare a 'release'? Did any version hit 'release' yesterday? What is meant by the next section https://wiki.mozilla.org/Release_Management/B2G_Landing#Rough_Update_Graph when it talks about '1.2 release'? Did FfOS 1.1 reach 'end-of-life' yesterday and what does that actually mean? Are people buying telephones in Uruguay today vulnerable from here on out to all security flaws discovered in the OS and in the browser? Is the rumor that there will never be any over-the-air updates to handsets here true? Did Firefox 1.3 reach 'code-freeze' yesterday? What is the status of the code base at code freeze? Did the schedule slip successfully address the issues which caused the slip? Did Firefox OS 1.4 reach 'functional complete' yesterday? Was the planned functionality completely written? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Introducing B2G to x86
Hey Hugh, On 2/25/14, 11:30 AM, Hugh Tay wrote: Hello everyone, I would like to initiate a new open-source community project to port FireFox OS to the Intel/AMD x86-64 platform. There is lots of community work going on around Firefox OS and that could well be brought together into a community umbrella project. This is very much needed so as to concentrate our efforts, to provide a single reference point for the various efforts, and to address the needs of the community which are so low in the Mozilla priorities. There is lots of work going on in South America already so bringing that into a common project would be doable. As far as x86 is concerned, are you aware that the new geeksphone is running on an Intel chip? That should provide the starting point for your work once (and if) they release the source for that port. I suspect, without basis, that Intel may have some resources behind the port as well since they are trying intensely to gain a foothold in the mobile device space, so there may be help for your effort. Certainly Geeksphone will be behind the x86 port. The phone has not yet shipped but I suspect binaries will eventually be available on https://downloads.geeksphone.com/ (with a bad certificate) or http://downloads.geeksphone.com/ (unsecure) although I am not sure where the source code of the port will live. That work, if available, would surely be a place to start since it will be a working port to x86. I'm thinking along the lines of the port for RasPi that Oleg Romashin developed - executing Gecko on top of a vanilla Linux kernel with only the essential drivers/libraries loaded. Supposedly this method would let us run FF-OS on an x86 PC like other Linux distros; e.g. Ubuntu, Fedora; just that its UI would be Gecko instead of KDE or Gnome. This way we should also be able to reduce our dependence on Android as the backbone of FireFox OS. The dependence on 'Android' is more at the level of build infrastructure than anything else. There is a 'fake dalvik' needed for some reason I have not yet understood. Apart from that 'AOSP' is merely a convenient place to get source code and the NDK is simply used as a build infrastructure for the project. The code for Gonk is essentially linux + rootdisk binaries + firmware + glue so that 'Android' should not cause you concern. With a clean, well designed build and configuration system, the original source should be changeable at will. cheers, ~adrian Perhaps further down the line we could also take advantage of UEFI booting and B2G in 10 seconds? Would anyone be interested in contributing to this effort? Looking forward to an exciting time ahead! Hugh ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Gecko version of the AppManager simulator
Hey all, In my debugging applications, I put the string defined in navigator.userAgent into the footer. Currently, in the app manager of Firefox nightly, when running the Firefox OS 1.3 Simulator 7.0pre7.20140113 the version string is Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0 which is the same as I get for the 1.2 version of the simulator. On my phone, which is FxOS 1.2, I get Mozilla/5.0 (Mobile; rv:26.0) Gecko/26.0 Firefox/26.0 and I thought 1.3 was running on Gecko/26.0 and 1.4 targeted at 28.0. what's going on? Is the simulator lying or using an older gecko? thanks for any info, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Gecko version of the AppManager simulator
On 2/24/14, 2:07 PM, Ben Kelly wrote: There is a bug in the user agent. See: https://bugzilla.mozilla.org/show_bug.cgi?id=964598 Hope that helps. Ben thanks. ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] FirefoxOS tree structure
On 2/5/14, 5:06 AM, Jose Vidal wrote: Hi everyone, What's the Firefox OS source code directory tree structure ? Hey Jose, The structure of the directory in which you build Firefox OS is indeed quite hard to understand. The directory does several things at once and then the Mozilla team decided that, since it was a mess anyway, they were welcome to make more of a mess of things. You need to understand, first, that the Firefox OS directory will do several things: * it is a repo directory that will be used by the Android project's 'repo' tool which means that: - it will have, by default, a hidden .repo/ dir with: 1. a new copy of the 'repo' tool 2. a manifest.xml file describing the project 3. a directory full of Git version control repositories - it will end up with *working copies* of all the source code used to build the project * it is a source code directory which you could use to work on the source code of the different projects, which you could do either using the 'repo' tool to manage work on many of the projects at once or using the 'git' tool to work on a single or few projects together, * it is a Make directory tree in which the source code will all be built using the Android project's Makefile system, * it is a build directory which will, after the build, include the output directories with the source code results, notably in the ./out/ and ./gecko_objdir/ directories, * it is a runtime directory which holds a mess of undocumented scripts used to run and profile the result of a build. Note also that the project is building not just Firefox OS but a bunch of Android tools including the 'adb' and 'fastboot' tools to interact with a device over USB, some tools used to assemble images, and a bunch of profiling tools based on Eclipse. This latter means that the directory requires two build chains, one for Firefox OS based on the architecture of the device you are targeting and another for the tools based on the architecture of the machine on which you are running the build. Note also that the contents of the directory will depend on the device you are targeting since each device gets a different 'manifest.xml' file listing the project contents. Finally, note the the builds are all dysfunctional to various, undocumented, extents. By default, the builds only go so far and then expect you to blindly trust the ./flash.sh script which will copy over what you have built to the device, something that only will work if you have root permissions on the phone. The builds will not, by default, build the four cannoical files: boot.img recovery.img system.img userdata.img but instead will try to copy the files over to the system/ and data/ partitions on the device. There are a mess of undocumented targets for 'make' that you can magically call to try and make those images, except that for some projects you can't actually generate the boot.img file. (Actually, forget the recovery.img; you should be able to leave that alone and use the one on your phone.) If you take the time, it turns out you can start from an empty directory to build Firefox OS! Note that this is only a vague outline: I don't want to take the time to look all this up right now. I spent a month and a half working on a build tool with better documentation that the scripts provided by Mozilla but got discouraged when I discovered that the scripts silently skipped building the kernel on the device I was working on building. From what I remember, the steps are something like: 1) use curl or wget to get the repo tool launcher (a single file) wget src-of-repo ./bin/. 2) run the repo launcher pointing at the source of manifest files ./bin/repo -u -b ... -m = this will add to the repo directory (.repo/ by default) (1) a full copy of the repo tool (2) a copy of the manifest.xml at the right branch 3) run 'repo sync' with the right flags = this will get a clone of all the git projects and put the git repository in the .repo/projects/ dir and put a working copy of the source code in the top level directory (WARNING THIS IS AROUND 10GB OF CODE!) 4) configure the system 5) optionally copy files from a working device locally 6) build the system by (1) setting up the right environmental variables and (2) running make (WARNING THIS WILL TAKE A WHILE AND WILL FIRST TRY TO SYNC UP THE SOURCE CODE OVER THE NETWORK.) 7) get the build results onto a device. This depends on how deeply you built the projects: you may brutally copy files over to the existing partitions of the device or you might actually use the 'fastboot' tool to copy over full images overwriting the partitions. The scripts in the B2G git project (the one on GitHub not the one on
[b2g] How wep apps know when data connection use fails due to insufficient balance
Hey all,
How does a web app know when an XHR is rejected because of lack of funds?
In the catch block of:
try {
var xhr = new XMLHttpRequest( props_for_request );
...
xhr.send( JSON.stringify( {'items': items_to_send } ) );
...
} catch (err) {
...
}
I am currently getting the error :
[Exception... Failure nsresult:0x80004005 (NS_ERROR_FAILURE)
location: JS
frame::app://6e9ae3f8-4f4e-8243-8087-4b1a2015c199/app.js::send_items::line381
data:no]
I currently suspect that this is due to a zero balance which blocks the
use of the cell phone data channel.
Is this error the most detailed information available to the web app for
such a case?
Is the data:no at the end a canonical indicator that the use of the
data channel has been refused?
Is there any way to know that the refusal was due to lack of funds
(versus badly configured data channel or other reasons)?
I'd like to help the users by transforming that error into a more
helpful prompt but to do so I wanted to get a sense of the scope of
these kinds of errors sent to a web app.
thanks,
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Documentation of MozMobileConnectionInfo.type
Hey all,
The page:
https://developer.mozilla.org/en-US/docs/Web/API/MozMobileConnectionInfo.type
lists some of the possible connection types, ending with 'etc.'.
Unfortunately, coding against an 'etc.' is kindda hard. Working from:
navigator.mozMobileConnection.voice.type
I need to make a lookup object like:
var cell_type_lookup = {
'type': ['celltype', 'itemtype'],//Header field
'gsm':['gsm', 'gsm'],
'edge': ['gsm', 'gsm'],
'gprs': ['gsm', 'gsm'],
'umts': ['umts', 'gsm'],
'hspa': ['umts', 'gsm'],
'hsdpa': ['umts', 'gsm'],
'hspap': ['umts', 'gsm'],//check name
'hsupa': ['umts', 'gsm'],
'cdma': ['cdma', 'cdma'],
'evdo': ['cdma', 'cdma'],
'ehrpd': ['cdma', 'cdma'],
'lte':['lte', 'gsm']
}
which I build from the info on:
https://mozilla-ichnaea.readthedocs.org/en/latest/cell.html
but the result is that I have to guess at values (e.g. what hspa+ might
have been converted to) and don't know how accurate or comprehensive the
lookup object might be.
Could one of you in the know could point to the place in the code where
these values are actually defined? Thanks.
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Restructuring the MDN FxOS zone
On 1/9/14, 5:26 PM, Chris Mills wrote: Hi all, Hope you are having a good start to 2014! One of my first tasks this year is to restructure the Firefox OS zone on MDN (https://developer.mozilla.org/en-US/Firefox_OS). There is some good content on there, but it could really do with the flow of content and structure improving. I have started to devise a plan at https://etherpad.mozilla.org/mdn-fxos-zone-restructure If you have any feedback about what could be improved on the Firefox OS content zone and what you think of this plan, please let me know, by responding to this mail, or writing your feedback into the “FEEDBACK SECTION” near the bottom of this doc. It’s at an early stage, but I reckon a bit of restructuring will really sort this out. Best regards, Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills Hey Chris, Your etherpad is a start. However, there is a bunch of work needed to get a good structure for the docs going forwards. I took action a few weeks ago to work on this. Unfortunately, I got side tracked quickly into trying to fix things rather than trying to document the mess as is. As far as an outline, this is as far as I had gotten: Landing page (pictures and redirects to sections or to other sites) Introduction * Define Firefox OS as both a *project* and an *OS* * Current status * 2013 * 2014 plans * This site is for: $audience_list * Other resources (also, resources for $non_audience) The Firefox OS Project * Mozilla -teams -community * Android project (via codeaurora.org) * Device makers (?the new alliance?) (e.g. QCOM) * Device assemblers (e.g. Alcatel) * Device distributors (e.g. Movistar) The OS * Overview * Detailed architecture of the pieces * ... Building * Overview Build Types: Device, Emmulators, Desktop Build components: Android tools, Profilers, Output Dir, Images Feature support chart The build process: workspace, goals, steps Caveats: disk size, network bandwidth, compile times * The workspace Layout Uses (build, code w/repo, code w/ git) * Pre-reqs * Configure * Build * Run? * Install * Customize Using the build * Screenshots * Remote Debugging * Profiling (and memory usage) * Remote control of a device How to file bugs * These docs * App Manager, Simulator * FF Responsive design View * FF Developer Tools * Gaia Apps * Gecko on Gonk * The build workspace Developing Firefox OS * Working in the workspace * repo in the workspace * git in the working dirs * linking in separate working dirs * How to contribute: Gaia, Gecko/Gonk, Gonk, Docs... Devices * ZTE Open * Alcatel OneTouch Fire * ... So that's not much better than your etherpad. Its not comprehensive yet, it does not flesh out any of the topics, and does not consider what else is needed. This view adds, compared to your etherpad, the idea of discussing the 'Project' and its 'community' which are important to outsiders and for building a community (although that may not be something this project wants or wants enough to invest in). However, while working on the docs and thinking about the various users, it became clear that we should at least try to do better than the current build system. So, in the last few weeks, I have been trying to get a handle on the build. I spent a couple of weeks hacking a bash script framework to manage a Firefox OS 'workspace'. The framework allows for a number of 'phases' (e.g. bootstrap, configure, build, run, install, configure) each of which might have a number of stages. Thus we could do: fxos setup and get the result attached to this email. (Really, it just tells a user what their machine needs for the different parts of the build, i.e. what is needed in the bootstrap.) The script framework should make it easy to isolate the code that does stuff from surrounding code that documents what has been done and what is needed. These days I am wrangling with repo and git and the various workspace configurations which are possible, (i.e. repo mirrors, single branch clones, shallow clones, group based manifests). I still have a ways to go on this but it might eventually get somewhere. It seems, from the general silence on the dev-b2g list, that there won't be much help coming from there. So we will have to invent a semantic structure to Firefox OS itself that we can then document. Unfortunately, since most of the details are over our heads, our readers will suffer from our lack of understanding. Technical debt begets more technical debt. From inside Mozilla, it would be of use to find out from recent hires working on Firefox OS what information they found they needed to become effective contributing. There's surely a lot that passes by word of mouth. Also, I have *no idea* about any of the runtime
[b2g] The Gaia repos and their suitability for FxOS
Hey all, There are two Gaia repos that I have run into so far: one on mozilla and one on github. The one on github seems relatively clean. The one on mozilla, tagged 'release', is a mess. The latter is used by FirefoxOS., at least in the hamachi manifest used by the Alcatel OneTouch fire. Are these two repos split into 'production' and 'development'? Why is Firefox OS (at least in its hamachi manifest) using the mozilla.org repository? Do these repositories have maintainers? If so, why are there branches on the mozilla.org Gaia repo with crazed names that have not been touched since August and April? Gaia on GitHub == This seems relatively clean: galet:gaia acuster$ git remote show origin * remote origin Fetch URL: https://github.com/mozilla-b2g/gaia.git Push URL: https://github.com/mozilla-b2g/gaia.git HEAD branch: master Remote branches: bug-952611tracked mastertracked ord tracked rocketbar-places tracked v1-train tracked v1.0.0tracked v1.0.1tracked v1.1.0hd tracked v1.2 tracked v1.2f tracked v1.3 tracked ...snip... Small number of branches, bug*, ord and rock* with relatively recent commits. Fine. Gaia on Mozilla (used by Firefox OS, hamachi build) === The GitHub repo used for Firefox OS, despite having 'release' in its name, seems to be the hacking repository. It's branches are a fant**!@ mess: git remote show mozillaorg * remote mozillaorg Fetch URL: https://git.mozilla.org/releases/gaia.git Push URL: https://git.mozilla.org/releases/gaia.git HEAD branch: master Remote branches: 816135 ... bug-845097-reverting... bug-918303 ... bug-952611 ... bug914179 ... camera-fix ... design-update ... e.me... fix-homescreen-dock-tests ... fix-imap-literal-landing... fxa_mo ... fxa_module ... master ... nightly ... offline ... ord ... rocketbar ... rocketbar-places... rocketbar2 ... s3-uploads ... shira ... task-switcher ... upstream/master ... v1-train... v1.0.0 ... v1.0.1 ... v1.1.0hd... v1.2... v1.2f ... v1.3... v1_train/bluetooth/Bug905944_confirm_receivi.WTF? v1_train/clock/Bug842750_Default_alarm_name_not_localized ...WTF? ...snip... So this does not seem like a 'release' repository (despite what the name says). It also does not seem to have anyone doing basic maintenance dropping abandoned branches with crazed names. Some explanation for this state of affairs would be appreciated. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Experience using Repo --depth or repo project 'groups'?
Hey all, Do any of you have experience working with the more advanced aspects of the 'repo' tool such as the --depth=1 argument to 'repo sync' for shallow git clones or the 'groups' attribute of the 'project' XML element in the manifests for targeted 'repo init' invocations? Note that I have not yet fully understood the build so that these questions might well arise from misunderstanding. (This all started as an attempt to improve the docs but that proved impossible without digging deep into the 'B2G' world, which has now turned into an effort to clean up the 'B2G' workspace and the scripts driving the build. It seems there might be room for a better use of 'repo'. The 'repo' tool apparently allows shallow clones. The 'repo sync' command accepts a --depth=1, which should eventually get passed to 'git clone' and thence to 'git fetch' leading to shallow clones of all the projects included in the 'repo init'. If this could work, it would be of great use to most of us since almost none of us are actually hacking in all of the 'repo' projects within our workspace. I believe that git allows a shallow clone to later be expanded to a full clone; if so, we could do a shallow clone of all projects by default, then explain how to get the full clones later for developers working with specific projects. (My experiments on this are on hold pending the activation of my new 'unlimited' internet connection plan, which might happen today.) The 'repo' tool also apparently allows the 'projects' to be grouped into named groups so that 'repo init', when given a group name, will originally load only the projects in that group. Given the diverse user base that Firefox OS is gaining, it seems we might be able to leverage that to allow: - gaia only builds (with file copy to device) - gaia and gecko only builds (with file copy to device) - full system.img and userdata.img builds (with flash to device) - Android tool builds: (adb, fastboot, mkbootimg) builds - gonk builds: boot.img, (with flash to device) - Desktop tool builds: whatever those runtime and profiling tools are really about. The idea is to minimize the download size and build complexity for those users who don't need it. We could use the 'groups' attribute to make, say a 'gaia' group that has only the - B2G build (a fork of the 'ndk' project, needed in all groups) - ?some build glue taken from gonc-misc? - gaia and then a user who has acquired an 'adb' binary from somewhere can copy the new gaia files over. That's my current hope. However, its now clear I need to dig into the 'gonk-misc' project to see what glue it is bringing to the 'ndk' build system and so it seems worth asking for advice/pointers. Do any of you who have written this code have a sense of how we could modularize the build of the Firefox OS components into such 'repo' groups? Have you tried this? This is part of my work developing a workspace and management system for Firefox OS which is both clean enough for me to be able to work within and clear enough for me to feel like documenting. It is also obvious that the growth of Firefox OS has lead to a greater variety of users than originally present: * enthusiasts that want a new build, * crazed enthusiasts that want to customize their own build and the splash screens, ringtones and other goodies, * web app developers that need a new build to use Firefox Dev tools or to tackle bugs, * gaia developers who need to stay current, * gecko/gonk developers doing their thing, * developers targeting new hardware devices, * distributors wanting to customize a distribution with splash screens, ringtones, particular app bundles, ... We are many, all with slightly different needs. The current B2G project is a mess of scripts which becomes, after repo init, a mess of directories. For my own needs, I want a clear separation between: * workspace stuff, * source code working directories, and * compilation output. As a bonus, I'm looking to lighten the downloads and target the build for specific uses. So I am working on a new version of 'B2G' with a cleaner layout, with a set of manifests which also use a clean layout, and a workspace management system (bash script) which is modular for extension but walks users through machine preparation, build configuration, device backup, source code build, compile result installation and possibly eventually runtime stuff (?profiling?) and build customization. That's the grandiose plan. The issue of the moment, however, is wrangling 'repo' and any advice on that would be appreciated. Thanks, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Uniquely identifying a device
Hey all,
Does Firefox OS provide any way to uniquely identify a device?
Is this possible both at the UNIX level ('adb shell') and from within
app code (with suitable permission)?
The Android community has been tackling this need for a long time and
has developed multiple approaches though, in modern versions, the OS
provides a way for user code (Java) to obtain a unique id per device. See
*
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
* http://www.pocketmagic.net/2011/02/android-unique-device-id/
* http://stackoverflow.com/questions/13744565/android-device-id-confusion
for discussion of the issues and various solutions.
So far I am poking around in /proc and /sys land from 'adb shell' but
have not yet found anything canonical. There is
cat /sys/devices/virtual/android_usb/android0/iSerial (MSM7627A)
cat /sys/devices/virtual/android_usb/android0/idProduct (9025)
cat /sys/devices/virtual/android_usb/android0/idVendor (05c6)
but I am not sure how 'unique' the iSerial number is. (Note that the
idVendor is probably, in general, related to the list on the page:
http://developer.android.com/tools/device.html
or on the more complete page:
http://www.linux-usb.org/usb.ids
though I am working only from my own device.
I have not yet found a way to extract the IMEI (GSM telephony), let
alone found a way to identify future CDMA devices (ESN/MEID) or devices
without any telephony.
Thanks for any help,
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Uniquely identifying a device
On 1/4/14, 9:29 AM, Alexandre Lissy wrote:
Le 04/01/2014 12:24, Adrian Custer a écrit :
Hey all,
Does Firefox OS provide any way to uniquely identify a device?
Is this possible both at the UNIX level ('adb shell') and from within
app code (with suitable permission)?
What do you exactly want to do ?
At the lowest level, I want to use adb to query the connected device(s)
to obtain a unique identifier for that device. That way I can make a
backup directory that has an appropriate unique identifier even when a
hacker has multiple devices in hand.
While working on this, I realized that the issue was more general and
would eventually be faced by Firefox OS Web App authors so that we
therefore needed either an appropriate answer or a bug for future work.
It sounds like the bug is needed since the 'certified app only'
limitation will be an issue.
(At the higher level, I am working to fix and cleanup the 'B2G' project
and am working to extract the backup step (configure_device) from
build.sh into something separate and comprehensible.)
cheers,
~adrian
___
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Build error on mac: duplicate symbol __dyld_func_lookup
On 12/18/13, 3:02 PM, Benjamin Smedberg wrote: Does anyone recognize this error or how I would go about debugging the build? I'm not sure from the output here which makefile was being executed, and they all seem to hide the compile and link commands so there's not a clear record in the first place. --BDS Yeah, the monolithic builds sucks when you hit errors early, and on a Mac this is likely. This looks like the part of the build where it is building the Android tools that will run on the mac itself. (the output is to 'out/host/') These are things like 'adb' and 'fastboot' used to talk over usb to a device. These are not really needed for device builds and I suspect not for emulator builds. (It also looks like there is a lot of Eclipse being copied or built, probably for some other tool.) You may be able to blow past them by ignoring compiler errors. (Yes, this is terrible.) You can pass the '-i' flag to make, I think you can just add that to './build.sh -i' and it will get passed to make. Of course, errors later on will be ignored too. :-( It looks like make has some more subtle ways of moving past errors but I have not explored the various make flags. If you hit errors when it is outputing to 'out/target' then those will potentially affect your build. good luck, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] Fixing the list of Meetings and Calendar
hey all, The 'B2G' meetings are listed on: https://wiki.mozilla.org/B2G#Meetings which includes a link, at the bottom of the page, to a calendar: https://mail.mozilla.com/home/dietr...@mozilla.com/B2G%20Event%20Schedule.html Unfortunately, the list of meetings on the two sources are not the same, not even really comparable. It would be helpful if this could be clarified. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Twitter web/app constantly closes on Firefox Os 1.2 ZTE Open
On 12/14/13, 9:46 AM, Xes Garcia wrote: I know that this maybe not be an Firefox OS problem. But something is wrong with twitter on Firefox Os, it works fine on Firefox for Android and it kind of worked on previous Firefox Os versions Twitter is very popular and for a mobile Os to succeed is important to have twitter working fine. If I open twitter on the browser it closes too showing the :( no response screen Maybe the system is too sensitive about no responsive webs ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g Hey, Not sure *which* platform you are on. Does another app open when the Twitter app closes? I had Calendar opening periodically and killing my long-lived app. Seems the last app to open wins. If not, perhaps the twitter app is using too much memory. Does it take the home screen a while to load after the twitter app dies? That would indicate the app were consuming too much memory. But, it sounds like yet something else, this 'no responsive'sic? issue. No idea about that. ciao, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] A month dogfooding and dogcoding
Hello Andreas and the Mozilla phone team, Thanks for all the great work making the Boot to Gecko idea into the real phone I have in front of me! The real Firefox OS, for all the criticism I level below, is a fantastic platform for the future. The amount of work you have put in is huge so you all deserve a great thanks for pulling it off. Yet there is still a long way to go to turn the existing platform into a viable and vibrant system able to produce a great experience for users, a viable infrastructure (and business?) for developers, and a competitive alternative to the other phone systems. That's what this mail is about. Andreas, this is addressed to you since we met in Montevideo during the launch and I figure you might have input into the overall process. It is sent to the list as well since the individual comments about the apps might be of use to those writing the Gaia apps and might elicit other discussion. Users are the ultimate key to making the project a success. If users hate the platform, it is sunk; if they love it, they will leave room for the inevitable mistakes and errors made along the way. I worry for the users of 1.1. I doubt any of us is dogfooding v1.1; it is too painful. The clock app which only tells the time does not make any sense on a phone that gives you the time in the top right corner. The browser was not even up to the level of the early versions of Firefox for Android. Fortunately 1.2 is better all over. So we need to get users past 1.1 as quickly as possible. = Mozilla needs to publish the upgrade story. Mozilla should be putting out very clear signals about how those users will get to upgrade. If Mozilla moves past 1.3 and I am stuck on 1.1 and all I hear is ... nothing, I get frustrated. Even if upgrades are out of Mozilla's hands, Mozilla should be coordinating with the device manufactures and the telephone service provides to put out a very clear story on the situation. From the point of view of a frustrated user, they ought to see Mozilla on their side trying to get upgrades done, not as part of the problem. Which brings me to the User experience itself. I'm working from v1.2 because that's what I have on my phone today. The Browser - You all had the gall to call this thing 'Firefox OS' and then you come up with this browser! You all know perfectly well that phoenix was started to break away from the monolithic suite being pushed by Mozilla. Firefox (born phoenix) was a project started outside Mozilla which aimed to do one thing only and well, web browsing. That it eventually dominated the integrated suite pushed by Mozilla insiders should have prevented you from re-using the name for this insider driven, let's make the browser do everything project. But, you squatted the name anyhow. Well, now you better live up to the name! So make the browser great. I know you have great plans for the future but releasing this phone named after the browser with a browser this trivial was bad marketing. (Yeah, go ahead, try using the browser v1.1 for your browser needs for a day, I challenge you.) Do better, make this great now, it is in the phone's name. Okay, in v1.2 the browser is at least becoming 'painfully usable' but it ain't worthy of the Firefox name and reputation. The browser is not key to a phone, but you've taken the name so now you have to make it GREAT, and quickly. Phone - works well so far. Cool. The Clock - v1.2 adds the Alarm clock and a Timer. Great, now it is actually an app. The Alarm sounds leave a lot to be desired. Are any of you willing to be heard in a meeting emitting these sounds when the alarm goes off to remind you you have to go pick up your sister's kids? The alarm actually survives long term, unlike the timer which dies when opening another app (or two). That is actually dangerous, since an obvious use is timing things on the stove. Also, when I overcook my pasta because of a crummy Clock app, I blame the phone, which is exactly what we want to avoid. Contacts - It's starting to be usable. The backup to sdcard saved me lots of work when downgrading from v1.3 to v1.2 (which hosed the contacts and SMS messages for some reason). So, good. Adding a contact is less obvious. The UI is all backwards where I have to look deep into the block to know what it is about. Can any of you tell me what Perso... is going to be about? Oh, okay this is an email field, and it is preset to not be 'work' and has chosen something like 'Personal' as the text but doesn't fit. Having that 'Company' field as the second entry is irksome, suggests this has been developed by corporate land. Then in the phone number there is this 'Carrier' thing which is puzzling. In Belgium, France, and Uruguay, everyone knows the carriers by how the numbers start. In the
Re: [b2g] A month dogfooding and dogcoding
On 12/13/13, 11:31 AM, Chris Mills wrote: Hi Adrian, Thanks a lot for the detailed feedback! I think it is exactly this kind of constructive criticism that helps the most. Cheers. I am on the MDN team, and in charge of maintaining the Firefox OS doc zone. You can feel free to aim any doc-specific stuff at me. Okay. Nice to meet you. I’d like to request that some of the platform developers try to find some time to help me work out where our documentation is out of date and in need of fixing. I ran through all the build process docs about 2-3 months ago in detail, checked that it all works, and made a number of updates, but it may well be time to do that again ;-) Your new article is very useful[1]; I have linked to it from the main Firefox OS zone menu[2] and from the Building and installing sublanding page[3]. Oooh, no! It's not ready for that. Really, it needs a technical review first! You can't have someone (me) writing how the build works who has not successfully done a build and placed in on their device. Please revert. Also, once it is deemed reliable, it will need to get integrated into the various menus and sections: https://developer.mozilla.org/en-US/Firefox_OS Left Nav Menu [DONE] https://developer.mozilla.org/en-US/Firefox_OS Build ... Section https://developer.mozilla.org/en-US/Firefox_OS/Build_and_install Menu https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS Getting and ... Section You are lost in a maze of twisty pages, all alike... I also gave it an editorial review, fixing a bunch of minor grammar/spelling/structural issues. Thanks. Now I know how to make note blocks too. All the best, Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills [1] https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_build_overview [2] https://developer.mozilla.org/en-US/Firefox_OS [3] https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] The dev.moz.org docs
On 12/13/13, 1:00 PM, Chris Mills wrote: On 13 Dec 2013, at 14:51, Adrian Custer a...@pocz.org wrote: You are lost in a maze of twisty pages, all alike… This is definitely a thing I need to work on. There is a lot here, and it could use some improved IA. I kind of got to the point where I couldn’t see the wood for the trees with this section of the site, so I left it for a while and went on to other things. Again, any ideas will be listened to ;-) Do you have a higher level overview of the docs? The current organization seems kind of strange. When I was writing the Gnumeric Manual, I needed a clear outline just to keep my own mind clear of what goes where. We surely need something similar to all be on the same page when working collaboratively on a wiki. The current layout lacks a coherent logic. Working from the left-hand menu on: https://developer.mozilla.org/en-US/Firefox_OS (Note that right clicking on each top level element opens an extra page for that top level element.) Introduction: = Is this focused at everyone or just developers? A key question is who is tragetted by these docs and how can we redirect the other readers quickly to other docs. = Needs a clear purpose (ie. Hardware requirements is strange to find here.) Usage Tips: = These are tips for developers, i.e. not 'usage' Platform Guide: = Needs to start with a simple archi diagram: [ Gaia Web Apps ] [ Other Web Apps] [ Gecko ] [Gonk: kernel, drivers, libs ] = Needs to work systematically through the layers: * Kernel * Drivers and libs = Gonk * Gecko * Web App Security Control * Web App APIs = 'Gecko'? * Common libraries for Web Apps * Shared UI elements * Gaia Apps = 'Gaia'? = The FxOS startup process should be separate from describing the layers = The App Execution Environment (Apps Architecture) should be its own section. = Feature Support Chart had better happen after explaining that there are 3 Runtime Environments: Device, Emmulator, Desktop. Actually, that should be part of the initial 'Introduction'. = Settings list should be part of the 'Web App Environment' It is not related to the Platform. = Developer Settings should be part of the Web App Hacking Guide which is should be a separate section here but might be in a different part of the dev.moz.org site. They are not part of the 'Platform'. Build and Install: = we've talked about this. = installing on a mobile device should also explain about working with the AOSP tools: adb and fastboot. That is the Android tradition. Also, it makes more sense to work from full filesystem images than relying on the magic of ./flash.sh = Dual boot... should be part of a device specific discussion subsection. Hacking: = this is mixing working on the OS and working on apps Developer Phone Guide: = The initial section 'Firefox OS phones' is missing from the menu. ! That's where the device - codename mapping lives! = The sections should all be different phone names: Updating... is way too long a title. = Is this 'developer' phone or just a 'phone' guide? Once you root the phone, the Alcatel thing is just as much a developer phone as any other. = Troubleshooting should be an overview of Working with physical devices Release notes: = API support does not belong buried here. = App permission does not either. App Design and Development: = link broken when right-clicking on the title (goes to Release#) = This is a separate effort that will need organizing in its own right. All in all there is lots of material here. If it can be systematically organized, it provides a good scaffolding for the future. But someone, probably you, needs to come up with a coherent outline of the whole thing so it is clear to all what goes where. For example, the Introduction could be: Defn: FxOS is a lightweight OS that runs user applications in an HTML web page like environment. FxOS is designed to run on mobile devices like smartphones and tablets. Benefits: It's free software. It's a familar develop. environment. Mozilla provides help (ie docs, the store). It leverages Android so device makers know the basics and it can be widely ported. ?Overview of the OS: 3 layer view ?Overview of OS Execution Environment(s)? Devices, emulators... API ?Current status of use, deployments...? but that takes someone making a coherent outline of the whole thing. cheers, ~adrian ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
