Related
Hello all,
I'm currently trying to develop an Android app as part of my final year of university (I would have posted this is development but I'm too new ) and I'm using my Dell Streak as the main testing device as, lets be honest, it rocks and I'm too poor to get another device. I'm running DJ_Steves Streakdroid 1.9.1 custom rom as the Android platform.
The app itself requires the usage of some sort of mapping API, and I would prefer to use the Google maps API as it has all the features I require and with it being built into a significant number of Android devices it would reach the widest range of devices whilst retaining the necessary simplicity due to being built into the SDK and ADT plugin. However when attempting to run a basic app prototype that displays a map centred on the last recorded GPS location, I run into a classDefNotFoundError every time I try to run it, indicating that the API does not exist on the device. This leads me on to a selection of questions I'd like to ask if anyone knows the answers to:
Do any of the Streakdroid versions have the maps API?
Do any other custom roms have the maps API?
Is the maps API included in the stock Froyo release?
Hey everyone, my name is Ian. I'm kind of new here, at least in a participatory role as wiki master of the Photon 4g's Sunfire dev team/collaboration. I have some talent in the world of web coding, but I'm useless at real programming.
I also have a rather nasty addiction to the world of flight simming, mostly as stand in for real flight time that I'm trying to orchestrate as I work towards a private pilot's license. Anyways, my program I use for flight simulation is X-plane and lacks in 3rd party applications that it can interface with, especially on the Android side. I would like to help to put together an Android app that can work with the sim and control basic functions. My current goal is to control radio systems and autopilot functions. To interface with the sim, I plan to use the Simulator Control System which is based on the CAN Aerospace protocol. This is cross sim application, so whatever works with X-plane will also work with Microsoft flight sim. I've been looking at the website, http://cross-simulator.com/, and I think that this seems like a fairly easy task. All the functions and commands are well documented and supported (there is even an example android code), I just don't know how to start. If anyone in this great community has some advice, I'd love to hear it because I really have no clue.
Thanks, and happy dev'ing
I would just download the example, import it in Eclipse and run it on the Android emulator (assuming you have downloaded and installed the Android SDK). Later, you can tweak the example code as you become more comfortable.
maybe either through API level, or by querying market info
Reason: i want to check on GB before I upgrade to ICS, which apps will not work.
don't know if relevant but it is for SGS II
Thx in advance
repost from here as nobody could really answer my question
can't believe I'm the only one with that issue
maybe an idea for a dev? would be willing to pay for that ;-)
I don't see why this can't be done:
-http://stackoverflow.com/questions/2695746/how-to-get-a-list-of-installed-android-applications-and-pick-one-to-run
-http://developer.android.com/reference/android/content/pm/PackageManager.html
-http://developer.android.com/reference/android/content/Context.html#getApplicationInfo()
I haven't thought through the problem just yet, but its seems to be doable. If you don't find an app soon, I will start working on a script that does it and, if successful, a proper, free software app. I am hoping the available methods won't require something as stupid as launching each app fully. But again, I haven't thought it through. Thanks for the idea btw.
EDIT:
Made a little more effort
https://groups.google.com/forum/?hl=en&fromgroups#!topic/android-developers/dXLACRIizKc
I will work on something this weekend and get back with y'all.
EDIT 2:
So it looks like I would need maxSdkVersion which I don't find in the API. Furthermore, it is strongly suggested that one not use maxSdkVersion when building an app so that doesn't sound all that useful. I have received another, much more complicated suggestion that may do what I want, but I will have to look hard at it. Looks like I'm going nowhere in my effort. Always open to suggestions. More to come later this weekend.
I'm not the sharpest tool in the shed, but I thought this was mostly a straightforward task using the API's exposure to AndroidManifest.xml. As per my previously posted link to an Android Developers discussion on the topic, my approach is dead in the water as far as I can see. I did try to find an answer though to the best of my limited ability. If anyone has or ever solves this problem (I consider it a problem) I would hope they find the this thread.
Thanks for the learning experience. I give up.
Most older apps will work fine on ICS, its pretty backwards compatible. If the app uses legacy menus the button will appear in the old lower left hand corner location instead of the upper right hand corner like apps written for ICS.
i'm no dev so bear with me if i write stupid stuff
one likely but not very promising sounding way might be to use android:targetSdkVersion as "As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens)."
question though is how many apps actually use this?
However after having read this re android:maxSdkVersion "Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute." (taking from here) i now don't know how important my op is, but then why do all app devs release new versions "fixing things" for ICS?
One pretty significant example which actually currently will prevent my phone from getting ICS for now is that the subsonic app in the current version produces stuttering when playing audio while downloading (problem description here).
Isn't there any way to instead of searching the phone searching google play/android market instead?
Randi said:
maybe either through API level, or by querying market info
Reason: i want to check on GB before I upgrade to ICS, which apps will not work.
don't know if relevant but it is for SGS II
Thx in advance
repost from here as nobody could really answer my question
Click to expand...
Click to collapse
Here's a list of some working games/apps for ICS
Theoretically an Android app (or a combo of say App Engine and Android) could find your installed apps, seacrh Play for said apps and then scrape the page for relevant information. Doesn't sound to hard, but I didn't think about too hard either. Perhaps I will check out what useful info is on Play and how feasible scraping its markup will be. I will get back at y'all if I do.
Maps Tool - new free app (with no ads either) to work with gps coordinate, maps and grids, including public land survey system (township, range, section)!
Do you happen to own some real paper maps? If so, my new app is designed exactly to make using them simpler. Or maybe you are just interested to learn something about geodesy, navigation and cartography? If so – read on.
While most online and other digital maps are now standardized around using decimal degrees latitude/longitude pairs using WGS84 geodesic datum, paper maps are not so simple. They use all kinds of different coordinate system. Many use UTM – Universal Transverse Mercator coordinate system that was developed by the United States Army Corps of Engineers in the 1940s. NATO militaries around the world wanted their own thing and developed another grid coordinate system called MGRS. While these two are most popular there are many more other grids, especially once we go to local level. Maps in UK often use something called Ordinance Survey National Grid (OSGB) while Ireland had to use yet another system called Irish Grid.
To make things even more complicated years before recent standardization around WGS84, maps often used other geodesic datum, based on different models of earth ellipsoid and measurements. In fact many historic reference earth ellipsoids are still used in local areas, since they may provide better accuracy of measurements in certain territories. In practice this means that getting coordinates assuming wrong datum can put you hundreds of meters away.
Maps Tool is a powerful app that allows you to convert data between many coordinate system representations and also adjust for various datum. This app currently supports lat/lng, UTM, MGRS, Earth-centered, Earth-fixed Cartesian coordinate system, Swedish Grid, Ordnance Survey of Great Britain and Irish National Grid and many different geodetic datums, including, but not limited to: WGS 84, NAD 27, ED 50, ETRF 89, OSGB 36, OSI 65, RT 90, SWEREF 99, SIRGAS 2000, SAD 69, Córrego Alegre, SICAD, Astro Chuá and SK 42.
By default Maps Tool uses offline HERE+ maps already stored on your phone, but can also use Bing Maps, Google Maps, and OpenStreetMaps for better coverage. Overlays such as topographic map and satellite imagery are also available. Other handy function of Maps Tool include geocoding (finding location by address) and reverse geocoding (find closest address for a given location), sharing your location via sms/email and build-in database of around 3000 major cities and 9000 world airports for quick access (you can just key in a 3-letter IATA or 4-letter ICAO code).
Using web service from BLM (Bureau of Land Management) Maps Tool also gives you access to PLSS (Public Land Survey System) information (township, range, section) as a convenient map overlay (you can search for parcels by TRS or view parcels around you by tapping on the map).
Last but not least, Maps Tool app allows you to see rough altitude information from the GPS module in your phone, or (available as an optional download) query various GIS systems for accurate topographical altitude information including currently supported: USGS (US only), SRTM3, GTOPO30, ASTER and Google.
Best of all this app does not require a data connection to work, so you can take it with you into the field.
It is currently translated to English, Russian and Japanese and if you can help with more languages - please let me know.
Here is the store link:
http://www.windowsphone.com/s?appid=4bf54046-e1a3-4140-9f6f-7516948a5d29
I own a JFLTEVZW i545, but I understand that this affects other variants as well.
I'm not a developer, but in the last 4 weeks or so, I've been trying to learn more about android, linux, and kernels. Hopefully what I've come up with can be attempted by someone with a more advanced skill set, because although I've had what appears to be success in attempted fixes, I really don't know if I'm implementing the changes appropriately because I don't see the appropriate fix. I'm also wasting many, MANY hours (200-300?) learning, tinkering, and waiting on compiling because I'm not skilled enough to make a quick change that I want, or to implement that change easily, without a complete recompile (which costs me 2 hours each time). Someone who is more knowledgeable with kernels and building/compiling from source could probably do everything I'm doing in 1%, or less, of the time that I'm doing it.
Core issue:
The magnetometer's X and Z axes are off 180degrees. This has been a consistent issue since early/mid 2014 builds in both CM11 and CM12, as well as CM12.1 (as of a few days ago when I last tested). This causes problems with navigation and multiple user apps.
Ways to experience the issue:
If you aren't familiar with this bug, or if you're of the opinion that the compass doesn't have any problems, fire up google sky and you'll see that things are wonky when the phone flips around crazily and none of the constellations, planets, or moon are where they should be via the augmented reality. This app is NOT incompatible--the data it's being fed is erroneous.
Alternatively, you can use Physics Toolbox Sensor Suite to view the true raw data (other sensor apps are either adulterated or show false or useless data). With this, the sections I've found most worth looking at are the Linear Accelerometer, Magnetometer, and Orientation, and you can compare the data to an OEM phone if you have another one handy.
For the magnetometer, I've found that the absolute best way to calibrate it is by performing a figure-8 movement in three-dimensional space, rather than two-dimensional as shown in some apps and videos, or by the method mentioned in GPS Status & Toolbox. See this video for an example. I perform a larger figure-8 and do it multiple times--once can work, but a few times really settles it down.
What aren't contributing factors:
Calibration
Hardware malfunction (many others have confirmed)
App malfunction
Magnetometer driver source code (note: the code itself in the files I've looked at are the same as Samsung's source, but the way in which it's implemented may not be)
Please keep in mind that because I'm very new to this, I don't have instant intuitive feedback to know how to confirm these things in the contributing factors or possible solutions. I really need to pass the reigns on this one to someone much more advanced than myself, who will see this post and churn out the fix in a half hour.
Possible contributing factors (could be more than this):
Driver implementation. The source in /kernel/samsung/jf/drivers/sensors/ is new, and OEM, but I don't see it compiling.
Driver implementation. I'm having difficulty knowing which source files from Samsung need to be dropped in to try and compile a kernel without CM modifications which pertain to the sensors. I also have significant difficulty knowing if it succeeded, correctly, rather than something in CM taking over and undoing my changes. This is the case for one particular thing, so I have no idea how to confirm the things that I can't readily see.
Sensor(s) orientation configuration(s).
Possible solutions:
Should /kernel/samsung/jf/drivers/sensors/ actually be compiling? I don't think it is (because I don't see the folder), or even know if it's necessary for our phones, but Samsung has it in their source and I cannot successfully compile Samsung source to try and compare. I also don't know if it gets merged in with other files somewhere else.
Dropping in all OEM necessary files and compiling, without CM interrupting. I don't understand linux and the filesystem enough to know what happens when, and I've resorted to using shred/srm to try and truly delete files, but I still struggle with understanding what's going on. I also don't know what encompasses a swap like this. I don't know if replacing sensorhub is all that needs to be done or if there are 3 other files in completely different directories that are critical, and must overwrite the CM modifications for things to compile appropriately.
Setting sensor orientation correctly with CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=0, CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=0, CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=0 being different values than zero.
I've tried the first two and had intermittent success. Sometimes things compile, sometimes they don't. But I also don't know if what I'm changing even matters. I've been checking file hashes to see when things change, but it's becoming tedious and someone who knows all of the linux commands and knows how the source gets compiled would know without having to check.
My favorite possible solution is the third. This is in the .config file which is made by the make menuconfig process, which I believe is influenced by various defcofig files. I've tried changing the .config directly, but CM undoes that. I've tried adding those lines to the defconfig files, but CM either undoes or ignores that. I've tried compiling a kernel outside of compiling CM as a whole and am hitting roadblocks with my lack of experience and knowledge. I've successfully compiled kernels, but I don't even know if my changes are sticking. I've taken what I though may have been an appropriately compiled kernel (Image and zImage) by modifying the .config and then manually doing a make zImage, but even dropping those in to compile with CM, chmod 555, chown/chgrp root and CM somehow manages to overwrite the renamed zImage-->kernel file, but it would actually leave them alone when I did all that nonsense to the Image and zImage in their normal output spot, /arch/arm/boot/kernel/ I believe.
The third possible solution sets how the sensors are physically placed within the phone. If the readings are off by right-angles, it seems that a coding change for one or more of these would be appropriate:
CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=0
CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=0
CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=0
I've had no success in making this happen, but as I said, someone who is a genuine programmer would be able to make these things happen and compile and test quickly...rather than me spend an entire day trying 20 different ways to see if I can get something to stick, and then not even being able to confirm if what I changed, actually made its way into the final compiled files.
Hopefully someone is willing to take a stab at this, because I'm apparently the equivalent of an elderly person having their first encounter with a computer when it comes to this stuff. It seems so simple, but I'm not the one to make it happen, and I feel like this may be the route to take. Thanks, y'all!
EDIT: I've tried other methods to make this work that I didn't list, I just can't remember everything and my mind is breaking down after going at this for about 13 hours straight today.
I suppose you own a Verizon phone, the unique with Compass issue. I'm currently helping jfltevzw guys to find a fix, and still nothing real even after some tries...
Already tried to change magnetometer physical angle (the correct value must be 3 or 5 according to board-jf_vzw), but if you think: even in CM10.2 the MAGNETOMETER_POSITION was 0
I'm going to try some other things...
Sorry, yes, I own a JFLTEVZW
What are your thoughts on the new "sensors" source folder and it seemingly not being compiled/built? The \Kernel\drivers\sensors\geomagnetic\Kconfig has a completely separate orientation reference of INPUT_YAS_MAGNETOMETER_POSITION:
Code:
#
# Copyright (c) 2010 Yamaha Corporation
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
# USA.
#
config INPUT_YAS_MAGNETOMETER
tristate "YAS Geomagnetic Sensor"
depends on I2C
config YAS_MAG_DRIVER_YAS532
tristate "YAS Geomagnetic Sensor - yas532"
depends on I2C
help
Say Y here if you want support for the yas532 sensor
device.
To compile this driver as a module, choose M here: the
module will be called yas532.
config INPUT_YAS_MAGNETOMETER_POSITION
int "YAS Geomagnetic Sensor Mounting Position on Board"
depends on INPUT_YAS_MAGNETOMETER
default "0"
help
Chip mounting position (pin 1).
0: top, upper-left
1: top, upper-right
2: top, lower-right
3: top, lower-left
4: bottom, upper-left
5: bottom, upper-right
6: bottom, lower-right
7: bottom, lower-left
This is one of the points where I get stuck, because even if I can forcefully input a different number and reference, I don't know how to reverse engineer and get the pseudo-code (or how to read it) to confirm that what I input actually made it into the kernel. I want to confirm one of two things:
1) The change made it into the kernel successfully, and there is proof of that, yet the magnetometer data is not fixed, or
2) The change cannot be confirmed that it made it into the kernel successfully, with proof, so things such as this are still viable options.
Side note:
Samsung is also using this driver setup for their new "wear" devices. Both sensors and sensorhub source folders, for the same YAS532 (YAS532B is the same chip from my research, it's akin to calling the phone the s4 or galaxy s4). This source code change was made without any hardware change to our phones, so that why I wonder if something is awry and something completely unexpected and seemingly unrelated, on first glance, is expecting the sensors source folder to be compiled, but it isn't.
jfltevzw compass now works on CM
Feel free to donate to invisiblek as part of the bounty
Heh, I saw that commit and was tinkering around before sunrise today--very excited!
Hi there everyone -
I am running an AOSP / CM12.1 / Lollipop 5.1 ROM (Fusion) with KT Kernel. IT's a Sprint variant and I, too have the Compass / magnetometer bug. North points south / east points west. Maddening. Everything else in the ROM is Really wonderful, but without the compass / GPS / Maps, it's a deal breaker for me.
My last ROM - GPE on this forum had NO issues with the compass, so I am assuming that it is either the Kernel, or the ROM, or some odd combo.
If anyone else has any other info, please let me know? Thanks in advance!