"Update" problem in the main activity xposed app on v2.6.1

Search This thread

RusherDude

Senior Member
Aug 24, 2012
2,013
623
I don't remember having this problem before, it only happens sometimes and with different results, it's very random.

Scenario A) When I open Xposed, it starts checking for updates and notifies me of every new update, if I go to the "Dowloads" activityand press the reload button, nothing new adds. <-- normal scenario, it always was like this before 2.6.1.

Scenario B) When I open Xposed, it starts checking for updates but doesn't find any new update (and doesn't give out any error, at least on a toast), when I enter the "Downloads" activity, and press the reload button, new updates appear..

Scenario C) When I open Xposed, nothing happens. It doesn't load ANY update or tried to get new ones, even if I had some updates pending to install before, it won't show anything until I enter the "Downloads" activity. There the updates to-do are like normal and pressing reload gets new ones.

Also, I noticed that from 2.6.1 is when I started choosing specific update configuration for some of the modules only (global is STABLE and for some apps EXPERIMENTAL now).

This doesn't only happens to modules, today I had an scenario B when after entering the "Downloads" activity and pressing reload, I got notified of the new Xposed experimental1 update..

I didn't do the "all modules disabled" test because since this is very random and I rarely find updates for my mods, It would mean having xposed disabled maybe for hours/days which sucks :(
 

rovo89

Senior Recognized Developer
Jan 4, 2012
2,585
81,433
Updates from the repository are only refreshed every 24 hours. The downloaded repo.xml is kept in the cache and still needs to be loaded every time the app is started - unless the app was still in the memory.

So the different situations can be explained like this:
A) The last refresh was more than a day ago, so the installer first downloads the new XML, then loads it.
B) The last refresh was less than a day ago, so the installer just loads the cached XML. When you press the refresh button, the 24 hour limit is ignored, so you see new updates.
C) The app might still have been running in the background, so no refresh was necessary. Or maybe you have cleared the cache, so nothing was downloaded and the XML to load was empty.

It isn't really worth looking into this in more detail as 2.7 experimental1 handles downloads quite differently.
 
  • Like
Reactions: RusherDude

RusherDude

Senior Member
Aug 24, 2012
2,013
623
Updates from the repository are only refreshed every 24 hours. The downloaded repo.xml is kept in the cache and still needs to be loaded every time the app is started - unless the app was still in the memory.

So the different situations can be explained like this:
A) The last refresh was more than a day ago, so the installer first downloads the new XML, then loads it.
B) The last refresh was less than a day ago, so the installer just loads the cached XML. When you press the refresh button, the 24 hour limit is ignored, so you see new updates.
C) The app might still have been running in the background, so no refresh was necessary. Or maybe you have cleared the cache, so nothing was downloaded and the XML to load was empty.

It isn't really worth looking into this in more detail as 2.7 experimental1 handles downloads quite differently.

That explains a lot. However, doesn't fully explains the C scenario, since on it, the main activity doesn't show all the "pending to install but already notified (in green letters) updates", it doesn't show anything, not even any module or download on any of the activities (forgot to mention this), hitting the reload button fixes everything tho.

The question is.. why does the system works like this? Why it has to be that "manual"? (I spend the entire day pressing the reload button lol). Why it couldn't just check for updates everytime the app was loaded / everytime the main activity was opened / or even without the app opened, in the background. Maybe bandwith? not sure otherwise :(

If the system is changing in the next version (and for now in experimental), yeah we'd be losing time checking there. How does the new system works? does it do anything of the ideas I said just above? I'd love to test it, but im not moving from STABLE releases of xposed, it is way important for me :good:

Thanks a lot for your fast reply!!
 

rovo89

Senior Recognized Developer
Jan 4, 2012
2,585
81,433
That explains a lot. However, doesn't fully explains the C scenario, since on it, the main activity doesn't show all the "pending to install but already notified (in green letters) updates", it doesn't show anything, not even any module or download on any of the activities (forgot to mention this), hitting the reload button fixes everything tho.

That's really strange, not intended and I never had that situation. Do you have an app that constantly clears the cache? Loading the XML of course happens independently from the 24 hour limit, so the only possible explanation is that the cached file was deleted.

The question is.. why does the system works like this? Why it has to be that "manual"? (I spend the entire day pressing the reload button lol).

As mentioned, THIS is definitely not working as intended. I suspect something is deleting the file in the background on your system, as I never heard of such issues before.

Why it couldn't just check for updates everytime the app was loaded / everytime the main activity was opened / or even without the app opened, in the background. Maybe bandwith? not sure otherwise :(

Sure it's bandwidth. The repository index has grown to about 350 kB and is always growing. The Xposed Installer 2.6.1 has been downloaded more than 1.25M times, 2.4.1 even reached more than 2.5M downloads. That surely includes duplicate downloads, bots, users who decided to abandon Xposed etc. But still, the repository index has been downloaded 4.5M times in May, generating more than 1.1 TB of bandwidth. Now imagine what would happen if the installer checked for updates twice daily, or even in the background (which would also generate bandwidth for the many users who don't open the app daily).

Apart from that, traffic caused for the user, waiting times until the file is downloaded etc.

With the database approach and partial updates, I might be able to lower the update rate a bit, but I don't really see a necessity for that. There are about 10-20 updates per day, which affect usally none, sometimes one or two of your installed modules. And even when there are updates, there is hardly any reason that you have to update right now, instead of half a day later.

If the system is changing in the next version (and for now in experimental), yeah we'd be losing time checking there. How does the new system works? does it do anything of the ideas I said just above? I'd love to test it, but im not moving from STABLE releases of xposed, it is way important for me :good:

Just check the thread, I explained it there. There are no changes in the framework, only in the downloader, so it won't affect your modules.
 
  • Like
Reactions: RusherDude

RusherDude

Senior Member
Aug 24, 2012
2,013
623
That's really strange, not intended and I never had that situation. Do you have an app that constantly clears the cache? Loading the XML of course happens independently from the 24 hour limit, so the only possible explanation is that the cached file was deleted.

As mentioned, THIS is definitely not working as intended. I suspect something is deleting the file in the background on your system, as I never heard of such issues before.

Well, now that I remember the times that happened I was cleaning some so it may be the reason.


Sure it's bandwidth. The repository index has grown to about 350 kB and is always growing. The Xposed Installer 2.6.1 has been downloaded more than 1.25M times, 2.4.1 even reached more than 2.5M downloads. That surely includes duplicate downloads, bots, users who decided to abandon Xposed etc. But still, the repository index has been downloaded 4.5M times in May, generating more than 1.1 TB of bandwidth. Now imagine what would happen if the installer checked for updates twice daily, or even in the background (which would also generate bandwidth for the many users who don't open the app daily).

Apart from that, traffic caused for the user, waiting times until the file is downloaded etc.

Yeah, I understand that :(, well at least on BD you're gonna save some bandwith :)


With the database approach and partial updates, I might be able to lower the update rate a bit, but I don't really see a necessity for that. There are about 10-20 updates per day, which affect usally none, sometimes one or two of your installed modules. And even when there are updates, there is hardly any reason that you have to update right now, instead of half a day later.

Just check the thread, I explained it there. There are no changes in the framework, only in the downloader, so it won't affect your modules.

Done. Thanks a lot :)

And about that "there is hardly any reason that you have to update right now, instead of half a day later", there are flashaholics and there are xposaholics :laugh::laugh:

Thanks mate!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Updates from the repository are only refreshed every 24 hours. The downloaded repo.xml is kept in the cache and still needs to be loaded every time the app is started - unless the app was still in the memory.

    So the different situations can be explained like this:
    A) The last refresh was more than a day ago, so the installer first downloads the new XML, then loads it.
    B) The last refresh was less than a day ago, so the installer just loads the cached XML. When you press the refresh button, the 24 hour limit is ignored, so you see new updates.
    C) The app might still have been running in the background, so no refresh was necessary. Or maybe you have cleared the cache, so nothing was downloaded and the XML to load was empty.

    It isn't really worth looking into this in more detail as 2.7 experimental1 handles downloads quite differently.
    1
    That explains a lot. However, doesn't fully explains the C scenario, since on it, the main activity doesn't show all the "pending to install but already notified (in green letters) updates", it doesn't show anything, not even any module or download on any of the activities (forgot to mention this), hitting the reload button fixes everything tho.

    That's really strange, not intended and I never had that situation. Do you have an app that constantly clears the cache? Loading the XML of course happens independently from the 24 hour limit, so the only possible explanation is that the cached file was deleted.

    The question is.. why does the system works like this? Why it has to be that "manual"? (I spend the entire day pressing the reload button lol).

    As mentioned, THIS is definitely not working as intended. I suspect something is deleting the file in the background on your system, as I never heard of such issues before.

    Why it couldn't just check for updates everytime the app was loaded / everytime the main activity was opened / or even without the app opened, in the background. Maybe bandwith? not sure otherwise :(

    Sure it's bandwidth. The repository index has grown to about 350 kB and is always growing. The Xposed Installer 2.6.1 has been downloaded more than 1.25M times, 2.4.1 even reached more than 2.5M downloads. That surely includes duplicate downloads, bots, users who decided to abandon Xposed etc. But still, the repository index has been downloaded 4.5M times in May, generating more than 1.1 TB of bandwidth. Now imagine what would happen if the installer checked for updates twice daily, or even in the background (which would also generate bandwidth for the many users who don't open the app daily).

    Apart from that, traffic caused for the user, waiting times until the file is downloaded etc.

    With the database approach and partial updates, I might be able to lower the update rate a bit, but I don't really see a necessity for that. There are about 10-20 updates per day, which affect usally none, sometimes one or two of your installed modules. And even when there are updates, there is hardly any reason that you have to update right now, instead of half a day later.

    If the system is changing in the next version (and for now in experimental), yeah we'd be losing time checking there. How does the new system works? does it do anything of the ideas I said just above? I'd love to test it, but im not moving from STABLE releases of xposed, it is way important for me :good:

    Just check the thread, I explained it there. There are no changes in the framework, only in the downloader, so it won't affect your modules.