Introduction

Accrescent is an Android app store focused on security, privacy, and usability. This documentation currently covers how to use the Accrescent developer console, although eventually it will contain much more in-depth discussion about its inner workings, server infrastructure, etc..

If you're a developer new to Accrescent, we recommend reading the getting started guide first. It explains how to sign up for the Accrescent Developer Console and gives a high-level overview of how it works. The other sections give more specific instructions for individual tasks.

Getting started

Similar to the Play Store, all apps in Accrescent are submitted and updated by their developers. This section of the guide explains how to set up, build, and submit apps as a developer.

Building

Although Accrescent accepts app submissions directly from developers, the process for building and signing an app is slightly different than what most developers are used to. Namely, Accrescent does not accept monolithic APKs. Read this section carefully to learn how to build apps in a format the Accrescent Developer Console will accept.

Setup

You need to install bundletool to build apps for Accrescent. bundletool is the open-source tool Google uses to generate split APKs from app bundles in the Play Store. Rather than signing split APKs from app bundles itself, Accrescent accepts split APKs generated and signed by developers.

There are two primary ways to use bundletool. The first (and easiest) way is using the bundletool Gradle plugin. The second is using the bundletool CLI. Both methods are covered in the following sections.

Bundletool Gradle plugin

Installation

Note: This plugin is only compatible with Android Gradle Plugin 7.4.0+.

Apply the bundletool Gradle plugin to your app as described in the plugin's home page. Then specify a signing configuration in your app-level build script as follows:

bundletool {
    signingConfig {
        storeFile = file("keystore.jks")
        storePassword = "password"
        keyAlias = "release"
        keyPassword = "12345"
    }
}

Notice the similarity to how signing configs are specified for your app.

Building

You can now build split APKs for your app by running ./gradlew buildApks${variant}. For example, if your app has a release variant, you can build the corresponding split APKs with the following command:

$ ./gradlew buildApksRelease

The resulting APK set will be generated as app/build/outputs/apkset/${variant}/app-${variant}.apks.

Bundletool CLI

Installation

bundletool can be installed from its GitHub releases. There's also an AUR package for Arch Linux users.

Building

There are two steps to building an app for Accrescent with the bundletool CLI:

  1. Building the app bundle
  2. Generating split APKs from the app bundle

See Google's documentation for how to build an app bundle (note: signing the bundle with an upload key is not necessary since the split APKs are signed later and are what is actually uploaded to Accrescent).

To build an APK set (set of split APKs) from bundletool, see bundletool's documentation. Be sure to provide a non-debug keystore to the build-apks command. The resulting APK set (.apks file) is what you will upload to the developer console.

Submitting a new app

Creating an account

To submit an app to Accrescent, you first need to create an account on the developer console. Currently login with GitHub is the only supported login method.

Sign-up is not yet available to the general public and is only permitted for allowlisted GitHub accounts. This choice was made to ensure that all developers on Accrescent are willing to tolerate the lackluster user experience, console bugs, and frequent policy changes resultant of Accrescent being in its early stages. If you are not allowlisted and are still interested in publishing on Accrescent, you may contact us at contact@accrescent.app to request being allowlisted.

Submission process

To upload a new app, click the "New app" button on your dashboard. You will be presented with an upload form. Upload the APK set (.apks file) you generated earlier as well as an app icon. The APK set must be less or equal to 150 MiB in size and the icon must be a 512 x 512 PNG. If you already have a Play Store icon, you can use it here. If you don't have an icon, you can generate one in Android Studio (make sure "Play Store icon" is selected).

Click "Upload" after you've selected the correct files. Once your files are finished uploading, you'll be presented with an autofilled form with basic information about your app. You may edit the display name if you wish. This is the name that will appear to users in the store. Once you're satisfied that your app's information is correct, click "Submit" to begin the review process.

If some or all of your app's functionality requires authentication to access, please provide test account credentials for the review process. This is currently not possible within the developer console, so you will need to contact the Accrescent team directly to provide them.

After you submit

A reviewer will be assigned to your app after you submit it. To increase its chances of being accepted, please review the app requirements later in this guide before submitting.

If the app is accepted, it will be passed on to have its metadata cryptographically signed into the store. This process ensures Accrescent's security even if one of its servers is compromised. You don't need to do anything at this point. Once your app is published, you will be notified and it will show up under "My apps" in the developer console

Post-approval

For next steps and how to update your app after it is published, see the maintenance section of the guide.

Maintaining a published app

Once an app is published, it needs to be maintained. This section of the guide explains how to maintain and modify an app after it is published.

App updates

Submission process

To update one of your existing apps, go to "My apps" in the developer console and click "Upload new update" under the app you want to update. You'll be presented with a similar form to the new app form. Select an APK set that represents your app update and it will be automatically uploaded and checked. You'll be shown the info Accrescent could gather about your update. If you're satisfied, click "Submit."

Different things may happen with your update after you submit it depending on its content. The specific process is explained below.

Review process

Accrescent's update process is unique in that most of the time, developers don't need to wait to have their updates reviewed. Instead they are published immediately after the developer submits them. This approach may sound like a bad idea at first, but it has several advantages:

  • security updates can be published immediately after they're ready
  • updates can (theoretically) be fully automated through CD pipelines
  • developers have fewer frustrating review experiences
  • Accrescent developers spend less time reviewing and more time developing

To mitigate the potential for a malicious or compromised developer to abuse this process, all updates requesting new sensitive permissions (as determined by the developer console) will require manual review.

For example, say an app was approved requesting the READ_SMS permission. The developer uploads an update that requests the READ_SMS and MANAGE_EXTERNAL_STORAGE permissions. Because MANAGE_EXTERNAL_STORAGE is newly requested and Accrescent considers it to be a sensitive permission, that update will require manual review.

Continuing the example, let's say that update is approved and the developer uploads another update requesting the READ_SMS and MANAGE_EXTERNAL_STORAGE permissions. Since the app was previously approved to request both of these permissions, the second update will not require manual review and will instead be published immediately after the developer submits it.

App edits

Introduction

App metadata (e.g. descriptions) is updated through edits. An edit is a set of changes to an app's metadata. Once submitted and approved, all of an edit's changes are published simultaneously.

Usage

To create an edit, follow the steps below

  1. Navigate to "My apps" in the console sidebar.
  2. Click the "View details" button on the app you wish to create an edit for.
  3. At the top of the screen, you will see a "New edit" form. Fill out this form with the changes you want the edit to include.
  4. Click "Create."

An edit will be created which can now be seen from the app details screen.

If you are satisfied with your edit's changes, click its "Submit" button. It will then be submitted for review. If review passes, all of your changes in the edit will be published simultaneously.

Appendix

This section contains the appendices complementary to the documentation.

Requirements

Accrescent has certain minimum requirements for all apps submitted to it to ensure the privacy and security of its users. This page documents these requirements for developers to reference before submitting their app so they know how to best improve their chances for acceptance.

These requirements are not exhaustive and Accrescent reserves the right to modify them at any time. However, the Accrescent developers attempt to make this list as thorough as possible and give notice to developers well in advance for major requirement updates. If you see something missing or incorrect, please submit a pull request at this site's GitHub repository.

Automated checks

The following checks are run automatically on all apps before the developer submits them. If any of them fail, an error will show in the developer console and the app cannot be submitted.

Debug certificate

Apps may not be signed with a debug certificate. They are insecure by design and so are not permitted in Accrescent.

Native code

Accrescent supports the following architectures:

  • arm64
  • armeabi-v7a
  • x86_64
  • x86

Apps containing 32-bit native code for a supported architecture must also include 64-bit native code for the corresponding architecture. Additionally, apps containing native code must support at least one of Accrescent's supported architectures.

For more information, see Google's documentation on 64-bit support.

Target SDK

Accrescent currently follows Google Play's target SDK requirements with a few major changes:

  • there are no formal timeline extension requests
  • Accrescent will remove apps when they don't meet the target SDK requirements for existing apps, not just make them less discoverable

android:debuggable

The android:debuggable attribute in the Android manifest must not be "true".

android:testOnly

The android:testOnly attribute in the Android manifset must not be "true".

Manual checks

The following are checks done by reviewers in reference to this document when manually reviewing an app.

ADB access

Utilizing ADB (Android Debug Bridge) directly or indirectly within an app is strictly forbidden. This restriction includes, but is not limited to using a proxy like Shizuku or directly using wireless debugging.

Root access

Apps may not utilize root access for any functionality. This includes apps which attempt to exploit the current device to gain root access as well as apps which access privileged functionality only available due to previously rooting the device.

Self-updaters

Apps may not have self-updaters. This includes improper use of the REQUEST_INSTALL_PACKAGES permission as outlined below, downloaders which prompt the user to update from an APK, and direct links to sources which may encourage or confuse the user into updating from a location outside of Accrescent.

Sensitive permissions

Addition of any of the following permissions in an app update will trigger a manual review and their usage will also be reviewed in new apps:

  • ACCESS_BACKGROUND_LOCATION
  • ACCESS_COARSE_LOCATION
  • ACCESS_FINE_LOCATION
  • BLUETOOTH_SCAN
  • CAMERA
  • MANAGE_EXTERNAL_STORAGE
  • NEARBY_WIFI_DEVICES
  • PROCESS_OUTGOING_CALLS
  • QUERY_ALL_PACKAGES
  • READ_CALL_LOG
  • READ_CONTACTS
  • READ_EXTERNAL_STORAGE
  • READ_MEDIA_AUDIO
  • READ_MEDIA_IMAGES
  • READ_MEDIA_VIDEO
  • READ_PHONE_NUMBERS
  • READ_PHONE_STATE
  • READ_SMS
  • RECEIVE_MMS
  • RECEIVE_SMS
  • RECEIVE_WAP_PUSH
  • RECORD_AUDIO
  • REQUEST_INSTALL_PACKAGES
  • SEND_SMS
  • WRITE_CALL_LOG
  • WRITE_CONTACTS
  • SYSTEM_ALERT_WINDOW

Review will fail if an app requests a permission it does not reasonably require to function or uses a permission to share sensitive user data without informed consent. More specific requirements are laid out below for the following permissions:

  • MANAGE_EXTERNAL_STORAGE
  • REQUEST_INSTALL_PACKAGES

MANAGE_EXTERNAL_STORAGE

The MANAGE_EXTERNAL_STORAGE permission may only be requested for one or more of the following use cases:

  • file management, such as for a file manager app

MANAGE_EXTERNAL_STORAGE is highly invasive and almost always unnecessary. Developers should heavily consider using internal app storage, the MediaStore API, and/or the Storage Access Framework instead.

REQUEST_INSTALL_PACKAGES

The REQUEST_INSTALL_PACKAGES permission may only be requested for one or more of the following use cases:

  • web browsers
  • file sharing
  • messengers which support sending APKs

REQUEST_INSTALL_PACKAGES may not be used for self-updating or updating or installing other apps.

Service intent filters

Adding any of the following actions to a service's intent filter will trigger a manual review:

  • android.accessibilityservice.AccessibilityService
  • android.net.VpnService
  • android.view.InputMethod

More specific requirements for the following actions are laid out below:

  • android.accessibilityservice.AccessibilityService
  • android.net.VpnService

android.accessibilityservice.AccessibilityService

Accessibility services are highly invasive, presenting a security and privacy risk to users. As such, they are heavily restricted on Accrescent and may only be used to help users with disabilities interact with the device.

android.net.VpnService

VPN services may only be used by apps that have a VPN as their core functionality. They must encrypt all data between the device and the VPN tunnel endpoint. They may not be used to collect sensitive user data without informed consent.