API request 404 (from cache) on Android device

#1

I’m updating an existing app with a few bugfixes and attempting to get it ready for iphone x, but with the latest code I’m seeing a weird behavior on my android test device. On the device every call to the API fails. Inspecting with the chrome debugger shows it’s resulting in a 404 which it says is from cache. This doesn’t happen on ios or the browser, those hit the API just fine. Nothing has changed with the API code or the server availability, there’s no reason it should 404.

I have tested this with 2 different devices, so it’s not an issue of a quirky single device, and reinstalling the current version from google play work fine. So it’s something new and specific to android. The code for the API calls has not changed. Any ideas on what I can do?

Ionic Info:

cli packages: (/Users/mbeckett/sites/apps/wtm/node_modules)

    @ionic/cli-utils  : 1.15.1
    ionic (Ionic CLI) : 3.15.1

global packages:

    cordova (Cordova CLI) : 7.1.0

local packages:

    @ionic/app-scripts : 3.0.1
    Cordova Platforms  : android 5.1.1 ios 4.5.2
    Ionic Framework    : ionic-angular 3.7.1

System:

    ios-deploy : 1.9.2
    ios-sim    : 5.0.3
    Node       : v6.11.0
    npm        : 3.10.10
    OS         : macOS Sierra
    Xcode      : Xcode 9.0.1 Build version 9A1004

Environment Variables:

    ANDROID_HOME : not set

Misc:

    backend : legacy

API http call:

import { Http, Headers } from '@angular/http';
import 'rxjs/add/operator/map';
import 'rxjs/add/operator/timeout';

...

this.http.post(path, postVars, { headers: _headers })
   .timeout(8000)
   .map(res => res.json())
   .subscribe(
        (data) => {

            if (data.status === 0) {
                  resolve(data.result);
                  return;
            }

            if (data.hasOwnProperty('message') && data.message == 'pam_auth_userpass:failed') {
                // we are no longer logged in
                // lets broadcast an event
               this.events.publish('Elgg:AuthFail');
            }

            reject(data);
         },
         (error) => {
              reject({ status: -1, message: 'ElggAPIException' });
         }
  );

Http version: “@angular/http”: “4.4.3”

Any ideas?

#2

Update:

I have tried using HttpClient from angular/common/http instead - same result
I’ve tried removing xwalk (assumed a different webview would act differently with regards to a cache) - same result

I’m quite stuck at the moment. Any other ideas would be appreciated.

#3

What happens if you add a useless param to the URL?

#4

I have also tried that, added a timestamp to each request - still getting a 404 from cache (which seems impossible with the timestamp)

1 Like
#5

This may be permission related. Try removing and re-adding the cordova-plugin-whitelist:

cordova plugin add cordova-plugin-whitelist

If that isn’t working, then it would be worth checking the Content Security Policy (does it include permission to call that target URL) and config.xml setting for allow-navigation.

Is this impacting all HTTP calls to that server? It may also be worth checking / sharing the AndroidManifest.xml file (should include ).

Related post Status Code:404 Not Found (from disk cache) on Android device only

2 Likes
#6

Thanks @thmclellan - while not the exact fix, it was close enough to get me there. The whitelist plugin was listed in package.json and config.xml, but I guess somehow during the upgrade it was removed from the platform. Adding it back didn’t directly fix it, I ended up upgrading a bunch of plugins and the android platform itself and jumping through some dependency hoops, but now it’s working.

2 Likes
#7

Glad to hear you fixed it! It’s so easy to lose time on plugin troubleshooting, hopefully it gets a lot easier next year when Ionic Pro is ready

#8

if you are getting the issue with the white list plugin, you can try remove and add the plugin again, it solved.

 cordova plugin remove cordova-plugin-whitelist
 cordova plugin add cordova-plugin-whitelist
2 Likes
#9

I have also got same type of problem but unable to solve

#10

@govindappaarun,
c’est la bonne réponse .
merci infiniment