Android build not reaching the remote server



I have been working on a web/mobile app and am coming across an issue where the .apk fails to reach the remote server. I spent all night trying to figure it out, reading across various issues and posts, but haven’t had much luck.

Most notably: This one here: Built apps cannot connect to the given --server: they keep failing to connect

The app works fine on the web hosted on my D.O. droplet.

The Error:
When I open the mobile app (Android 5.1), "Oops, looks like there’s no route on the client or server for url: “http://localhost:12656/


  • iron:router (have also tried clinical:router, a fork of iron:router)
  • MUP Deployments
  • Nginx reverse proxies to support multiple instances per here
  • Build command: meteor build ../<build path> --server=myapp.domain:3001 (on the server, app is running 3001 and reverse proxy from 80.)
  • I have also tried meteor build ../<build path> --server=myapp.domain:80, but same failing results. Have also tried passing --server myapp.domain:3001 (or 80) but same failing results.

Also, don’t know if this makes a difference, but I’m using mdg:crosswalk. Have been signing and zipalign the android/project/build/outputs/apk/android-armv7-release-unsigned.apk file to download and install on my Android 5.1 device. I don’t think it would; not getting any build errors.

I’m a little confused, because my understanding is that passing in --server to the build command should set the ROOT_URL. But I’m seeing folks say they have had to manually set it in their app. I don’t believe anything is wrong with my cordova builds; if I look at the __meteor_runtime_config__ var, it’s properly indicating myapp.domain (and also it’s config’d in the "env" block of mup.json (below)).

__meteor_runtime_config__ = JSON.parse(decodeURIComponent("%7B%22meteorRelease%22%3A%22METEOR%401.3.4.1%22%2C%22ROOT_URL%22%3A%22http%3A%2F%2Fmyapp.domain%3A80%2F%22%2C%22ROOT_URL_PATH_PREFIX%22%3A%22%22%2C%22DDP_DEFAULT_CONNECTION_URL%22%3A%22http%3A%2F%2Fmyapp.domain%3A80%2F%22%2C%22autoupdateVersionCordova%22%3A%22a54d365fe6382ae7aa64b8f60975e0854f913873%22%2C%22appId%22%3A%221fzkqha1q75e1ooc32e6%22%2C%22meteorEnv%22%3A%7B%22NODE_ENV%22%3A%22production%22%2C%22TEST_METADATA%22%3A%22%7B%7D%22%7D%7D"));


<allow-navigation href="http://localhost" />
<access origin="*://myapp.domain" />```


    > {
    >   "servers": [
    >     {
    >       "host": "server.ip",
    >       "username": "ryan",
    >       "sshOptions" : { "port" : xxxxxx },
    >       "pem": "~/.ssh/id_rsa.pem"
    >     }
    >   ],
    >   "setupMongo": false,

    >   "setupNode": true,

    >   "nodeVersion": "0.10.43",

    >   "setupPhantom": true,

    >   "enableUploadProgressBar": true,

    >   "appName": "myApp",

    >   "app": ".",

    >   "env": {
    >     "ROOT_URL": "server.ip",
    >     "PORT" : 3001,
    >     "MONGO_URL" : "mongodb://nice:try@remote.db.ip:27017/myApp"
    >   },

    >   "deployCheckWaitTime": 15
    > }

blank, not passing anything in there.

I read in a guide that you'd want to specify your buildNumber, I've tried that with and without. Probably no big deal. (super basic while testing, nothing too important going on here){
  ```id: '',
  name: 'My App',
  description: 'A meter reading suite for Property Managers',
  author: 'myCompany, LLC',
  email: '',
  website: '',
  version: '1.0.0',
  buildNumber: '100'

**Nginx Server Block**
    ```server {
    	listen 80;```

    	server_name myapp.domain;

    	location / {
    	proxy_pass http://localhost:3001;
    	proxy_http_version 1.1;
    	proxy_set_header Upgrade $http_upgrade;
    	proxy_set_header Connection 'upgrade';
    	proxy_set_header Host $host;
    	proxy_cache_bypass $http_upgrade;


I'm considering switching from iron:router and migrating to flow:router to see if that makes a difference; but would prefer not to since I have a better level of comfort (and the app is reasonably built) around iron:router.

I'm wondering if it's because I'm doing a reverse proxy on the server, but I am limited in knowledge of how that works and if it'd affect DDP. Would trying the app directly on ```:80```, redeploying, and rebuilding make a difference? I'd prefer not to since I'd like to have this server as a multi-hosted environment.

Anyone have any thoughts or ideas? I'd love to get this figured out!

From looking around, I also tried:
```meteor update iron:middleware-stack``` -- [reference](
and, assigned a name to every route in my router.js. Still not working.

**Another Edit**
Ok, so I got to the point where I'm no longer getting router errors. 
- When I was first learning Meteor, a video course said to put your routes (router.js or whatever) in ```<app>/lib``` (also where I put my ```collections/``` dir)
- I moved my router.js into ```<app>/client/lib``` and the app will at least  launch without going straight to an error after the splash screen.

Still getting some bugs (sign-in not working, etc.) likely because of server/client code accessibility with the router now moved.

This became obvious because I decided to downgrade the app to Meteor version 1.2.1, and when I'd launch the 1.2.1 android app, it would say, "Oops, looks like there's no route on the client or server for url: 'http://meteor.local'", which gave me [some new things to look for](

**Can someone please clarify for me where a router.js with iron:router should belong, and if it in fact needs to be in /client for Cordova builds? Mobile apps won't work if it's in /lib?**

**Last Edit**
it seems like there's different thoughts on Meteor project file structure. Think I've got it all figured out now, thanks to [The Meteor Chef](


Took the day to learn Flow Router and make the switch – best decision I could have ever made with my early Meteor stages. Zero problems on mobile compared to web now.

A lot of the issues had to do with onBeforeAction and waitOn usage in iron router.

Make sure your router is in a client/server accessible location (like <project>/lib/router.js) and auth checks are on the client side (in my case, created some global client helpers for authInProcess, loggedIn, isAdmin, noAccess, etc.).

Flow Router also makes working with ground:db so much better in concept.