When I run the following command meteor run android-device I app loads on the device, but I cannot login or perform any action, and I get the following error message :
I20160125-16:26:04.688(2) (android:http://meteor.local/:0) XMLHttpRequest cannot load http://192.168.20.41:3000/sockjs/info?cb=pp4d6iodxu. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://meteor.local' is therefore not allowed access. The response had HTTP status code 403.
My phone is in developer mode, and I'm debugging (or attempting to) via USB.
As I already mentioned, the app is loading, but I'm dead from there.
Try to add App.accessRule("*"); to /mobile-config.js
After trying a number of things, including setting up another demo app, multiple restarts, setting up browser policies and tons of access Rules etc, it finally began to work. The things I tried:
plenty of accessRules in the mobile config
Browser Policy Package with standard rules
temporarily setting environmental variables for root url etc.
So in order to figure out what specifically caused the issue I began to work backwards removing things, until I removed ALL OF IT. and then it still worked.
I have tried for two weeks to replicate the issue now, and everything is working smoothly. Putting this down to a random bug, in my system, there are definitely more than a few people that have hit it.
The only thing I think I could have missed is a package update, that patched some package in the dependency tree that caused the whole thing to bomb on mobile.
Related
I've seen plenty of ways of getting system logs in Android with logcat and the like, but not so much about app logs (except for the usual USB + adb solution).
My B2B Android app produces useful logging created with Log.i calls. Whilst in Studio these are very useful for debugging, it would also be useful to get these from customer's installs when things go wrong, i.e. from a release build out in the wild. Customers are generally not techies so getting logs via adb isn't really an option.
Is there a way within the app code itself to grab all the log contents?
Perhaps the SDK provides a way to do this?
I could then send that to my server or by email. I'm thinking it'll be useful for my customers to just hit a button so I can get an instantaneous snapshot of what is happening in the app.
Thanks in advance
UPDATE
There doesn't seem to be a way to do this, aside from writing to a file and sending that file. Which I guess is a good a solution as any.
Two other interesting ones that have come up are:
Firebase (from Mohammed's comment) - can log events:https://firebase.google.com/docs/analytics/android/events
Instabug
we can write write logs to file using java.util.logging.Logger API.
How to write logs in text file when using java.util.logging.Logger
Check out here for writting crash log to a file
My Android app is coming to the end. Debugging runs OK for many many times without any error. It runs just fine. It's the time for me to build a release and publish the app. I follow all the steps which can be found via Google easily. In fact the signed APK is installed OK and the app starts OK but if user interacts to navigate between screens of the app, it is crashed for no reason. Not all screen switching causes app crash, just some of them and I can notice that maybe it involves Reflection here. I design my own binding system to bind ViewModel behind with the Fragment and using Reflection is a must, no other way.
I totally believe that it is not any fault in my code because the app runs just fine in debug mode. And at the time of nearly completely losing all hope to publish the app, I found a signed version of the APK file in the debug folder (that signed version is generated only if you start debugging the app to run in some targeted device - even some emulator, building in Debug mode won't generate that file). It's very lucky for me that that signed apk works perfectly. I can deploy that APK to a new device and install normally, the app runs expectedly.
So it must be something wrong with the releasing process. Here is some info about configuration for Release mode (mainly in Android Options tab):
Packaging (Packaging properties): Nothing is checked in here.
Linker: I tried both Sdk assemblies only and Sdk and user assemblies but nothing works.
Advanced properties: I checked all options to support all possible CPU architectures (this should not be a problem because in debug mode, all these options are also checked).
At the beginning of learning Xamarin Android, I tried finding information about publishing Android app and did complete a simple test (to deploy a simple app). It worked OK at that time (maybe because it's too simple), but now when it comes to a complex one (mainly involving my binding system which uses reflection heavily) it can be crashed at some user interactions. I also have a separate library project (containing some custom Views) referenced OK in my main project (not sure if that could be a break, however one custom view is used OK while some others may cause crashing). Because all the crashes happen in a compiled build, I cannot debug anything to see what could be wrong.
No code is provided here because there is too much code, it seems to be crashed at many places and one more important reason is the code should not be the problem (for one reason I explained above - it just runs smoothly in debug mode, I even found a signed APK file in debug folder which can be installed OK and the app then runs just OK like in debug mode).
Since you stated you are using a lot of reflection, the first thing to do is:
In the Android Build Settings:
Disable Proguard if it selected
Change the Linker Options to Don't Link
Rebuild a release build
Update: Since this worked and the app no longer crashes.
The linker will sometimes remove code that you want to preserve.
For example:
You will need to determine what classes and/or method are being remove because that have no direct references and are only called via reflection and preserve those to prevent the linker from removing them.
If they are in your code, you can use the [Preserve] attribute.
If they are 3rd party libs or the Xamarin.Android framework, you can create a "hardcoded" fake reference to those classes/members so the linker sees that you need them.
You might have code that you call dynamically via System.Reflection.MemberInfo.Invoke.
If you instantiate types dynamically, you may want to preserve the default constructor of your types.
If you use XML serialization, you may want to preserve the properties of your types.
Ref: https://developer.xamarin.com/guides/android/advanced_topics/linking/
Here is my issue, I am using Bootstrap (twbs:bootstrap), font-awesome (natestrauser:font-awesome) and Avatar (utilities:avatar).
When I load my application in a desktop browser, all assets load fine.
When I load my application in a mobile browser, all assets load fine.
But when I load my application in the compiled (Android) app, font-awesome and Avatar don't load their assets. The reason I am targeting them is they are both reliant on contacting outside sources. font-awesome is served off of a CDN and Avatar retrieves avatars from social networks. I know I can package font-awesome but I can't do the same for avatars so I need to figure this out.
I have looked to see if Meteor does something odd like sandboxing the app to prevent outside contact but I can't seem to find any mention of these kinds of issues. Is there a default security settings that I can set where it would allow my app to 'contact' whitelisted sites? It would be absurd but it is Meteor after all.
I figure someone more knowledgeable in Meteor can point out my error.
There is no code for font-awesome (besides using CSS classes) and there is really no specific code for Avatar besides {{> avatar ... }}
Thank you in advance!
Note, as of 5/30/2017: Please skip to EDIT 2 below unless you want to read the very long and confusing ramblings of my former self. Thank you.
Okay, I was right but not necessarily right about who was causing what (I was kind of right). The reasoning behind it makes sense so I am thankful for that.
Here is what I've determined. Cordova has a whitelist under /res/config.xml where URLs are whitelisted and only those URLs are the only URLs allowed outside of the application.
But, if you try to edit config.xml it will be overwritten by Meteor on build which indicates this config is governed / overwritten by Meteor.
I searched around and found a few things: Meteor / Cordova, Meteor. The second article gives the solution. You must use the package browser-policy to whitelist what URLs you want.
After installing browser-policy, you must include them in a file in /server. I tried installing them inside a if(Meteor.isServer) block outside of /server but it didn't work.
Hope this helped! I couldn't find anything similar to this and I presume others will run into this road block as well
EDIT: This will only fix it for desktop. For my issue, I had to create a top-level file called mobile-config.js and use config settings from this page to whitelist URLs. This change happened in Meteor 1.0.4
EDIT 2:
Here is it said more clearly: You must whitelist all outside URLs that you want to contact inside of mobile-config.js
For instance, if you want to contact google.com from your mobile app, you would add
App.accessRule('https://www.google.com')
Thankfully Meteor has fixed their extreme documentation issue and has now included this on the official documentation here
I'm having a problem where an app I'm developing is working on mobile devices (tested on 4 different devices), but crashing when I try to test it on my tablet. The tablet I'm using is a Tesco Hudl 2, which, although being a good quality low cost device, lacks adb drivers and so you can't debug apps through USB and get the Logcat data. The app was developed using Android Studio.
With other apps I have developed, I have just set up ACRA in the project so I can still get debug information from a crash. This time however, the app is crashing without any information from ACRA and so I'm not quite sure what is going wrong. I'm pretty sure I've set up ACRA correctly given that I've used it in several projects before and see nothing wrong this time. Can it be that whatever is going wrong is happening too early for ACRA to catch?
I have pulled out all the code from the activity so the only thing that happens in code is that ACRA gets initialized in the derived Application class (note that the crash exists without ACRA). The app also uses Google maps and a provider for search suggestions. If there is any code anyone wants to see just ask, but I'm unsure what exactly to post up since everything else was stripped out. So, does anyone have any idea on what I can do to solve this, or what tools I can use to catch whatever sort of errors happen so early in the apps lifecycle?
Thanks
Update with strange behaviour... Downloaded Crashlytics and it also did not catch the crash. I copied the project and removed every .java file except the Application, Activity and provider. The provider functions were empty (save for the return value of 0/false/null/whatever), the application class just initialized Crashlyitcs and the Activity class was empty. This then worked, I was even able to add in a lot of the code and get the google map to load.
Now if I do the same in my main project, except don't delete the .java files, the crash still happens. The classes in these files are not used so I have no idea how they can be causing the crash. Otherwise all the xml, gradle, resources are identical (except the package and app name). Very confusing...
Consider using one of the apps to view logcat on the device:
https://play.google.com/store/apps/details?id=com.nolanlawson.logcat
https://play.google.com/store/apps/details?id=org.jtb.alogcat
Also try using Crashlytics. Maybe it will catch your crash?
But yeah, it's possible to have a crash before any crash reporter (ACRA or Crashlytics) will have a chance to catch it.
And one more note, maybe there is a way to enabled ADB over WiFi.
Normally you would need to enable it via adb but maybe in case of this cheap and strange tablet, there is an option for that enabled in the ROM?
Ok! So it's 1am and I decided to have one final attempt to fix, which I think I did. In my manifest, I had things like
<activity
android:name=".MyActivity"
...
for example, and while this worked fine on the mobiles, for some reason the Hudl required the complete package name, i.e. com.mypackage.MyActivity. Not sure why this is the case but it appears to have fixed the problem.
Sorry for the newbie question, but I spent the whole day trying to figure out why the target list remains empty.
This is what I've done so far:
Launched the Weinre host, bounded to my desktop ip adress
(192.168.0.38)
Checked it on Chrome : the host is bounded to
192.68.0.38:8080
Checked that the device is able to access to 192.168.0.38:8080/target/target-script-min.js#anonymous
White-listed both 192.168.0.38:8080 and 192.168.0.38 in config.xml
Added the script call in the index.html
Still the target list remains empty when I launch the app on the device from ADT...
What should I do next?
Thanks!
___ EDIT
I tried the demo, and it's working!
So what makes the difference between calling the script from a demo file, or from the application?
Turns out for me, the problem was that the mobile device silently switched over to another Wi-Fi network (than the one my computer was on), thus rendering the Weinre JS Script unreachable from within the app.
It's different than the issue described above (since, for Yako, the example scripts were working fine), but thought it could help somebody someday.
My issue was that I kept trying to access a page anchor. Apparently that doesn't work too well so I have to load the page first with no anchor, then add the anchor separately.
Finally, it's working!
It seems I only had to wait a little bit after app initalization!??
For all of you who still have to use weinre and have the same problem, I just want to share my mistake:
I did not whitelist my IP-address in the config.xml
maybe some of you have the same mistake.