If we remove debug.sf.nobootanimation=1, the bootanimation program
then runs but we still have nothing on the screen, even with a
bootanimation.zip in /system/media/.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without that fix, on a GT-I9300, the mount fails and we have the
following in dmesg:
    EXT4-fs (mmcblk2p8): can't mount with journal_async_commit
    in data=ordered mode

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE, in Replicant 11,
when running 'make otapackage' we have the following build
failure:
  2021-10-06 17:37:04 - blockimgdiff.py - INFO    : Finding transfers...
  Traceback (most recent call last):
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 174, in _run_module_as_main
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 72, in _run_code
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/__main__.py", line 12, in <module>
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 174, in _run_module_as_main
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 72, in _run_code
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 2258, in <module>
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 2237, in main
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 1980, in GenerateNonAbOtaPackage
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 755, in WriteFullOTAPackage
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 679, in GetBlockDifferences
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/common.py", line 2630, in __init__
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/blockimgdiff.py", line 342, in Compute
    File "[...]/out/host/linux-x86/bin/ota_from_target_files/blockimgdiff.py", line 1561, in FindTransfers
  AssertionError
  17:37:04 ninja failed with: exit status 1
This is because for some reasons the cache_size variable is
None. I've not been able to track exactly why though.

And with BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE but without the
entry in fstab, in Replicant 11, also when running
'make otapackage' we have the following build failure:
    Traceback (most recent call last):
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/internal/stdlib/runpy.py", line 174, in _run_module_as_main
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/internal/stdlib/runpy.py", line 72, in _run_code
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/__main__.py", line 12, in <module>
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/internal/stdlib/runpy.py", line 174, in _run_module_as_main
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/internal/stdlib/runpy.py", line 72, in _run_code
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 999, in <module>
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 993, in main
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 876, in AddImagesToTargetFiles
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/add_img_to_target_files.py", line 539, in AddCache
      File "[...]/out/host/linux-x86/bin/add_img_to_target_files/common.py", line 1872, in CheckSize
    KeyError: '/cache'
    17:05:43 ninja failed with: exit status 1

In Replicant 6, f2fs is being used, and we have the
following in rootdir/fstab.smdk4x12 in device/samsung/i9300:
  /dev/block/mmcblk0p8            /cache                  f2fs            noatime,discard,inline_xattr,inline_data,nosuid,nodev           wait
  /dev/block/mmcblk0p8            /cache                  ext4            noatime,nosuid,nodev,journal_async_commit,errors=panic          wait

But for now ext4 is used instead of f2fs as ext4 is already
been used for and tested with the system and data
partitions, so the diff is smaller than with f2fs.

If it works fine we could then switch to f2fs (and spot
regressions if there are som):
- to stay compatible with Replicant 6
- because a log-structured file system seems more adapted
  for cache than regular filesystems like ext4.

And even if f2fs design is more recent than ext4, and that
increases the risk of loosing data, the cache partion can
easily be reformated in the recovery.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

In Replicant 6 we have the following in
rootdir/fstab.smdk4x12 in device/samsung/i9300:
    /dev/block/platform/dw_mmc/by-name/OTA /misc emmc defaults defaults

And without this patch, the Replicant 11 recovery complains
about a missing /misc partition.

Once the recovery is booted we see the following on the
bottom of the screen on the GT-I9300:
    E:Failed to clear BCB message: failed to
     find /misc partition

And when we select "Apply update from ADB" in the menu, we
have the following on the bottom of the screen:
    E:Failed to clear BCB message: failed to
     find /misc partition
    E:Failed to WriteUpdateInProgress: faile
    d to find /misc partition

    Now send the package you want to apply
    to the device with "adb sideload <filena
    me>"...

With this fix all these warnings disappear.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

According to the PIT that we have in the
vendor/replicant-data repository[1], the RECOVERY
partition size is 8M:
    $ heimdall print-pit --file 16G.pit
    Heimdall v1.4.2
    [...]
    --- Entry #9 ---
    Binary Type: 0 (AP)
    Device Type: 2 (MMC)
    Identifier: 6
    Attributes: 5 (Read/Write)
    Update Attributes: 1 (FOTA)
    Partition Block Size/Offset: 98304
    Partition Block Count: 16384
    File Offset (Obsolete): 0
    File Size (Obsolete): 0
    Partition Name: RECOVERY
    Flash Filename: recovery.img
    FOTA Filename:
    [...]

Here the blocks size is 512 bytes, so that makes 8MiB.

Without that patch, Replicant can build recoveries bigger
than 8MiB, and when installing them with heimdall, they work
fine[2] and nothing looks wrong.

The issue is that when the image is bigger than the
partition size, the part of the recovery image that is
bigger than the recovery partition will be written on the
next partition(s) and overwrite their content.

In the case of the GT-I9300, the next partition is the
RADIO partition, which contains the modem firmware.

So if users built Replicant 11 themselves and followed
the Replicant 11 official installation instructions which
instruct users to install the recovery, and didn't make
any backup of the RADIO partition, their modem will probably
not work anymore.

As the modem firmware is nonfree and not redistributable,
fixing that without any backup is not trivial:
- We don't know the situation with repair shops, some
  might have agreements with Samsung for being able to
  restore original operating systems. Though if the
  reparation costs more than buying a new phone it doesn't
  help here.
- Some shops might not have agreements with Samsung, and
  modem firmwares can also be found on the Internet, and
  in both cases we don't know the legal situation (which
  also depends on the countries) with various right to
  repair legislation or the lack thereof.
  If the law doesn't permit reparation, users that don't
  have any backup will face a dylema between repairing the
  phone themselves and respecting the copyright laws.
- As the code is nonfree we also don't have much
  documentation on the side effects of installing a
  different modem firmware than the one originally on the
  device.
- Replicant obviously cannot redistribute such nonfree
  firmwares and probably cannot have instructions to
  find such firmwares.

[1]https://git.replicant.us/replicant/vendor_replicant-data/tree/devices/PIT/GT-I9100G/stock/16G.pit
[2]https://github.com/Benjamin-Dobell/Heimdall/issues/494

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

We do need to flash the recovery to enable people to format the
userdata partition.

In addition we can't flash the userdata as-is as the hack to
automatically reisize it at the first boot doesn't work anymore
because for some reasons selinux seems to be enforced for init
services even when it's in permissive mode globally.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

We now use userdebug for quite some time, and we also use it by
default in vendor/replicant/build.sh

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

The device_samsung_i9305 also copies the exact same
android.software.app_widgets.xml in the exact same
place, so it's best to move that in
device_samsung_midas_common.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Without that, libsamsung-ril continuously tries to bootstrap
the modem and fail, because the support for the GT-I9300 modem
has not been completed yet in the Replicant 11 kernel and the
associated code in libsamsung-ipc has not been fully merged yet.

So in order not to pollute the kernel logs, it's better to disable
it for now.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>