IssueTracker

According to Issue 237190749, this did not happen in 32, so something new happened in 33.

IMO, the real answer here is probably that core-lambda-stubs.jar shouldn't be in a host-specific build-tools distribution, since it's a device library that should be common across hosts. That would fix this caching issue and let us remove some hoops the build has to go through to get it packaged (though that wouldn't be enough to actually let us turn down Mac device builds in the platform)

That being said, I see no reason why the two should be different today. And looking at the build rules, the Mac version is more likely to be correct (and those configs haven't changed for years). Looking at builds of both linux and mac on aosp-sdk-release from last week agree -- they both look like the Mac listing above.

Which CI builds did the build-tools packages ship from? My best guess would be that the during the linux build it may have gotten replaced by a different prebuilt due to libcore being in the runtime apex.

Hello. Is there any chances to get this fixed? It's making gradle remote cache almost useless for android projects written on Kotlin.

I can confirm that in build-tools 32.0.0 core-lambda-stubs.jar were identical between linux and darwin. In 33.0.0 they are different.

rajukulkarni@ what builds do build-tools come from?

We need to schedule a new release with build-tools fixed. From observation seems like linux is the one that is incomplete jar as observed in #4 (it is 15.1kb instead of 18.2kb that it should be)

(given that both paulduffin@ and tobiast@ are no longer on the team and are on git blame for this build file) +miguelaranda@google.com from libcore team to validate what this jar should look like

Hi, just an update, that this issue still persists in the latest build tools build (https://android-build.googleplex.com/builds/branch-dashboard/git_tm-beta3-release?build_id=9064945) Let's make sure this gets fixed for the next build tools release version.

The problem is still persists in 33.0.1 version. Are there any updates here?

On closer inspection the only difference in the actual class definitions seems to be debug info, where the mac classes contain debug info but the windows and linux ones don't.

Anton, are you the right person to look at this?

To answer Dan's question for 33.0.1 it was released from

- sdk-build-tools : { # T  33.0.1
    bid: "9306103",
    branch: "git_tm-beta3-release",
    target-linux: "sdk_phone_armv7-win_sdk",
    target-windows: "sdk_phone_armv7-win_sdk",
    target-darwin: "sdk_phone_armv7-sdk_mac",
    sign: true,
}

and the artifact is sdk-repo-{platform_name}-build-tools-{build_id}.zip

I've done some restructuring of how the SDK is built. The SDK now isn't host specific, there's just a single sdk target on ab/master. The sdk build tools still need to be for each host, but I'm surprised to see this stub jar in the build tools zip (per comment#13). I don't know the purpose of this stub or whether it could be in the non-host-specific sdk instead. Over to libcore team for that.

There shouldn't be any differences with this stub jar on host. The history for this JAR dates back to 2016 when it was added to address a circular dependency for javac (b/26753820). It is not something that anyone on the current team is particularly familiar with.

I think the difference between the two is that the Mac was built from source but the linux was using prebuilts/module_sdk/art/current/sdk/java/core-lambda-stubs.jar. The reason that file does not look much like a standard Jar file is almost certainly because it was generated by Turbine.

I ran m core-lambda-stubs and checked the out/soong/.intermediates/libcore/core-lambda-stubs. And found the following

106353782     16 -rw-r--r--   1 paulduffin primarygroup    15149 Oct 17 18:04 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/turbine/core-lambda-stubs.jar
106353783     16 -rw-r--r--   1 paulduffin primarygroup    15149 Nov 25 11:10 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/turbine-combined/core-lambda-stubs.jar
106304088     12 -rw-r--r--   1 paulduffin primarygroup     8511 Nov 25 11:10 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/javac/core-lambda-stubs.jar
106304087     20 -rw-r--r--   1 paulduffin primarygroup    18163 Nov 25 11:10 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/withres/core-lambda-stubs.jar

1. The turbine ones don't appear to compress the contents, have no directories or manifests, just the .class files.
2. The javac one is compressed, includes a manifest, directories and .class files.
3. The withres one is also compressed, includes a manifest, directories, .class files and .java files.

So, it looks as though the linux one is using a turbine one (possibly via prebuilts) and the mac is using the withres one.

Which raises a couple of questions:

1. Which of the 3 different core-lambda-stubs.jar above should be being used in the prebuilts?
2. Which should be being used in the main Android sdk?

The advantage of using the turbine one is that it is smaller (even without compression). The advantage of using the withres is the source is available (assuming that Studio can find it). However, the source is just stubs anyway as the only reason these classes are provided is because the javac compiler needs them. They are not used by Android at runtime at all so have no implementation.

I think at the end of the day the only thing that really matters is that they are consistent across platforms and there is no reason why they should not be.

It looks like there's code in studio that assumes it's in buildtools, so unless we want to break existing studio versions it's going to have to remain there: https://cs.android.com/search?q=core-lambda-stub&sq=&ss=android-studio

I think the question then is probably why the mac build disables prebuilts. Could you look into that Paul?

I think that is easy to answer. The Mac build disables prebuilts because we do not generate host side prebuilts suitable for use in a Mac.

That is why the sdk snapshot tests have this code:

func TestMain(m *testing.M) {
	if runtime.GOOS != "linux" {
		// b/145598135 - Generating host snapshots for anything other than linux is not supported.
		log.Printf("Skipping as sdk snapshot generation is only supported on linux not %s", runtime.GOOS)
		os.Exit(0)
	}

	os.Exit(m.Run())
}

Switching the Mac to use prebuilts instead of sources in general is probably not the answer here.

Could we add it to the non-host-specific SDK and then get the target that generates the buildtools to copy the file from the there?

add it to the non-host-specific SDK

Wouldn't that still use the source-built version on mac, and prebuilt on linux?

I was referring to this part you mentioned in comment#14:

I've done some restructuring of how the SDK is built. The SDK now isn't host specific, there's just a single sdk target on ab/master.

Could that not build core-lambda-stubs?

Anton and I have discussed this offline and we think we have a quick solution to the problem.

Assuming that the problem is the inconsistency between the core-lambda-stubs.jar used on Linux and on Mac then the quickest way to address that is to hard-code this dependency to use "prebuilt_core-lambda-stubs" instead of "core-lambda-stubs". That will force both the Mac build of build-tools (which currently uses the source) and the Linux build of build-tools (which currently uses prebuilts) to both use prebuilts.

I have made the change locally in my AOSP checkout to see if it works. If it does then I will upload it so someone can cherry pick to the appropriate branch and test it there.

Uploaded change https://r.android.com/2318749. I tested that it does what I want for the Linux and Windows builds but I don't have a Mac to test it on.

Chris, are you the right person to take this forward, test it on a Mac and cherry pick it into the appropriate branch? If not could you assign it to whoever is the right person.

Thanks for that - I'll take a look and drive this forward

Thanks Paul, this all works

[aosp/2318749](https://android-review.git.corp.google.com/c/platform/development/+/2318749 which is landed internally in tm-dev ag/I9507eb785bca0fb929dbb587caf0b26455ec9480

I've checked the artifacts of sdk_phone_armv7-sdk_mac and sdk_phone_armv7-win_sdk on ab/9406650 (a branch that the change has flowed to that has fixed the issue) and of the sdk and sdk-mac on u release branches.

Now to releasing build tools with the fix

I'll keep this updated with the release status

I filed b/264245942 for the longer-term fix of putting it in the platforms dir instead of build-tools

#comment30 - I've filed https://issuetracker.google.com/268504557 to track

copy an existing role and adjust its permissions

sabberhossen09@gmail.com Thanks for developers

I'm facing an error challenge on with SDK build tools on my Handy_T2_EU

https://issuetracker.google.com/issues?q=id%3A(279644036)

https://issuetracker.google.com/issues/241546164

https://issuetracker.google.com/237299698#comment30

Which build tools version was this fixed in?

This landed in build tools 33.0.2

IssueTracker

Assigned to me Starred by me CC'd to me Reported by me

To be verified 

Bookmark groups Saved searches Hotlists Create hotlist Create bookmark group Browse components Issue 237299698 Android Public Tracker > App Development > SDK 237299698 core-lambda-stubs.jar version 33.0.0 differs on mac vs linux/win Comments (44) Dependencies (0) Duplicates (2) Blocking (0) Resources (19) Fixed Bug P1 Status Update

No update yet. Descriptionxa...@google.com created issue #1 Jun 27, 2022 11:54AM The mac version has manifest, empty directories, and more importantly the source files. But also the class files seems to be different

This triggers cache miss and is a big problem we need to solve. Raju, can you find the right person to look into this?

The content of the jar on linux/win is:

  Length      Date    Time    Name
---------  ---------- -----   ----
      329  01-01-2010 00:00   java/lang/invoke/CallSite.class
      433  01-01-2010 00:00   java/lang/invoke/LambdaConversionException.class
     1004  01-01-2010 00:00   java/lang/invoke/LambdaMetafactory.class
     1155  01-01-2010 00:00   java/lang/invoke/MethodHandle.class
     3046  01-01-2010 00:00   java/lang/invoke/MethodHandles$Lookup.class
     3480  01-01-2010 00:00   java/lang/invoke/MethodHandles.class
     3248  01-01-2010 00:00   java/lang/invoke/MethodType.class
     1206  01-01-2010 00:00   java/lang/invoke/SerializedLambda.class
---------                     -------

On Mac it is:

  Length      Date    Time    Name
---------  ---------- -----   ----
        0  01-01-2008 00:00   META-INF/
       45  01-01-2008 00:00   META-INF/MANIFEST.MF
        0  01-01-2008 00:00   java/
        0  01-01-2008 00:00   java/lang/
        0  01-01-2008 00:00   java/lang/invoke/
      520  01-01-2008 00:00   java/lang/invoke/CallSite.class
     1045  01-01-2008 00:00   java/lang/invoke/LambdaConversionException.class
     1463  01-01-2008 00:00   java/lang/invoke/LambdaMetafactory.class
     2117  01-01-2008 00:00   java/lang/invoke/MethodHandle.class
     4777  01-01-2008 00:00   java/lang/invoke/MethodHandles$Lookup.class
     5203  01-01-2008 00:00   java/lang/invoke/MethodHandles.class
     5275  01-01-2008 00:00   java/lang/invoke/MethodType.class
     2127  01-01-2008 00:00   java/lang/invoke/SerializedLambda.class
        0  01-01-2008 00:00   ojluni/
        0  01-01-2008 00:00   ojluni/src/
        0  01-01-2008 00:00   ojluni/src/lambda/
        0  01-01-2008 00:00   ojluni/src/lambda/java/
        0  01-01-2008 00:00   ojluni/src/lambda/java/java/
        0  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/
        0  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/
     1484  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/CallSite.java
     2759  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/LambdaConversionException.java
     2213  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/LambdaMetafactory.java
     2109  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/MethodHandle.java
     6432  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/MethodHandles.java
     3573  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/MethodType.java
     2677  01-01-2008 00:00   ojluni/src/lambda/java/java/lang/invoke/SerializedLambda.java
---------                     -------

Issue summary Mentioned issues (5) P2 core-lambda-stubs.jar are not aligned for Linux and macOS installations as per build-tools;33.0.0 “ Issue 237190749 ”

xa...@ #2

--

“ b/26753820 ”

ot...@ #15

--

“ b/264245942 ”

ha...@ #29 P1 Renderscipt is broken on apple silicon in build tools 33.0.2 “ https://issuetracker.google.com/268504557 ”

cm...@ #31 P3 Different content of core-lambda-stubs.jar leads to build cache misses “ https://issuetracker.google.com/241546164 ”

da...@ #40 Links (11) “ some hoops ” dw...@ #4 “ build rules ” dw...@ #4 “ linux ” dw...@ #4 “ mac ” dw...@ #4 “ https://android-build.googleplex.com/builds/branch-dashboard/git_tm-beta3-release?build_id=9064945 ” hm...@ #10 Comments All comments xa...@google.com xa...@google.com #2Jun 27, 2022 11:56AM According to Issue 237190749, this did not happen in 32, so something new happened in 33. ra...@google.com ra...@google.com #3Jul 8, 2022 03:40PM Reassigned to pa...@google.com. @Patrick - can you help investigate this issue? CC'ing Dan in case if he has pointers dw...@google.com dw...@google.com #4Jul 8, 2022 04:48PM IMO, the real answer here is probably that core-lambda-stubs.jar shouldn't be in a host-specific build-tools distribution, since it's a device library that should be common across hosts. That would fix this caching issue and let us remove some hoops the build has to go through to get it packaged (though that wouldn't be enough to actually let us turn down Mac device builds in the platform)

That being said, I see no reason why the two should be different today. And looking at the build rules, the Mac version is more likely to be correct (and those configs haven't changed for years). Looking at builds of both linux and mac on aosp-sdk-release from last week agree -- they both look like the Mac listing above.

Which CI builds did the build-tools packages ship from? My best guess would be that the during the linux build it may have gotten replaced by a different prebuilt due to libcore being in the runtime apex. nn...@joom.com nn...@joom.com #5Aug 12, 2022 03:49AM Hello. Is there any chances to get this fixed? It's making gradle remote cache almost useless for android projects written on Kotlin. au...@google.com au...@google.com #6Sep 14, 2022 05:14PM Reassigned to ra...@google.com. I can confirm that in build-tools 32.0.0 core-lambda-stubs.jar were identical between linux and darwin. In 33.0.0 they are different.

rajukulkarni@ what builds do build-tools come from? au...@google.com au...@google.com #7Sep 14, 2022 05:19PM We need to schedule a new release with build-tools fixed. From observation seems like linux is the one that is incomplete jar as observed in #4 (it is 15.1kb instead of 18.2kb that it should be) au...@google.com au...@google.com #8Sep 14, 2022 05:26PM (given that both paulduffin@ and tobiast@ are no longer on the team and are on git blame for this build file) +miguelaranda@google.com from libcore team to validate what this jar should look like ra...@google.com ra...@google.com #9Sep 14, 2022 05:45PM Reassigned to ja...@google.com. I discussed this with Neha earlier today. She is working on prepping for the release >> CP'ing the change to the release branch and kicking off a build and then getting a sanity test for review. hm...@google.com hm...@google.com #10Sep 21, 2022 04:56AM Hi, just an update, that this issue still persists in the latest build tools build (https://android-build.googleplex.com/builds/branch-dashboard/git_tm-beta3-release?build_id=9064945) Let's make sure this gets fixed for the next build tools release version. ly...@gmail.com ly...@gmail.com #11Nov 24, 2022 01:43AM The problem is still persists in 33.0.1 version. Are there any updates here? cm...@google.com cm...@google.com #12Nov 24, 2022 04:36AM Reassigned to ha...@google.com. On closer inspection the only difference in the actual class definitions seems to be debug info, where the mac classes contain debug info but the windows and linux ones don't. cm...@google.com cm...@google.com #13Nov 24, 2022 04:55AM Anton, are you the right person to look at this?

To answer Dan's question for 33.0.1 it was released from

- sdk-build-tools : { # T  33.0.1
    bid: "9306103",
    branch: "git_tm-beta3-release",
    target-linux: "sdk_phone_armv7-win_sdk",
    target-windows: "sdk_phone_armv7-win_sdk",
    target-darwin: "sdk_phone_armv7-sdk_mac",
    sign: true,
}

and the artifact is sdk-repo-{platform_name}-build-tools-{build_id}.zip ha...@google.com ha...@google.com #14Nov 24, 2022 10:30AM Reassigned to ot...@google.com. I've done some restructuring of how the SDK is built. The SDK now isn't host specific, there's just a single sdk target on ab/master. The sdk build tools still need to be for each host, but I'm surprised to see this stub jar in the build tools zip (per comment#13). I don't know the purpose of this stub or whether it could be in the non-host-specific sdk instead. Over to libcore team for that. ot...@google.com ot...@google.com #15Nov 25, 2022 02:55AM Assigned to ha...@google.com. There shouldn't be any differences with this stub jar on host. The history for this JAR dates back to 2016 when it was added to address a circular dependency for javac (b/26753820). It is not something that anyone on the current team is particularly familiar with.

pa...@google.com pa...@google.com #16Nov 25, 2022 03:23AM I think the difference between the two is that the Mac was built from source but the linux was using prebuilts/module_sdk/art/current/sdk/java/core-lambda-stubs.jar. The reason that file does not look much like a standard Jar file is almost certainly because it was generated by Turbine.

I ran m core-lambda-stubs and checked the out/soong/.intermediates/libcore/core-lambda-stubs. And found the following

106353782     16 -rw-r--r--   1 paulduffin primarygroup    15149 Oct 17 18:04 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/turbine/core-lambda-stubs.jar
106353783     16 -rw-r--r--   1 paulduffin primarygroup    15149 Nov 25 11:10 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/turbine-combined/core-lambda-stubs.jar
106304088     12 -rw-r--r--   1 paulduffin primarygroup     8511 Nov 25 11:10 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/javac/core-lambda-stubs.jar
106304087     20 -rw-r--r--   1 paulduffin primarygroup    18163 Nov 25 11:10 out/soong/.intermediates/libcore/core-lambda-stubs/android_common/withres/core-lambda-stubs.jar

1. The turbine ones don't appear to compress the contents, have no directories or manifests, just the .class files.
2. The javac one is compressed, includes a manifest, directories and .class files.
3. The withres one is also compressed, includes a manifest, directories, .class files and .java files.

So, it looks as though the linux one is using a turbine one (possibly via prebuilts) and the mac is using the withres one.

Which raises a couple of questions:

1. Which of the 3 different core-lambda-stubs.jar above should be being used in the prebuilts?
2. Which should be being used in the main Android sdk?

The advantage of using the turbine one is that it is smaller (even without compression). The advantage of using the withres is the source is available (assuming that Studio can find it). However, the source is just stubs anyway as the only reason these classes are provided is because the javac compiler needs them. They are not used by Android at runtime at all so have no implementation.

I think at the end of the day the only thing that really matters is that they are consistent across platforms and there is no reason why they should not be. ha...@google.com ha...@google.com #17Nov 25, 2022 04:25AM Reassigned to pa...@google.com. It looks like there's code in studio that assumes it's in buildtools, so unless we want to break existing studio versions it's going to have to remain there: https://cs.android.com/search?q=core-lambda-stub&sq=&ss=android-studio

I think the question then is probably why the mac build disables prebuilts. Could you look into that Paul? pa...@google.com pa...@google.com #18Nov 25, 2022 04:36AM I think that is easy to answer. The Mac build disables prebuilts because we do not generate host side prebuilts suitable for use in a Mac. pa...@google.com pa...@google.com #19Nov 25, 2022 04:42AM That is why the sdk snapshot tests have this code:

func TestMain(m *testing.M) {
	if runtime.GOOS != "linux" {
		// b/145598135 - Generating host snapshots for anything other than linux is not supported.
		log.Printf("Skipping as sdk snapshot generation is only supported on linux not %s", runtime.GOOS)
		os.Exit(0)
	}

	os.Exit(m.Run())
}

Switching the Mac to use prebuilts instead of sources in general is probably not the answer here.

Could we add it to the non-host-specific SDK and then get the target that generates the buildtools to copy the file from the there? ha...@google.com ha...@google.com #20Nov 25, 2022 04:52AM

add it to the non-host-specific SDK

Wouldn't that still use the source-built version on mac, and prebuilt on linux? pa...@google.com pa...@google.com #21Nov 25, 2022 04:54AM I was referring to this part you mentioned in comment#14:

I've done some restructuring of how the SDK is built. The SDK now isn't host specific, there's just a single sdk target on ab/master. pa...@google.com pa...@google.com #22Nov 25, 2022 04:54AM Could that not build core-lambda-stubs? pa...@google.com pa...@google.com #23Nov 25, 2022 08:54AM Anton and I have discussed this offline and we think we have a quick solution to the problem.

Assuming that the problem is the inconsistency between the core-lambda-stubs.jar used on Linux and on Mac then the quickest way to address that is to hard-code this dependency to use "prebuilt_core-lambda-stubs" instead of "core-lambda-stubs". That will force both the Mac build of build-tools (which currently uses the source) and the Linux build of build-tools (which currently uses prebuilts) to both use prebuilts. pa...@google.com pa...@google.com #24Nov 25, 2022 08:55AM Reassigned to cm...@google.com. I have made the change locally in my AOSP checkout to see if it works. If it does then I will upload it so someone can cherry pick to the appropriate branch and test it there. pa...@google.com pa...@google.com #25Nov 25, 2022 09:26AM Uploaded change https://r.android.com/2318749. I tested that it does what I want for the Linux and Windows builds but I don't have a Mac to test it on.

Chris, are you the right person to take this forward, test it on a Mac and cherry pick it into the appropriate branch? If not could you assign it to whoever is the right person. cm...@google.com cm...@google.com #26Nov 25, 2022 09:45AM Thanks for that - I'll take a look and drive this forward cm...@google.com cm...@google.com #27Dec 15, 2022 06:54AM Marked as fixed. Thanks Paul, this all works

[aosp/2318749](https://android-review.git.corp.google.com/c/platform/development/+/2318749 which is landed internally in tm-dev ag/I9507eb785bca0fb929dbb587caf0b26455ec9480

I've checked the artifacts of sdk_phone_armv7-sdk_mac and sdk_phone_armv7-win_sdk on ab/9406650 (a branch that the change has flowed to that has fixed the issue) and of the sdk and sdk-mac on u release branches.

Now to releasing build tools with the fix cm...@google.com cm...@google.com #28Dec 15, 2022 07:02AM I'll keep this updated with the release status ha...@google.com ha...@google.com #29Jan 3, 2023 06:41AM I filed b/264245942 for the longer-term fix of putting it in the platforms dir instead of build-tools ga...@gmail.com ga...@gmail.com #30Feb 8, 2023 11:03PM facing error with SDK Build Tools 33.0.2 as well when upgrading to targetSdk = 33

Task :capture:compileDebugRenderscript FAILED dyld[15878]: Library not loaded: '@rpath/libclang_android.dylib' Referenced from: '/Users/gg/Library/Android/sdk/build-tools/33.0.2/llvm-rs-cc' Reason: tried: '/Users/gg/Library/Android/sdk/build-tools/33.0.2/../lib64/libclang_android.dylib' (no such file), '/Users/gg/Library/Android/sdk/build-tools/33.0.2/lib64/libclang_android.dylib' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e))), '/Users/gg/Library/Android/sdk/build-tools/33.0.2/../lib64/libclang_android.dylib' (no such file), '/Users/gg/Library/Android/sdk/build-tools/33.0.2/lib64/libclang_android.dylib' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e))), '/usr/lib/libclang_android.dylib' (no such file)

cm...@google.com cm...@google.com #31Feb 9, 2023 11:02AM #comment30 - I've filed https://issuetracker.google.com/268504557 to track ha...@gmail.com ha...@gmail.com #32Feb 14, 2023 03:31PM copy an existing role and adjust its permissions sa...@gmail.com sa...@gmail.com #33Mar 11, 2023 09:07PM sabberhossen09@gmail.com Thanks for developers oo...@gmail.com oo...@gmail.com #34Mar 24, 2023 09:17AM I'm facing an error challenge on with SDK build tools on my Handy_T2_EU lk...@gmail.com lk...@gmail.com #35Mar 28, 2023 12:37PM WILL YOU REMOVE THE STALKING POS USING YOUR SERVICES FROM MY ACCOUNT! IMMEDIATELY WOULD BE AMAZING

Lezlie

On Fri, Mar 24, 2023, 9:17 AM buganizer-system@google.com wrote:

Replying to this email means your email address will be shared with the team that works on this product.

https://issuetracker.google.com/issues/237299698

Changed

oo...@gmail.com oo...@gmail.com added comment #34 https://issuetracker.google.com/issues/237299698#comment34:

I'm facing an error challenge on with SDK build tools on my Handy_T2_EU

---

Reference Info: 237299698 core-lambda-stubs.jar version 33.0.0 differs on mac vs linux/win component: Android Public Tracker > App Development > SDK https://issuetracker.google.com/components/192728 status: Fixed reporter: xa...@google.com assignee: cm...@google.com cc: dw...@google.com, ot...@google.com, pr...@google.com, and 6 more type: Bug priority: P1 severity: S1 duplicate issue: 237190749 https://issuetracker.google.com/issues/237190749, 241546164 https://issuetracker.google.com/issues/241546164 retention: Component default ReportedBy: User

Generated by Google IssueTracker notification system

You're receiving this email because you are subscribed to updates on Google IssueTracker issue 237299698 https://issuetracker.google.com/issues/237299698. Unsubscribe from this issue. https://issuetracker.google.com/issues/237299698?unsubscribe=true

ma...@gmail.com ma...@gmail.com #36Apr 9, 2023 08:44AM Comment has been deleted. lk...@gmail.com lk...@gmail.com #37Apr 9, 2023 09:07AM Law Enforcement have been notified in regards to the hacking stalking to my accounts. At this moment in time I have no other avenues to assume other than everyone an every account is involved with all the open source, and developer access and no contact from Google whatsoever, Be advised this fuckory is on a short timer. I hope your company is no way involved and you can provide additional information to put the POS in prison. beautiful day to all not involved. lezlie

Lezlie

On Sun, Apr 9, 2023, 8:44 AM buganizer-system@google.com wrote:

Replying to this email means your email address will be shared with the team that works on this product.

https://issuetracker.google.com/issues/237299698

Changed

ma...@gmail.com ma...@gmail.com added comment #36 https://issuetracker.google.com/issues/237299698#comment36:

redacted

---

Reference Info: 237299698 core-lambda-stubs.jar version 33.0.0 differs on mac vs linux/win component: Android Public Tracker > App Development > SDK https://issuetracker.google.com/components/192728 status: Fixed reporter: xa...@google.com assignee: cm...@google.com cc: dw...@google.com, ot...@google.com, pr...@google.com, and 6 more type: Bug priority: P1 severity: S1 duplicate issue: 237190749 https://issuetracker.google.com/issues/237190749, 241546164 https://issuetracker.google.com/issues/241546164 retention: Component default ReportedBy: User

Generated by Google IssueTracker notification system

You're receiving this email because you have just been removed from any roles on Google IssueTracker issue 237299698 https://issuetracker.google.com/issues/237299698.

lk...@gmail.com lk...@gmail.com #38Apr 9, 2023 09:10AM like I've stated, law enforcement have been notified to the stalking via developers at Google. good day to those not involved. lezlie

Lezlie

On Sun, Apr 9, 2023, 8:44 AM buganizer-system@google.com wrote:

Replying to this email means your email address will be shared with the team that works on this product.

https://issuetracker.google.com/issues/237299698

Changed

ma...@gmail.com ma...@gmail.com added comment #36 https://issuetracker.google.com/issues/237299698#comment36:

redacted

---

Reference Info: 237299698 core-lambda-stubs.jar version 33.0.0 differs on mac vs linux/win component: Android Public Tracker > App Development > SDK https://issuetracker.google.com/components/192728 status: Fixed reporter: xa...@google.com assignee: cm...@google.com cc: dw...@google.com, ot...@google.com, pr...@google.com, and 6 more type: Bug priority: P1 severity: S1 duplicate issue: 237190749 https://issuetracker.google.com/issues/237190749, 241546164 https://issuetracker.google.com/issues/241546164 retention: Component default ReportedBy: User

Generated by Google IssueTracker notification system

You're receiving this email because you have just been removed from any roles on Google IssueTracker issue 237299698 https://issuetracker.google.com/issues/237299698.

te...@gmail.com te...@gmail.com #39May 2, 2023 09:14PM https://issuetracker.google.com/issues?q=id%3A(279644036) da...@gmail.com da...@gmail.com #40May 8, 2023 10:46PM https://issuetracker.google.com/issues/241546164 bo...@gmail.com bo...@gmail.com #41Jul 20, 2023 09:22AM https://issuetracker.google.com/237299698#comment30 ga...@freeletics.com ga...@freeletics.com #42Aug 4, 2023 07:47AM Which build tools version was this fixed in? cm...@google.com cm...@google.com #43Aug 4, 2023 07:53AM This landed in build tools 33.0.2 mr...@gmail.com mr...@gmail.com #44Aug 21, 2023 07:20AM Update ja...@gmail.com ja...@gmail.com Aug 28, 2023 07:45AM deleted Restricted+ 0 B deleted Restricted+ 0 B Add comment Issue metadata Reporter xa...@google.com Type Bug Priority P1 Severity S1 Status Fixed Access Default access View Assignee cm...@google.com Verifier

Collaborators CC au...@google.com dw...@google.com ga...@google.com ha...@google.com mi...@google.com ... and 4 more (show all) AOSP ID

ReportedBy User Found In

Targeted To

Verified In

In Prod