Previously, when building from prebuilts boot no rules were created to
produce the boot image files for the host, i.e. the OS on which the
build was running. That caused problems with checkbuilds. No rules were
produced as there was no host variant of a prebuilt apex to provide
them.
This change restructures the code to allow the prebuilt bootclasspath
fragment to build the host variants of the files from the dex files
provided by the prebuilt APEX. The generated files will not be the same
as they would be if built from source as there is no boot image profile
to use but it should be sufficient to satisfy the checkbuild target and
allow for host side testing.
Bug: 192575099
Test: m SOONG_CONFIG_art_module_source_build=false droid dist checkbuild
Merged-In: I6af00f19bb71aa18dd462f5eac6aa38e3e721023
Change-Id: I6af00f19bb71aa18dd462f5eac6aa38e3e721023
(cherry picked from commit a56be7d7815ad164cdd854f8fc6b1cbc3bbf1918)
Previously, boot image generation used GetCachedGlobalSoongConfig(ctx)
in order to get access to the GlobalSoongConfig. That required that
some other part of the code had called GetGlobalSoongConfig(ctx) to
initialize the cached value. That was left over from when the boot
image generation was done in a singleton which could not call
GetGlobalSoongConfig(ctx) directly. That is no longer true.
This change switches the uses of GetCachedGlobalSoongConfig(ctx) to
GetGlobalSoongConfig(ctx) and removes the now unnecessary call to
GetGlobalSoongConfig(ctx) from outside the functions.
Bug: 192575099
Test: m nothing
Merged-In: I34b7b1526d072d8b09fda7caa96e381695888e16
Change-Id: I34b7b1526d072d8b09fda7caa96e381695888e16
(cherry picked from commit 8fc51a8eb6ca20dbb4b65822123201568bb297f1)
Previously, the boot zip file, containing all the boot image files for
all the supported architectures, was only created from source. It was
not created when building from a prebuilt_bootclasspath_fragment. That
lead to build failures when building from ART prebuilts.
This change pulls the boot zip file creation out so that it can be done
for both source and prebuilt bootclasspath_fragment modules as well as
for the platform_bootclasspath module.
Bug: 192575099
Test: m out/target/product/generic_arm64/boot.zip
m SOONG_CONFIG_art_module_source_build=false out/target/product/generic_arm64/boot.zip
- Compare the output of the first command from before the change
with the output from them both after and confirm that when the
ART prebuilts are up to date with the source that there are no
differences.
Merged-In: Ie7dd5e2ca4a865d06fd9ebf87320cf68c4d05bc3
Change-Id: Ie7dd5e2ca4a865d06fd9ebf87320cf68c4d05bc3
(cherry picked from commit 56afb27fb099cb79c1537c661628db1776f1fcc3)
Sometimes the stem property is set to change both the installed file
name and the name use to filter the configured module list, e.g. when
adding a test library to replace the standard library, e.g. test_foo
instead of foo.
Sometimes it is used just to change the installed file name.
This change uses both to filter the updatable boot jars and not just
the stem.
Bug: 180105615
Test: m nothing
Merged-In: I6c459fc3597b1e4f062bc9a4e52843305b538c5f
Change-Id: I6c459fc3597b1e4f062bc9a4e52843305b538c5f
(cherry picked from commit 56c93e899a355311463d41e988c9ba511af14278)
Without these errors, the last encountered deapexer would silently be
used, and we wouldn't know if it was taken from the prebuilt APEX that
actually get installed in the system image.
With this error check there may be only one enabled prebuilt_apex or
apex_set for each apex_name (which defaults to the module name). E.g.
if there are both prebuilt com.android.foo and com.google.android.foo,
it is necessary to disable one of them in the .bp file.
Merged-In is set from https://r.android.com/1745454, a change that has
gone into AOSP and internal master, as well as sc-dev-plus-aosp, but
specifically not sc-dev. This change cannot merge into sc-dev-plus-aosp
and others, because they may or may not have the com.google.android.art
prebuilt APEX present depending on manifest, and with this check
exactly one of com.android.art and com.google.android.art prebuilts has
to be present and enabled. It'll be cherry-picked to AOSP along with a
full fix for b/192006406, when it can be safely enabled everywhere.
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Test: m nothing SOONG_CONFIG_art_module_source_build=true
Test: m nothing
with enabled:true for the com.android.art prebuilt APEX - check that
it fails with an "ambiguous duplicate deapexer" error
Bug: 192006406
Bug: 192542393
Change-Id: I44566fd26b12f82a8a67fe4a69e56303460756d0
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Previously, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: Ibf81a7de63b888a3ebf445528326fa6101fdb1ba
Unless the prebuilt dex jar files are explicitly required to build
system images or dex preopting defer reporting of any missing dex boot
jars from Soong to Ninja.
This will prevent builds that contain prebuilt sdks, containing prebuilt
bootclasspath_fragment modules but without a corresponding apex_set or
prebuilt_apex module from failing even when it is not building against
the prebuilt sdk.
Bug: 179354495
Test: m nothing
Merged-In: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
Change-Id: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
(cherry picked from commit ef083c9556c53738e5d7a3ab791c49ef00501f73)
Previously, if a bootclasspath_fragment had both a java_sdk_library
module and one of its components in stub_libs properties they would be
treated as separate modules instead of simply different APIs from the
same module. That would result in them both providing stub dex jars to
"hiddenapi list" which would fail because it found duplicate
definitions of the same class.
e.g. Specifying something like this:
api: {
stub_libs: [
"art.module.public.api",
],
},
core_platform_api: {
stub_libs: [
"art.module.public.api.stubs.module_lib",
],
},
would cause "hiddenapi list" to fail because it would have been passed
paths to two dex jars (actually the same dex jar but that does not
matter) each of which defined the same class, e.g. java.lang.Object.
This change treats the "art.module.public.api.stubs.module_lib" and
"art.module.public.api" modules as being the same for the purposes of
hidden API processing.
(cherry picked from commit 3f0290ef7940c70a491dcbd4b57cabd8b2e753ef)
Bug: 192446466
Test: m nothing
Merged-In: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Change-Id: I9e1cb82bea96022faaec98edc0c9ea7eac6204b0
Previously, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: I0cbf11986adff1f2f967b96f86e6bfe0e9b8b1ef
Before this fix, compiling a java_library against sdk_version:
"module_current" can't use the @SystemApi(MODULE_LIBRARIES) provided
by the ART module because the system module "core-current-stubs-system-modules"
contains only the public APIs.
Use the new system module with module lib APIs.
(cherry picked from commit b54f5aa3599196cfed8c32d3e52e1c35b51b8473)
Bug: 183097033
Test: m droid
Merged-In: I274e2710d1ff34e896aa620bfafb4481180c53b5
Change-Id: I374bc4899ef8f60344e37a94ad3cb8492f47fb4d
Revert "Add ramdisk_available to init_first_stage's deps"
Revert submission 15071196-init_first_stage_soong
Reason for revert: fixes b/192248690
Reverted Changes:
I23cf4f975:Add ramdisk_available to init_first_stage's deps
Icd98c7e24:Add ramdisk_available to init_first_stage's deps
If9da9ba16:Add ramdisk_available to init_first_stage's deps
Ibc8668029:Add ramdisk_available to init_first_stage's deps
I3b4b8c475:Add ramdisk_available to init_first_stage's deps
I59cd149e0:Completely migrate init first stage to Soong
I36d789578:Add ramdisk_available to init_first_stage's deps
I2a0daa612:Add BUILD_USES_RECOVERY_AS_BOOT to soong config
Ic76c325ce:Directly create ramdisk dirs in ramdisk image rule...
I4c5374deb:Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars
I8aab5faf3:Add ramdisk_available to init_first_stage's deps
I9d5a10661:Add ramdisk_available to init_first_stage's deps
Iaa2edeb4a:Add ramdisk_available to init_first_stage's deps
I7cb582ca0:Update init_first_stage
I06091d15e:Add ramdisk_available to init_first_stage's deps
I8bdb8dda3:Add ramdisk_available to init_first_stage's deps
I7436b8dd1:Add ramdisk_available to init_first_stage's deps
I39693fd86:Add ramdisk_available to init_first_stage's deps
I0a9ba90f0:Add ramdisk_available to init_first_stage's deps
Ib66b4c4ea:Add ramdisk_available to init_first_stage's deps
I31ce63d23:Add ramdisk_available to init_first_stage's deps
Icb580f97c:Add ramdisk_available to init_first_stage's deps
I044a075b7:Add ramdisk_available to init_first_stage's deps
I33164a7e7:Fix ndk and aml arch order
Ib8d92904a:Add ramdisk_available to sysprop_library
Ibc3516453:Add install_in_root to cc_binary
Change-Id: I3f48a1bee726c7c2b38c9bdc501b2a32337eaab7
Revert "Add ramdisk_available to init_first_stage's deps"
Revert submission 15071196-init_first_stage_soong
Reason for revert: fixes b/192248690
Reverted Changes:
I23cf4f975:Add ramdisk_available to init_first_stage's deps
Icd98c7e24:Add ramdisk_available to init_first_stage's deps
If9da9ba16:Add ramdisk_available to init_first_stage's deps
Ibc8668029:Add ramdisk_available to init_first_stage's deps
I3b4b8c475:Add ramdisk_available to init_first_stage's deps
I59cd149e0:Completely migrate init first stage to Soong
I36d789578:Add ramdisk_available to init_first_stage's deps
I2a0daa612:Add BUILD_USES_RECOVERY_AS_BOOT to soong config
Ic76c325ce:Directly create ramdisk dirs in ramdisk image rule...
I4c5374deb:Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars
I8aab5faf3:Add ramdisk_available to init_first_stage's deps
I9d5a10661:Add ramdisk_available to init_first_stage's deps
Iaa2edeb4a:Add ramdisk_available to init_first_stage's deps
I7cb582ca0:Update init_first_stage
I06091d15e:Add ramdisk_available to init_first_stage's deps
I8bdb8dda3:Add ramdisk_available to init_first_stage's deps
I7436b8dd1:Add ramdisk_available to init_first_stage's deps
I39693fd86:Add ramdisk_available to init_first_stage's deps
I0a9ba90f0:Add ramdisk_available to init_first_stage's deps
Ib66b4c4ea:Add ramdisk_available to init_first_stage's deps
I31ce63d23:Add ramdisk_available to init_first_stage's deps
Icb580f97c:Add ramdisk_available to init_first_stage's deps
I044a075b7:Add ramdisk_available to init_first_stage's deps
I33164a7e7:Fix ndk and aml arch order
Ib8d92904a:Add ramdisk_available to sysprop_library
Ibc3516453:Add install_in_root to cc_binary
Change-Id: I9ac333972fcd016059ea73f48b295d7140414a50
Revert "Add ramdisk_available to init_first_stage's deps"
Revert submission 15071196-init_first_stage_soong
Reason for revert: fixes b/192248690
Reverted Changes:
I23cf4f975:Add ramdisk_available to init_first_stage's deps
Icd98c7e24:Add ramdisk_available to init_first_stage's deps
If9da9ba16:Add ramdisk_available to init_first_stage's deps
Ibc8668029:Add ramdisk_available to init_first_stage's deps
I3b4b8c475:Add ramdisk_available to init_first_stage's deps
I59cd149e0:Completely migrate init first stage to Soong
I36d789578:Add ramdisk_available to init_first_stage's deps
I2a0daa612:Add BUILD_USES_RECOVERY_AS_BOOT to soong config
Ic76c325ce:Directly create ramdisk dirs in ramdisk image rule...
I4c5374deb:Add BOARD_BUILD_SYSTEM_ROOT_IMAGE to config vars
I8aab5faf3:Add ramdisk_available to init_first_stage's deps
I9d5a10661:Add ramdisk_available to init_first_stage's deps
Iaa2edeb4a:Add ramdisk_available to init_first_stage's deps
I7cb582ca0:Update init_first_stage
I06091d15e:Add ramdisk_available to init_first_stage's deps
I8bdb8dda3:Add ramdisk_available to init_first_stage's deps
I7436b8dd1:Add ramdisk_available to init_first_stage's deps
I39693fd86:Add ramdisk_available to init_first_stage's deps
I0a9ba90f0:Add ramdisk_available to init_first_stage's deps
Ib66b4c4ea:Add ramdisk_available to init_first_stage's deps
I31ce63d23:Add ramdisk_available to init_first_stage's deps
Icb580f97c:Add ramdisk_available to init_first_stage's deps
I044a075b7:Add ramdisk_available to init_first_stage's deps
I33164a7e7:Fix ndk and aml arch order
Ib8d92904a:Add ramdisk_available to sysprop_library
Ibc3516453:Add install_in_root to cc_binary
Change-Id: Iaccc4bada78e63fdae3249adfc668c0b30418758
Previously, when determining which dependencies, direct or transitive,
of a prebuilt_apex/apex_set required APEX variants the code assumed
that all dependencies implemented ApexModule. While that is true for
the modules that can be explicitly mentioned in the exported...
properties it is not true for all of them. e.g. A
prebuilt_apex/apex_set can depend on license modules which do not
implement ApexModule.
This change simply ignores any module that does not implement
ApexModule.
Bug: 179354495
Test: m nothing
Change-Id: Iead6f9d1085d169335b88ceadcce2d8cc042254d
Previously, the stub dex jars for each HiddenAPIScope was created by
merging the stub dex jars provided by each module for that scope. Then
the widest stub dex jars were chosen. So, if module A provided public,
system and test stub dex jars and module B provided only public then
the stub dex jars for each scope would be:
* public -> A,B
* system -> A
* test -> A
So, the widest API scope for which there are stub dex jars is "test"
and so the widest stub dex jars would just come from module A and not
module B. So, when "hiddenapi list" is run for module C which depends
on modules A and B it only gets given stub dex jars for module A which
means that it cannot resolve all the types that C may use which can
lead to incorrect flags being generated.
This change does not merge the stub dex jars from each module together
and instead keeps them separate by module. The widest stub dex jars
list is constructed by asking each module in turn for their widest stub
dex jars. e.g. Given the above example we would have:
Module A:
* public
* system
* test <- widest
Module B:
* public <- widest
So, the widest stub dex jars will be A's test and B's public stub dex
jars.
Bug: 179354495
Test: m out/soong/hiddenapi-flags.csv
- make sure that this does not change the file.
Merged-In: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
Change-Id: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
(cherry picked from commit 280a31aac39697a069f2f2f2ee471ffafb52d2a3)
The widest stub dex jars should include the widest stub dex jars
provided by each module. So, if module A has public, system and test
and module B has only public then the widest stub dex jars should
include module A's test and module B's public stub dex jars. Instead,
they just include module A's test.
That behaviour is needed so that when the "hiddenapi list" tool is run
against a module C that it is passed stub dex jars from both module A
and module B so that any references to the types provided by those APIs
can be resolved.
A follow up change will fix this issue.
Bug: 179354495
Test: m nothing
Merged-In: Ibd31964e8d2a33fa92fbd0b800c9fe054ee359c7
Change-Id: Ibd31964e8d2a33fa92fbd0b800c9fe054ee359c7
(cherry picked from commit d2b1e0ca92cb3f2c4b98efffd5968057af4e4320)
When generating the stub-flags.csv for a bootclasspath_fragment the
hiddenapi list tool is not given a complete set of all classes and
members. This change causes it to ignore them by passing the new
--fragment option to it.
This does not risk changing the flags as the stub-flags.csv files
created with the --fragment option are compared with the monolithic
out/soong/hiddenapi/hiddenapi-stub-flags.txt file which is not run
with this option to ensure that they match.
Bug: 179354495
Test: m out/soong/hiddenapi-stub-flags.csv
- make sure that this does not change the file.
Merged-In: I890c7374c445759cade4d685f51e81261b7ccea2
Change-Id: I890c7374c445759cade4d685f51e81261b7ccea2
(cherry picked from commit 156b5d3b61848fc7d41c1e94f92e532ae5142d2e)
Previously, hidden API processing could only be done by those
bootclasspath_fragment modules that either did not depend on any other
fragments (e.g. art-bootclasspath-fragment) or only depended on APIs
provided by other fragments (e.g. i18n-bootclasspath-fragment). That
meant that modules like com.android.os.statsd-bootclasspath-fragment
that depended on APIs provided by parts of the platform which are not
yet part of another bootclasspath_fragment could not perform hidden
API processing.
This change adds support for a bootclasspath_fragment to specify the
additional stubs needed to perform hidden API processing. It adds a new
additional_stubs property that can be used to specify the additional
stub libraries.
Most bootclasspath_fragments that need to use the property will need
access to the APIs provided by the android-non-updatable.* libraries.
Rather than have each fragment explicitly specify the correct module
for each scope it treats "android-non-updatable" as if it was a
java_sdk_library that can provide different jars for each scope.
Soong will handle mapping that to the correct android-non-updatable.*
module.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv \
out/soong/hiddenapi/hiddenapi-index.csv \
out/soong/hiddenapi/hiddenapi-stub-flags.txt \
out/soong/hiddenapi/hiddenapi-unsupported.csv
- make sure that this change does not change the contents.
m TARGET_BUILD_APPS=Calendar nothing
Merged-In: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
(cherry picked from commit 5cca7c44e51d0d08a5ea842d0f9870a772529dec)
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-stub-flags.txt
- check that an error is reported if a modular stub-flags.csv file,
i.e. one created by a fragment is not a subset of the monolithic
file, e.g. because a signature in the modular file has different
flags than it does in the monolithic or is not present there.
Merged-In: I46ebb495cb093a5e3abe7571c49933c845318549
Change-Id: I46ebb495cb093a5e3abe7571c49933c845318549
(cherry picked from commit 2e880971528cd4a2d93062072c7d8e9ff7998ade)
Previously, the func created a rule and returned it for the caller to
create with the appropriate name and description. This change passes
the name and description into the func and causes it to create the rule
itself. The func is also renamed to make it more consistent with the
other similar rules.
Bug: 179354495
Test: m nothing
Merged-In: I2a4455daa8a6090ed5568994b255848d063e1ab2
Change-Id: I2a4455daa8a6090ed5568994b255848d063e1ab2
(cherry picked from commit 4539a37a617ecfd5abc11697ed0d15370db6492b)
Add an apex_name property to prebuilt APEX modules to allow specifying
the "runtime" name of the APEX, i.e. the one it gets mounted as in /apex/,
which is also the one used for the apex variations.
Introduce a callback to retrieve that name consistently for all APEX
modules (apex, override_apex, prebuilt_apex, and apex_set), and update
some apex mutator code paths to use it.
For APEX source modules (apex and override_apex), it's necessary to add
a new field in apexBundle, since the name property gets overridden for
the override variant that override_apex creates.
Cherry-picked from https://r.android.com/1748294.
Test: m nothing
Bug: 191269918
Change-Id: If8612639bffdf91cbcab3387b0603bf5dffef1f5
Merged-In: If8612639bffdf91cbcab3387b0603bf5dffef1f5
Lint's NewApi checks currently produce a lot of false positive findings.
The filtered lint database removes information of classes defined by
mainline modules which are the cases that might become a false positive.
This commit updates soong to use this database instead of the normal one
when linting mainline modules.
Test: m lint-check
Fixes: 186478867
Change-Id: Ica646081b9189303c393b36b2f02914d69eee291
Merged-In: Ica646081b9189303c393b36b2f02914d69eee291
Although the hidden API runtime does not support a module-lib API flag
the hidden API processing does need to used them as they are needed by
the "hiddenapi list" tool for any bootclasspath_fragment module whose
contents builds against an sdk_version of "module_current". Without it
the "hiddenapi list" tool could fail to resolve references to classes
provided by other modules which would break the build.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Merged-In: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
Change-Id: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
(cherry picked from commit b51db2ed8eb3bf528e6914dd0720ee6d2ef54ee1)
Adds a test to establish a baseline for a follow up change that adds
module_lib support to hidden API processing.
Bug: 179354495
Test: m nothing
Merged-In: I5630075825c674b2e4f38bd459c7b061c01fc362
Change-Id: I5630075825c674b2e4f38bd459c7b061c01fc362
(cherry picked from commit 48b67415108db83f26a16a80ad60fab5c6cfdb84)
Previously, the hidden API processing used SdkKind to identify the API
scopes, e.g. public, system, etc. that are of interest for hidden API
processing. Unfortunately, there is a mismatch between the SdkKind and
what hidden API processing needs. e.g. SdkKind includes values that are
not used by hidden API processing and hidden API processing needs
additional API scope specific information not provided by SdkKind. The
apiScope struct used in sdk_library.go is also not a suitable
representation for similar reasons.
This change adds the HiddenAPIScope (following a similar approach as
apiScope) that rectifies that and uses it as a replacement for SdkKind
in most parts of the hidden API processing. The SdkKind is still used
for retrieving information from java_sdk_library[_import] modules.
Follow up changes will extend the HiddenAPIScope with more information.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Merged-In: I97968f58535121652852b8d25217aa288afd2bfd
Change-Id: I97968f58535121652852b8d25217aa288afd2bfd
(cherry picked from commit 31fad800a7a44ef2edda5d4051335f28d514139a)
Bug: http://b/189328402
This contains a fix to AArch64 __clear_cache.
Test: TH + Manual verification by emulator team.
Change-Id: Iff1064df8361163a6828b01256d5a7950f618652
Merged-In: Iff1064df8361163a6828b01256d5a7950f618652
(cherry picked from commit 3e54508a3a83eef2c8265192e232196a6572b31f)
Previously whether prebuilt properties were customizable was dependent
on the order of calling various inits.
Test: go test soong tests
Bug: 191975220
Change-Id: Icaa1fe811a5f5fc4aa5fc9fa0ec0b90debe3d537
Merged-In: Icaa1fe811a5f5fc4aa5fc9fa0ec0b90debe3d537
(cherry picked from commit 69d6413dd0a0dad94335a4b0c8e9eef5c9383b70)
Bug: 158843648
Test: check if dexpreopt.config for the module defined in mk file has
DexPreoptImageLocationsOnDevice field
Change-Id: Idb2de398871ff114245393a9dd92b5a1b5c942e7
Merged-In: Idb2de398871ff114245393a9dd92b5a1b5c942e7
(cherry picked from commit e3165c8de302839c8ab15f53d8024b585c62061f)
Previously, a java_sdk_library with shared_library = true would create
a variation per APEX because it depends on an sdkLibraryXml module
which generates a file containing the APEX name. However, a shared
java_sdk_library_import would create a merged APEX variation. The
inconsistent variations caused failures in sdkDepsReplaceMutator.
This change ensures that both java_sdk_library and
java_sdk_library_import create an APEX specific variation when their
shared_library property is true.
Bug: 190499958
Test: m nothing
- ran the above command after modifying the test to reproduce the
problem and then after fixing to verify that it fixed the problem.
Change-Id: Iee81776a8569db3e871c40cbde14d248dfeb56e4
Martin Stjernholm