I would like the addition of an app blacklist. Apps in this list should not be updated through accrescent.

The reason for this is that people might want to update certain apps through other sources and do not want to get prompted for updates from accrescent.

More background:
I use the Molly app (non FOSS). Accrescent prompted me for update. To me it was not clear this originated from accrescent, i am not sure the notification even tells. It did result in suddenly having the FOSS version installed while I require the non FOSS version for the features it has. This much to my annoyance. I understand Accrescent checks for the app id and Molly does not distinguish the app versions in form of an app id. Blacklisting would at least help me to not on every update having to find out I lost the features I need again.

Hi; Can we offer you translations of the user interface?
(In my case, in French)

I am aware that Accrescent is still at an early stage, and that many additions will be necessary before the first public publication, this is only a base that I will keep updated as additions are made (if it fits)

I can do this via pull request, or by simply providing you the strings.xml file.

Thanks.

• App icon
• App description
• App size
• Links to license, source code, bug tracker, email, etc.
• App permissions
• Old versions in case someone wants to downgrade for some reason

First of all I would like to thank the developers for developing such an application.

I'm using Android 10 (Lineageos) and the first version is giving package error.

Trying to update from Github but I get the error.
Is the APK signed differently?
I installed it from Github originally.

This information should be displayed in the settings instead

Hi
This is not a request and I am writing in the wrong place I know.
But when the app will be ready to use?
Thank you!

Currently this is how an installation looks.

1. Pleass change the deactivated install button to a cancel download button.
2. If the download (and later the installation) is completed, show an pupup with: "Sucessfully downloaded (installed)".
3. Add an installation progress tracker after the user has confirmed the installation. (If it's not possible to get the installation progress, atleast show an indicator that something is happening).
4. 1-3 should also be displayed if it the update was started manuelly.

Accrescent should have a toggle that disables auto-updates. Instead, users should get a notification about a new version, at which point they can choose whether they want to update or not.

Unlike the blacklist mentioned here (#154), this would apply across the board, and not to specific apps.

The blacklist feature would be useful if someone is obtaining a specific app from a different source and doesn't want to get it from Accrescent, and the auto-update toggle will be for people who want to check what a new version offers before updating etc.

Reproduce

In system setings under Display -> Display size and text
set the font size to its maximum and open accrescent's searchbar.

Steps to reproduce:

Settings -> display -> Interface Size (and additionally Font Size) set to big/large/very large (just highest possible values).

Observed behavior

The app looks quite strange then (I am visually impaired user so can't describe it in detail), but for me, more important is that "open" button of second app on the list is not announced at all by TalkBack. With standard (default) font and interface size, the label of "open" button is announced correctly.

Don't know it's issue of Accrescent, of some composable or of Compose itself - I just learn coding and I'm total beginner.

As a follow up to #50 and 13a4d6d, make a GitHub Action that makes a PR to update MIN_TIMESTAMP to the latest published value every X weeks. The frequency isn't important to begin with but once every month seems reasonable given where Accrescent is in development currently.

Currently if STATUS_PENDING_USER_ACTION is received, Accrescent is in the background, and the notification permission is denied, the user is never notified that user action is required to install the app(s) they want.

We should resolve this by keeping track of these pending apps for a short time (the lifetime of the application context is most likely sufficient) and prompting the user when they next resume MainActivity. This may require a new UI dialogue if there are multiple pending apps since the user would otherwise be inundated with requests without context the next time they open Accrescent.

When an app is updated through Accrescent automatically, you should get a notification that says something along the lines of "app_name has been updated successfully." or something similar.

Unattended updates are a godsend, but it would be nice to actually know when something is updated, so I'm not perplexed when the app changes in some way when I'm unaware that it has updated in the first place.

Currently the store doesn't seem to auto refresh. Users are not seeing new apps in the list until after a manual refresh. Perhaps the app list should either refresh each time the store is opened or each time it polls for updates?

Hello!

GitHub supports a CODEOWNERS file that makes it possible to get notified if certain files within a repository change. I'd like to propose to add a new GitHub team for translators and make it the owner of files like app/src/main/res/values/strings.xml. This way people in the team get notified if new strings get added and can accordingly prepare new PRs updating the language files.

The only downside I see is that people get notified by getting assigned to a PR as a reviewer if code-owner files change. It does not work if one pushes directly on a branch AFAIK.

I'd be willing to set this up if you see it as low priority or don't have the time. I have a language PR prepared as well alongside the already existing #58.

Cheers.

P.S.: How can one help with the project in the long-term? I am looking to contribute once I have more time, which would be around October. Can I simply fix/implement features? Or is it better to ask around the matrix room?

Specifically:

• Choose a primary and secondary color based on Material Design guidelines
• Utilize our chosen colors in a Material fashion throughout the app UI
• Redesign the app logo to match said colors (not just color changes - it needs other tweaking)

Jetpack Paging is likely the most appropriate option for fetching app icons. Their sha256 hashes should be checked in accordance with the signed repodata.

The "new format" is the end result of accrescent/meta#2

Since the client is already "production ready" how do you feel about inclusion in F-Droid?

I tried to install Aves Gallery and Molly, clicking install had no effect.

On the latest Github release.

Due to my testing setup this is very inconvenient to debug. I'll be able to figure it out eventually, but I'd appreciate someone else grabbing a log if possible.

Current changes in the idea bucket:

• Remove developer-specific repodata entirely, instead pinning the app certificate in the root repodata (pending review)
• Use unchanging ID for developers instead of their username (irrelevant if above change is deemed sane, otherwise accepted)
• Design method for fetching split APKs from the repository
• Store app display names

So far, the app only works when it has an internet connection.

1. However, the tab with the already installed apps should also be able to be displayed when the smartphone is in flight mode, for example.
2. The updates and (available) apps tabs should also show useful error messages, like:

Currently the device has no internet connection.
Do you want to try again?
retry - button

Apps

Installed

Updates

The initial implementation should at least be able to search through the local database of app display names. It doesn't need to do fuzzy matching or anything fancy (although better matching would be a welcome improvement).

We should listen for ACTION_LOCALE_CHANGED and ACTION_APPLICATION_LOCALE_CHANGED and install the corresponding language split APKs on reception.

We could probably uninstall irrelevant language splits immediately after installing new ones in the initial implementation. Some sort of delay may be desired but the best way to handle old splits isn't yet clear to me.

Have different settings, depending on how
the device is connected to the internet.

Download and install new apps:

1. Ask each time (disables settings 2 - 5)
2. WIFI (allow / disallow installations)
3. metered WIFI (... / ...)
4. mobile data (... / ...)
5. roaming (... / ...)
6. have an extra button with which the current settings can be ignored once

Update of already installed apps:

1. take over installation settings (disables settings 2 - 5)
2. WIFI (allow / disallow updates)
3. metered WIFI (... / ...)
4. mobile data (... / ...)
5. roaming (... / ...)
6. have an extra button with which the current settings can be ignored once

In addition, you could have separate settings for very small (individual mb limit) and very large apps (individual mb limit) and divide updates into manual and automatic updates.
So many settings are probably superfluous, but I wanted to list them all.

Use HTTP Range requests to accomplish this. Initial implementation should work for both repository metadata and APKs.

There is already TLS pinning but I think also having DNS over HTTPS inside the app would be great

I tried to add this to the ''update all button'' Issue.
But it wouldn't let me.
It would be nice have updates happen in as few clicks as possible. If the update all button was on every tab that could work. Alternatively if you could set the app to open by default on the updates tab.

An update all button in a notification would be quicker still.
Or Assuming there are unattended background updates… it would be nice to see a report back on what was updated when the app next open.

This would allow us to display e.g. Accrescent as "Accrescent" rather than "app.accrescent.client" in the UI. It should be in the root repodata to prevent different developers from creating multiple apps with the same name, potentially misleading users.

Waiting on:

• #5
• #41
• Testing on Android 13 (beta is fine)

Currently the repodata timestamp is downgrade protected by setting the latest verified timestamp as the minimum accepted value. This means that a client which has not previously fetched repodata (e.g. new installs) will accept a timestamp with an arbitrarily low value, thus being vulnerable to an attacker serving outdated repodata.

The solution to this problem is to hardcode a minimum expected value for the timestamp as a fallback in the event that there is no previously saved timestamp. It should be updated periodically (at least before every regular update, but ideally a dedicated update with a timestamp bump should be released on a set schedule, say, every 2 weeks).

It will be also a link to the source code. When the user clicks it, it would be opened by the default browser of Android.
This is can be found in Droid-ify (F-Droid client) and also other apps.

Hi! My reason for wanting this is every time accrescent updates, I have to type and search accrescent GitHub to check the changelogs. With this, it's just one tap away.

The user can then press this notification to bring up the package installation dialogue. For reference, see Signal's automatic updates and GrapheneOS's compat layer for the Play Store

As per https://developer.android.com/reference/androidx/work/NetworkType

Currently all app-specific repository metadata is unconditionally fetched from the network when requested. This data should ideally be cached and only fetched when it has changed.

The groundwork for this change is already in place since all repository metata access is facilitated through RepoDataRepository. Implementing caching should mostly just require modification of getAppRepoData in that class.

For example, it is clear for an f-droid user that any app downloaded from their repo contains no trackers or propriatry libraries and dependancies.

What is Accrescent's policy in that respect? Do we have one? I couldn't find one in the app description.

What can I as an end user be guaranteed regarding the privacy of the apps in your repos?

While I have no reason to suspect any wrong-doing, I believe detailed information would not hurt.

I have installed Aves (v1.7.8) via Accrescent on two different systems (WSA and One UI 5.0).
Now, however, v1.7.9 has been released, but I cannot upgrade to it with Accrescent, even if I search for it manually in the Update tab.
Accrescent also shows v1.7.9 as the latest version.