App service dies, help me find possible cause

[mrklos]

Im using Continuous Running app service -> https://docs.zepp.com/docs/guides/framework/device/app-service/

Inside it, in 1 min loop it does (in promise chain):

1. Fetch settings (Once per 5 min, return cache otherwise)
2. Api call to fetch glucose data from web (always do call)
3. store data to text file (using writeFileSync, readFileSync )
4. parse data / do model logic
5. send notification / start vibration based on logic

AppService looks like this:

AppService(
  BasePage({
    onInit(_) {
      const monitor = createGlucoseMonitor();
      this.monitor = monitor;
      monitor.start(this);
    },
    onEvent(e) {
      logger.log(`onEvent`);
      const params = parseQuery(e);
      if (params.action === 'dismiss') {
        sendDebugNotification("AppService", `onEvent canceling alert`, this.monitor.state.settings);
        logger.log(`onEvent canceling alert`);
        this.monitor.resetActiveAlerts();
      }
    },
    onDestroy() {
    }
  })
);

and Main loop looks like this:

  function start(vm) {
    timeSensor.onPerMinute(() => {
      getSettings(vm)
        .then(() => apiManager.getGlucose(vm))
        .then((glucoseData) => {
          updateGlucoseStorage(glucoseData);
          alertManager.handleGlucoseAlerts(glucoseData.glucoseMeasurement);
        })
        .then(() => {
          vibrationManager.handleTimerTick();
        })
        .catch((error) => {
          sendErrorNotification("AppService", `fatalerror ${error}`);
          logger.log(`fatalerror ${error}`);
        });
    });
  }

For some reason loop works fine for some debuging period of time, but when i go sleep with it turned on, it fails to work in nighttime, later on morning it looks like whole appService is dead, and i didn't get any error notification nor systme log inside zepp app.
What might be a possible case?

In documentation there's "The "App Service" will exit only when the exit service API is actively called or when system-related restrictions are triggered."
What kind of restrictions might kill my service? Is there a way to better log possible cause?

[SashaCX75]

I am having a similar problem. My application is receiving data from the internet. During the day it usually works fine. But at night the data is not updated. I attribute this to the fact that at night the phone does not see user activity and limits background processes. Usually after that in the morning the service works normally, but not always.

[mrklos]

After some testing (Thanks to new alert) It looks like app-service goes down when bluetooth disconnects, and app-service tries to do web request (Every 1 min). AppService then will go dark, and won't restart or after bluetooth is connected. Only way to get it running then is to open Zepp-app on ios phone, and then kill/start app service again.

@MyoungXUE Do you have some idea why it does happen? I'd assume that app-service would just throw some error if network request fails, but not die and be able to continue working in loop when bluetooth goes back online.

[T4ASICK]

Hi, I too have opened a discussion on this issue and have been experimenting. Completely similar situation - try to remove everything related to sleep in the code. I assume that when the user is asleep, the sensor/Sleep causes the AppService to stop.

[T4ASICK]

You can also try to stop sending if there is no bluetooth connection

import { connectStatus } from "@zos/ble";

  if (!connectStatus()) {
    appLogger.error(“Connection status check failed.”);
    return;
  }

[mrklos]

Thanks for suggestion about checking the status. It might be good idea as i still think that service dies as soon as i get error about bluetooth connection getting lost.
i'll update some code and go back to You with answers

[T4ASICK]

I got help from @SashaCX75 in the Discord channel — this advice turned out to be the key:

You can see how this approach works in one of his projects:

• [weather_alarm_service.js](https://github.com/SashaCX75/Weather-service/blob/main/app-service/weather_alarm_service.js) — structure of the app-service
• [settings.js](https://github.com/SashaCX75/Weather-service/blob/main/page/settings.js) — alarm configuration example

After applying this, my app started running 24/7 without interruption.

---

Key points from my implementation

In the app-service, make sure to define:

• onInit
• onEvent

And every exit point should call appService.exit() — including inside try/catch.

Example from app-service/background_service.js:

... Other code and funcs

AppService(
  BasePage({
    onEvent(e) {
      appLogger.log(`service onEvent(${e})`);
      try {
        sendMetrics(this);
        appService.exit();
      } catch (error) {
        appLogger.error(error);
        appService.exit();
      }
    },

    onInit(e) {
      appLogger.log(`service onInit(${e})`);
      try {
        sendMetrics(this);
        appService.exit();
      } catch (error) {
        appLogger.error(error);
        appService.exit();
      }
    },
  })
);

---

Alarm setup in page/index.js

import * as alarmMgr from "@zos/alarm"

const serviceFile = "app-service/background_service";

// other code and funcs

function startTimeService(vm) {
  console.log(`=== starting service: ${serviceFile} ===`);

  const alarms = alarmMgr.getAllAlarms();
  const biodataAlarmService = alarms.length === 1;

  if (!biodataAlarmService) {
    const option = {
      url: serviceFile,
      repeat_type: alarmMgr.REPEAT_MINUTE,
      repeat_period: 5,
      repeat_duration: 2,
      store: true,
      delay: 30,
    };
    console.log(`=== starting alarm: ${serviceFile} ===`);
    alarmMgr.set(option);
  }
}

// other code and funcs

[mrklos]

Thanks! After lot of changes i think im on right track thanks to Yours hints.

Side note for anyone trying to achieve the same: Use hints @T4ASICK provided, and then remember that ZML has some problems with app-service. Httprequest provided by zml tends to fail a lot. Better solution is to handle requests in app-side without counting on ZML and using request rather than httprequest. This tends to be more stable.