Replicant: Issueshttps://redmine.replicant.us/https://redmine.replicant.us/favicon.ico?15984615062017-09-10T18:12:31ZReplicant
Redmine Replicant - Feature #1833 (New): Add possibility to update Replicant from within Replicant / OTA ...https://redmine.replicant.us/issues/18332017-09-10T18:12:31ZWolfgang Wiedmeyerwreg@wiedmeyer.de
LineageOS has the <a href="https://github.com/LineageOS/android_packages_apps_CMUpdater" class="external">CMUpdater app</a> that handles updates to newer versions. So far, this app was removed in Replicant and no such functionality is available in Replicant. However, this feature gets regularly requested by Replicant users and there would be some advantages of having this working:
<ul>
<li>Automatic checks and notifications if a new update is available</li>
<li>Display of Changelog and optionally additional hints</li>
<li>No need to connect the device to a PC for the update</li>
<li>Automatic signature check of the downloaded update zip</li>
<li>Probably more...</li>
</ul>
<p>The CMUpdater app could be adapted in a way that it works together with a webroot and the <a href="https://git.replicant.us/replicant/release-scripts/" class="external">release scripts</a>. Replicant doesn't have several release channels and dozens of supported devices, so a lot can be simplified and it would be good if nothing more than a bunch of files on the server side would be necessary (no support for POST requests required).</p>
<p>I could image that this can be implemented by adding a new script to the release scripts that generates a folder with a json file for each device and in the json file are at least entries for the latest release, the Changelog and the release date. The app on the device downloads the json file that belongs to the device it is running on. And the app itself generates the download URL of the update zip from the standard paths that are used for <a href="https://ftp-osl.osuosl.org/pub/replicant/images/" class="external">the release images webroot</a>. Maybe the Changelog can also be put in such a standard path (<code>RELEASE_NUMBER/DEVICE_NAME/changelog</code>), so that a Changelog entry in the json wouldn't be nessary.</p>
<p>When testing the app, it is important to check that the signature verification works and the installation with the Replicant recovery is reliable. The app should refuse to install the update if it's not for a new minor release (e.g. 0002 to 0003), but for a major release (e.g. Replicant 6.0 to Replicant 7.1), because these should still be done with a factory reset. It's possible that the CMUpdater app already handles all of this well and only minor adaptations for Replicant are needed.</p> Replicant - Feature #1797 (New): Create a boot animationhttps://redmine.replicant.us/issues/17972017-05-03T16:03:31ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>During boot, Replicant displays a static image of the rollerskating droid with the Replicant name below it. We should replace this with a neat animation.</p>
<p>A long time ago, My Self <a href="/boards/9/topics/6201">made two suggestions in the forum</a> that can already be used as boot animations on Replicant. I like the second "Roots" variant. But I suggest to remove the text below the droid. IMHO 2D text animations almost always look clunky. As an alternative, the ring animation could be replaced with a light red glow behind the droid that pulses.</p>
<p>Wouldn't it be cool to actually make the android roller-skate? The android could roller-skate from left to right into the view and keep roller-skating in the middle of the view, moving the legs and arms. The two small antennas on the head could move a little because of the airflow. A little white blur on the black background could also be used to signal that the replicant is moving.</p> Replicant - Issue #1793 (New): Consider locking critical wiki pageshttps://redmine.replicant.us/issues/17932017-04-13T10:36:44ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>We have quite a few wiki authors. However, a lot of them were inactive for several years. I think when we encourage users to get involved, editing the wiki should be one of the first recommended tasks. Besides knowledge of English and the matter at hand, there is no special knowledge or experience required to edit the wiki.</p>
<p>When someone gets wiki access, it's usually for fixing some smaller mistakes on usage pages or adding information to instructions (e.g. build instructions). These edits require review, but there is not a high level of trust in the wiki author required because mistakes there can't have serious consequences. This makes it possible to get a lot more people involved without having high requirements to get wiki access.</p>
<p>However, the same wiki author that fixes a typo on a usage page has access to the page where all Replicant images are listed and to the page with the signing key information. If a wiki author wants to make a malicious change, he can do so. An example would be replacing links to Replicant images with links to malware and changing the GPG key information to the attacker's key information, so users are downloading and verifying malware without their knowledge.<br />Changes are logged on the activity page and some (including myself) receive a mail notification about the change. But we might not react fast enough for various reasons or we might not even notice the malicious change because it was cleverly masked with other mundane changes.</p>
<p>It is possible to lock wiki pages. Paul, Denis and I can do this and then only project managers can edit those pages. I suggest locking pages like the signing key page and the images page. There is then still the risk that a rogue wiki author copies the signing key and images pages and replaces links to the actual pages with links to the newly created malicious pages. If we want to protect the wiki against those changes, the wiki index, installation pages and maybe the device pages need to be locked, too. This wouldn't be a big restriction. These pages are still only a subset of the wiki pages and users can still make suggestions for changes on these pages.</p> Replicant - Issue #1788 (New): Ensure that emergency calls work properlyhttps://redmine.replicant.us/issues/17882017-04-09T18:32:45ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>When the phone has no service, it usually displays <strong>emergency calls only</strong>. We need to make sure that emergency calls work properly in this network state.</p>
<p><a class="wiki-page" href="https://redmine.replicant.us/projects/replicant/wiki/Samsung-RIL">Samsung-RIL</a> lacks a few requests/responses related to emergency calls. This could prevent that an emergency call is not routed with a higher priority or not directly to a local emergency desk.</p>
<p>We also need to ensure that 112 or similar emergency numbers are properly translated to the local emergency numbers if the local network does not support them.</p>
<p>It may be possible to set up a date for a test call with your local emergency desk so you can safely test if emergency calls work properly with Replicant.</p> Replicant - Issue #1786 (Feedback): Review the Chromium Webview build environmenthttps://redmine.replicant.us/issues/17862017-04-09T16:55:23ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>In Android 6 (Marshmallow), the Webview is not built as part of an Android built. It is built in an Chromium build environment using the Chromium source code. The final apk file is committed to <a href="https://git.replicant.us/replicant/external_chromium-webview" class="external">external/chromium-webview</a>.</p>
<p>While this makes it possible to build the Webview based on the latest Chromium release including security fixes, the downside of this is that another huge and complex build environment has to be set up in order to build the Webview apk. The apk has to be copied and committed to the corresponding repo in the Replicant source tree. Then it gets automatically included in the build.</p>
<p>The build environment for the Chromium code needs to be thoroughly reviewed. All dependencies must be free software and the prebuilt binaries should be verifiable and the aim should be to build them from source, too. The build scripts download and set up a custom Android toolchain. Maybe this prebuilt toolchain can be replaced with the Replicant toolchain that is built from source.</p>
<p>I did an initial review. During the setup of the build environment, a license needs to be accepted that appears to be non-free. The license needs to be accepted because the build environment sets up the proprietary play services libraries. I verified that these non-free libraries are not used when building the Webview apk. The libraries were likely only included in the build environment setup because the same build environment is used for building Chrome which includes the libraries. I removed the scripts related to the play services in <a href="https://code.fossencdi.org/chromium_src.git/commit/?h=replicant-6.0&id=7f1f0f9f88dce6c9444c1692957af14adcc520f2" class="external">this commit</a>. The commit can be used as reference when preparing a new Webview version for <a class="issue tracker-3 status-3 priority-33 priority-high2" title="Issue: Update the webview apk (New)" href="https://redmine.replicant.us/issues/1780">#1780</a>.</p> Replicant - Issue #1785 (New): Change the app label of the old Gallery apphttps://redmine.replicant.us/issues/17852017-04-09T16:20:49ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>In recent Android versions, the Gallery2 app is used. Due to <a class="issue tracker-3 status-15 priority-33 priority-high2 closed child" title="Issue: Incomplete EGL implementation (Resolved)" href="https://redmine.replicant.us/issues/705">#705</a>, Replicant still uses the older Gallery app because the Gallery2 app doesn't work with the Android software renderer.</p>
<p>The Gallery app has the label <strong>Camera</strong> which is confusing. Users expect the gallery app to be named <strong>Gallery</strong> when they browse the apps settings. This naming scheme is also conflicting with the actual camera app as there are two apps displayed in the apps settings that both have the name <strong>Camera</strong> but different icons.</p>
<p>The label strings of all languages need to be changed.</p> Replicant - Feature #1784 (New): Integrate toolchain build in Android build systemhttps://redmine.replicant.us/issues/17842017-04-09T16:07:40ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>Currently, a <a href="https://git.replicant.us/replicant/vendor_replicant/tree/build-toolchain" class="external">simple script</a> takes care of building the toolchain. The script needs to be converted to Android Makefiles, so parts of the toolchain can be built e.g. with <code>make gcc-android</code> or the whole toolchain can simply be built by issuing <code>make toolchain</code>.</p>
<p>A build error happens when the toolchain is built after running <code>. build/envsetup.sh</code> in the same shell. So the toolchain always needs to be built in a newly opened shell where no Android build environment variables are already set.</p>
<p>The first step is to identify the environment variable(s) from <code>envsetup.sh</code> that break the toolchain build. Then the toolchain is buildable in the Android build environment and it's possible to write the Makefiles.</p> Replicant - Issue #1780 (New): Update the webview apkhttps://redmine.replicant.us/issues/17802017-03-15T16:44:23ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>Due to <a class="issue tracker-3 status-15 priority-33 priority-high2 closed child" title="Issue: Incomplete EGL implementation (Resolved)" href="https://redmine.replicant.us/issues/705">#705</a>, the webview apk in Replicant 6.0 cannot be updated. Currently, webview version 43.0.2357.134 is in use. It was released in July 2015 and has numerous security issues that were discovered since then.</p>
<p>Updating the webview apk would fix a lot of security issues and would ensure that websites can be visited securely using the browser shipped with Replicant or Lightning.</p> Replicant - Feature #1779 (New): Implement setting that allows to permanently disable the modemhttps://redmine.replicant.us/issues/17792017-03-06T22:06:03ZWolfgang Wiedmeyerwreg@wiedmeyer.de
<p>Some users don't need or don't want to use the modem of their device. Reasons might include skepticism about the level of the modem isolation, the wish to completely avoid the tracking of the mobile system or they simply don't want to have a nonfree system like the modem operating system running on their device.</p>
<p>So far, these users were advised to either buy a Replicant-supported device without a modem or to disable the radio interface layer by deleting or moving the library.</p>
<p>A more user-friendly approach would be a setting that, when enabled, would disable the modem boot when booting Replicant and that would not load the modem software to the modem.</p>
<p>When enabling the setting, the phone needs to be rebooted to ensure that the modem is not running. When disabling the setting, the user needs to be informed that the modem will only be operational after the device is rebooted.</p>